[Gluster-devel] Ability to skip regression jobs?

[Raghavendra Talur]

On Tue, Dec 20, 2016 at 9:31 PM, Nigel Babu <nigelb at redhat.com> wrote:
> Hello folks,
>
> There's a few conversations I've been having about reducing regressions
> workloads. Is it useful to have a mechanism to suggest in a commit message to
> skip regressions on a job? For instance, you'd say [ci-skip] and it would skip
> your commit.

We already have some form of this:
1. If it a Work in progress patch, don't give a +1 verified on the
patch and we won't run regression.
2. If it is a doc only change, we don't run regression.
3. If it is a distaf only change, we don't run regression.

If there is any genuine reason for a type of change to skip
regression, it should be configured on the jenkins side as we do for
changes above.

>
> My assumption is that we may have a genuine use-case where we don't want to run
> regressions. For example, changes to packaging, or changes to some files in
> extras. We could maintain a larger skip list, but that approach doesn't scale
> very well.
Packaging and extras changes do need to be tested, an error in systemd
unit file or an error in where it is placed is as critical as a code
bug.

>
> On the other hand, opening this up means it's likely to be abused. So we may
> have to do good policing.
This will certainly happen. I do not recommend any mechanism which
could be used by patch owner.

>
> Anyone have ideas either way?
One way to reduce load is to figure out a way to award +1s to parent
patches when a dependent patch passes regression. It is recommended
that a change be split into as many smaller sets as possible.
Currently, if we send 4 patches that need to be serially merged, all 4
have to pass regressions. Instead, if Jenkins offered a way to block
merging of subset of patches and made it possible to take all 4 in in
one go, we could run tests only on top of these patches. The last time
I checked, such a feature did not exist in Jenkins.

Thanks,
Raghavendra Talur

>
> --
> nigelb
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel