Keep Action status OFF PR?

I have a workflow which is set to on: push – that is, on any branch.

This alone seems to make it show up as a check/status on any PR. And if some of the jobs fail, the PR will show up as red.

I do want the workflow triggered on every push, including to a branch that may be in a PR – but I don’t actually want it it showing up in the list of checks on the PR, or effecting it’s green/red pass/fail status.

Is there any way to suppress it from showing up in the list of checks on the PR? Or does anything with on: push or on: pull_request just necessarily do that?

(If you’re curious what my goal is, it’s something resembling the travis allowed_failures. I want it to run, and I want it’s results to be available as a badge and in actions, but I don’t want the results effecting the check status of the PR. I thought I had something that would be workable for me, until I realized that on: push would wind up showing up as a PR status anyway! Now I don’t really understand the difference between on: push and on: pull_request, since on: push shows up on pull requests anyway!)

Looks like the API option auto_trigger_checks might allow you turn it off, granted that Actions actually use an app to trigger CheckSuites:

Good find, thanks! I will try that out.

perhaps a next step for my tentative vision of a allow_failure type check would be somehow posting the failure as a COMMENT on the PR, instead of in the check suite (I didn’t know that’s what it was called “check suite”, great).

Which I guess would require the action to figure out WHAT the corresponding PR is; and then post a comment to it. All using the API. Not totally sure how to do either one, but especially the first one (we have a branch ref provided in env; is there a way to use the api to go from branch ref to PR id?).

I might leave this for another day at this point though. I’m sure there would be more details arising too (say, avoid spamming with too many comments if it keeps failing, etc).

With on: pull_request it’s easy to determine the PR because it’s in the payload information.
It’s more tricky with on: push. You can find out the branch easily, but any commit can be part of any branch, so there is no clear mapping to pull requests. I’m actually not sure how GitHub correlates check runs to PRs if you push to their feature branches. Could be simply based on branch name I guess. You should be able to query the API for PRs by the branch name. I would only expect a single result, even though not sure if this is hard limitation or if there could be multiple PRs with the same feature branch but with different bases.

thanks that’s helpful.

With on: push (with no branch limitations), the statuses still, by default, somehow show up on PR('s?) that include the commit, so somehow github itself knows…

I guess if you can find out the branch easily, there is a pretty clear mapping from branch to PR (every PR has a branch, and GH last I checked won’t let you have two open PR’s for the same branch), so I guess that should work out, assuming relevant API’s are available.