Use alternate git ref with --progressive

[phemmer]

One of the downsides that prevents --progressive from working well is when the author has created multiple commits and is submitting them all at once. In this case, progressive mode will compare HEAD against their previous commit, and it might see a violation as pre-existing and incorrectly allow it.

A simple way to address this is to use something other than HEAD^1 as the git ref to compare against.
At a minimum, the user should be allowed to manually specify the ref, perhaps as an argument to --progressive such as --progressive=master. However it would make for a good user experience if various build systems were automatically supported. For example gitlab provides CI_MERGE_REQUEST_TARGET_BRANCH_NAME. There are many other CI systems, each with their own variables they provide, so I'm not sure if we do want to go this route, and/or which ones should be supported.

[kostyaplis]

We noticed the same need for our workflows.
It would be very useful to pass SHA or HEAD^n as optional argument that considered if progressive=True. So we can capture a regression in previous N commits, e.g. from branching point till now.
--progressive=abcd seems not good as progressive is boolean, so it will break existing configurations
maybe --commit=[HEAD^n|commit_hash] with default value of HEAD^1 ?

I'm keen to prepare a PR for that

[phemmer]

--progressive=abcd seems not good as progressive is boolean, so it will break existing configurations

Well right now the flag doesn't take a parameter. So adding a parameter wouldn't be breaking. The parameter would just default to HEAD^1 when not passed

[kostyaplis]

I mean if someone has progressive: true in config file

[MarcinWieczorek]

Hi, I'm leaving a comment here to indicate an urgent need of this feature. This logic is what at first I thought progressive mode now is and I think it should be. Current implementation gives a false sense of correctness in CI use cases.