I believe we split _Commit and _Phrase to work around a bug with job filtering. For example, when you make a python change only the python tests are run based on the commit. We still want to be able to run the java jobs by trigger phrase if needed. There are also performance tests (Nexmark for example) that have different jobs to ensure PR runs don't end up published in the performance dashboard, but i think those have a split of _Phrase and _Cron.
As for canceling jobs, don't forget that the github status APIs are keyed on commit hash and job name (not PR). It is possible for a commit to be on multiple PRs and it is possible for a single PR to have multiple commits. There are workflows that will be broken if you are keying off of a PR to automatically cancel jobs. On Tue, Jun 23, 2020 at 9:59 AM Tyson Hamilton <tyso...@google.com> wrote: > +1 the ability to cancel in-flight jobs is worth deduplicating _Phrase and > _Commit. I don't see a benefit for having both. > > On Tue, Jun 23, 2020 at 9:02 AM Luke Cwik <lc...@google.com> wrote: > >> 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 >>> >>
