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