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 >>>> >>>
