I think this is a great improvement to prevent the Jenkins queue from growing too large and has been suggested in the past but we were unable to do due to difficulty with the version of the ghrpb plugin that was used at the time.
I know that we created different variants of the tests because we wanted to track metrics based upon whether something was a post commit (_Cron suffix) vs precommits but don't know why we split _Phrase and _Commit. On Tue, Jun 23, 2020 at 3:35 AM Tobiasz Kędzierski < tobiasz.kedzier...@polidea.com> wrote: > Hi everyone, > > I was investigating the possibility of canceling Jenkins builds when the > update to PR makes prior build irrelevant. (related to > https://issues.apache.org/jira/browse/BEAM-3105) > In the `GitHub Pull Request Builder Jenkins plugin [ghprb-plugin] there is > a hidden option `Cancel build on update` that seems to work fine. > e.g. > > 1. > > I make a PR > 2. > > ghprb-plugin triggers beam_PreCommit_PythonLint_Commit > 3. > > I make a new commit to the PR > > 4. > > ghprb-plugin aborts the previous `beam_PreCommit_PythonLint_Commit` > and adds to the queue the new one with updated sha1. > > > > This option seems to significantly improve the experience with build > triggering and we are planning to enable it shortly. > > However, putting a phrase “Run PythonLint PreCommit” in the comment > triggers new `beam_PreCommit_PythonLint_Phrase` build, but does not touch > already queued or running `beam_PreCommit_PythonLint_Commit` builds, that > are technically speaking, different jobs. > > For testing purposes I made a single job which was a “_Commit” job with > added “Trigger phrase” and it works well (commit builds cancelled after > putting phrase comment in PR) > > Hence my question: do we need separate “_Phrase” and “_Commit” jobs? > > BR > Tobiasz >
