Logged in as a Committer, You need to open the configuration menu for the task, add in a string parameter for 'ghprPullId'. Save.
Then you can go to Build With Parameters, populate the new field with the PR number And the sha1 with origin/pr/<PRNUM>/merge The you can kick off the job. It doesn't automatically link to the PR, so you'll need to copy paste the run info into the PR. This matches what the normal runs seem to do. I have confirmed that it executes everything with the correct commits and so on. It's unfortunate that the PR variants weren't already configured to simply accept a PR number. On Mon, Jun 13, 2022, 4:22 PM Kiley Sok <[email protected]> wrote: > Reuven, it looks like yours may have been stuck in a weird state when we > re-enabled the precommits. I kicked off the tests on your PR with 'retest > this please' > > To clarify, precommits are working as before (pr comment and update > triggered) and so you should be able to check in code. > > If you want further testing with post commits, you'll need a committer to > manually trigger them on the Jenkins UI. I believe you can do this by > 'Build with Parameter' and putting in the PR number (correct me if I'm > wrong @Robert Burke <[email protected]>). If there are no objections, I > can re-enable triggers for the common postcommits. > > > > On Mon, Jun 13, 2022 at 4:06 PM Reuven Lax <[email protected]> wrote: > >> Are there any pointers on how to manually trigger the runs? >> >> On Mon, Jun 13, 2022 at 4:04 PM Robert Burke <[email protected]> wrote: >> >>> You know, I do forget that committers can manually trigger Jenkins runs. >>> >>> And after fiddling with the Jenkins options and filling in the expected, >>> but missing PR number parameter i think I've managed it. >>> >>> Thanks for the reminder! >>> >>> On Mon, Jun 13, 2022, 3:38 PM Kiley Sok <[email protected]> wrote: >>> >>>> Can you run the post commits from the Jenkins UI to unblock? We've >>>> turned off the triggers for all post commits, but could turn it on for a >>>> select few as well. >>>> >>>> On Mon, Jun 13, 2022 at 3:31 PM Robert Burke <[email protected]> >>>> wrote: >>>> >>>>> There are a couple of Go SDK PRs that are basically blocked on final >>>>> manual runs of the post commits, that we'd like to get in for the 2.40 >>>>> cut. >>>>> >>>>> Are we intending on delaying the 2.40 cut a little bit so PRs like >>>>> those can make it in? >>>>> >>>>> >>>>> On Mon, Jun 13, 2022, 1:32 PM Ahmet Altay <[email protected]> wrote: >>>>> >>>>>> Thank you all for working on this. >>>>>> >>>>>> On Mon, Jun 13, 2022 at 10:09 AM Kenneth Knowles <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Yes, the ghprb plugin was disabled. That was the entire action. I >>>>>>> believe my PR will reduce the load caused by the ghprb plugin; we are >>>>>>> currently restarting Jenkins to re-enable it. So we can unfreeze master >>>>>>> as >>>>>>> soon as Jenkins reboots. Basically, if your PR has a precommit status >>>>>>> great, otherwise please wait. >>>>>>> >>>>>>> What we lose from my change is postcommit comment triggers. I see >>>>>>> how this is unfortunate for our established release process that runs >>>>>>> them >>>>>>> all on the release branch. >>>>>>> >>>>>>> Going forward, we are using old/unmaintained plugins and need to >>>>>>> stop relying on them. There are two obvious choices: >>>>>>> >>>>>>> (1) use some "latest and greatest" Jenkins plugin - most likely the >>>>>>> multibranch pipeline plugin (aka Jenkinsfile plugin) >>>>>>> (2) use GitHub Actions >>>>>>> >>>>>>> I believe both of these will be comparable in migration effort. I'm >>>>>>> in favor of expanding our GitHub Actions usage to take over what we do >>>>>>> with >>>>>>> Jenkins. We have figured out how to have self-hosted workers, just like >>>>>>> we >>>>>>> do for Jenkins. I don't know what other pitfalls may exist. >>>>>>> >>>>>>> A good first step would be to bring the GitHub Actions precommits to >>>>>>> parity with the Jenkins precommits. >>>>>>> >>>>>> >>>>>> +1. After spending some time, these two plugins are not very >>>>>> compatible and migration to the new plugin would itself be a sufficiently >>>>>> large migration. We are using GH actions to an extent today and in >>>>>> general >>>>>> they were working fine. >>>>>> >>>>>> >>>>>>> >>>>>>> Kenn >>>>>>> >>>>>>> On Mon, Jun 13, 2022 at 9:44 AM Brian Hulette <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Can someone familiar with this clarify the current status? It looks >>>>>>>> like PostCommits and PreCommit_Cron jobs are still running on a >>>>>>>> schedule, >>>>>>>> e.g. [1,2]. Was the ghprb plugin (responsible from triggering jobs >>>>>>>> based on >>>>>>>> new PRs and comments) just disabled? >>>>>>>> >>>>>>>> If that's the case then we have a full suite of PostCommits, but >>>>>>>> the only precommit checks we have are GitHub Actions checks. These are >>>>>>>> pretty thorough, but off the top of my head a decent amount is missing: >>>>>>>> - No PyLint, PyDoc precommits >>>>>>>> - We can't trigger PostCommits before merge >>>>>>>> - Java build doesn't have null checker? (I know Jenkins java >>>>>>>> PreCommit turns on null checker, I'm not sure about GitHub actions) >>>>>>>> >>>>>>>> It would be painful to untangle the inevitable PostCommit breakages >>>>>>>> if we keep submitting code, so I do think a code freeze is in order, >>>>>>>> but >>>>>>>> it's a very inopportune time given the release cut is this week... >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> [1] https://ci-beam.apache.org/job/beam_PostCommit_Python38/ >>>>>>>> [2] https://ci-beam.apache.org/job/beam_PreCommit_Python_Cron/ >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Jun 12, 2022 at 9:04 PM Chamikara Jayalath < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Should we install a code commit freeze till this is addressed to >>>>>>>>> maintain code health ? I noticed that it's easy to miss certain >>>>>>>>> untriggered >>>>>>>>> test suites for new PRs. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Cham >>>>>>>>> >>>>>>>>> On Sun, Jun 12, 2022 at 5:25 PM Danny McCormick < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> In case anyone else is planning on taking a look at this, I did a >>>>>>>>>> deep dive on it and wrote up my findings here - >>>>>>>>>> https://docs.google.com/document/d/10qyUsvB_uVy5jftfTiwohlvN8Qwix5AuadssyoC4JsE/edit?usp=sharing >>>>>>>>>> >>>>>>>>>> My high level takeaways were: >>>>>>>>>> 1. I don't think this is actually caused by Issues, I think it's >>>>>>>>>> a structural issue with the plugin. At worst, Issues very minorly >>>>>>>>>> contributed to it (with a smaller impact than adding an extra build >>>>>>>>>> trigger >>>>>>>>>> would/did), but I'm not even sure that is true. As a result, our fix >>>>>>>>>> probably needs to focus on patching or switching to a new plugin. 2. >>>>>>>>>> Patching the plugin would be hard. >>>>>>>>>> 3. I agree that switching to a different plugin is the best path >>>>>>>>>> forward. >>>>>>>>>> >>>>>>>>>> If anyone else is looking into this and wants edit permissions on >>>>>>>>>> the doc, let me know! >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Danny >>>>>>>>>> >>>>>>>>>> On Fri, Jun 10, 2022 at 5:21 PM Kiley Sok <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> There's currently an issue with too many connections from >>>>>>>>>>> Jenkins to Github bringing down Jenkins. The hypothesis is that we >>>>>>>>>>> were >>>>>>>>>>> already close to the limit, but the extra triggers from GH issues >>>>>>>>>>> pushed it >>>>>>>>>>> over the edge. >>>>>>>>>>> >>>>>>>>>>> We're looking to switch to a different plugin that'll hopefully >>>>>>>>>>> resolve the issue. >>>>>>>>>>> >>>>>>>>>>> More info: https://issues.apache.org/jira/browse/INFRA-23358 >>>>>>>>>>> and in INFRA slack channel. >>>>>>>>>>> >>>>>>>>>>> Thanks for your patience! >>>>>>>>>>> >>>>>>>>>>
