Impossible to retrigger jenkins via checks api on main due to CD workflow spamming

[jetersen]

https://github.com/jenkinsci/bom/blob/659a6b62a1ad4888a08d2cfd83042ed1e7486c16/.github/workflows/cd.yaml#L6-L8

This seems to spam +100 cd workflows making the jenkins checks disappear in the mists.

blocking release of #558 because no power to trigger rebuild on ci.jenkins.io

[jetersen]

makes more sense to use check_suite as we can look at the completeness of the Jenkins CI.

Should be able to use something like this to do the same thing the verify ci does...

    if: github.event.check_suite.app.name == 'Jenkins' && github.event.check_suite.conclusion == 'success'

[timja]

Give it a go, I've added you to https://github.com/jenkinsci/jenkins-infra-test-plugin if you have time to test it out, that's a complete test plugin that should have no real installations, used for testing this sort of thing

[bstopp]

Where would this go in the cd Workflow? Something like?:

validate:
  if: github.event.check_suite.app.name == 'Jenkins' && github.event.check_suite.conclusion == 'success'

[jetersen]

@bstopp https://github.com/search?q=event+check_suite+path%3A.github%2Fworkflows

[jglick]

This was the best I could come up with in JEP-229 given that there are limited trigger options—you cannot specify the check name or conclusion you wish to use as a trigger. https://github.com/jenkins-infra/verify-ci-status-action/blob/6dd04d9f67d59b0c336b9d79c3f90048df19008e/run.sh#L18-L34 is the workaround. Much clumsier than, say, Jenkins’ own ReverseBuildTrigger.

[jetersen]

@jglick perhaps we can go the other way since Jenkins already knows the GitHub app token. Perhaps you can use a repo or workflow dispatch from jenkins to trigger the github action?

https://github.com/peter-evans/repository-dispatch/blob/main/src/main.ts https://github.com/benc-uk/workflow-dispatch/blob/master/src/main.ts just in a jenkins shell script or nodejs something

[jglick]

Jenkins already knows the GitHub app token

Yes but I presume—hope—that the App in question lacks permission to trigger workflow runs.

[jglick]

blocking release of #558

Is there a specific reason this is important to release? If so, just change its labels so it is marked as a bug, Release Drafter should pick that up whenever something next merges, and the automatic deployment should happen.

[timja]

The master build failed on ci.jenkins.io and without a green build it won't release.

and you can't re-trigger it via checks because there's so many of them that GitHub hides the button: https://github.com/jenkinsci/bom/runs/2836762274

There's probably an api / gh cli command you could run instead though

[jglick]

https://github.com/jenkinsci/bom/releases/tag/876.vc43b4c6423b6 got released already. Should this be closed or are we keeping this issue open to try to solve the same problem for the future?

[jglick]

This feels like a GUI bug in GitHub Actions rather than something we should be trying to work around.

[timja]

It's a general issue not the first time it's happened, the 'fix' currently is to merge something else and hope it passes.

and yeah seems to be a gui issue, and likely can be worked around via API / CLI

[jglick]

https://cli.github.com/manual/gh_run_rerun ?

[timja]

cli.github.com/manual/gh_run_rerun ?

Doesn't work, that only shows GitHub actions not other check_runs

[jglick]

Would block #1993 but I think you can just use the Re-run checks dropdown.