On Tue, Dec 20, 2016 at 9:31 PM, Nigel Babu <nigelb@xxxxxxxxxx> 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@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
