+1 to Andrew's analysis On Tue, Jun 23, 2020 at 12:13 PM Ahmet Altay <al...@google.com> wrote:
> Would it be possible to cancel any running _Phrase or _Commit variants, if > either one of them is triggered? > > On Tue, Jun 23, 2020 at 10:41 AM Andrew Pilloud <apill...@google.com> > wrote: > >> 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 >>>>> >>>>
