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 <kiley...@google.com> 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 <rob...@frantil.com> 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 <al...@google.com> wrote: >> >>> Thank you all for working on this. >>> >>> On Mon, Jun 13, 2022 at 10:09 AM Kenneth Knowles <k...@apache.org> >>> 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 <bhule...@google.com> >>>> 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 < >>>>> chamik...@google.com> 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 < >>>>>> dannymccorm...@google.com> 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 <kiley...@google.com> >>>>>>> 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! >>>>>>>> >>>>>>>
