How can I attach a manual workflow run to a pull request's status checks?

Question

I have a workflow which runs a test job under given circumstances automatically, or I can run it manually:

name: Test

on:
  workflow_dispatch:
    inputs:
      used-branch:
        description: Branch the test shall be run on
        default: master
        required: true
  push:
    branches: ['main', 'master']
    tags: ['!**']
  pull_request:
    types: [opened, reopened, ready_for_review]

jobs:
  test:
    steps:
      - name: Checkout selected branch
        uses: actions/checkout@v3
        if: inputs.used-branch != ''
        with:
          ref: ${{ github.event.inputs.used-branch }}
      - name: Checkout current branch
        uses: actions/checkout@v3
        with:
          ref: ${{github.ref}}
        if: inputs.used-branch == ''
      - name: Run test
        ...

I want the test be required before merging. So I check Require status check to pass before merging, Require branches to be up to date before merging and specify test as required job in the repo's branch settings.

The problem is: when I run the workflow manually (and therefore inject the branch via a variable), it's not related to the branch and its success won't be "discovered" by the PR checks.

Is there another way to link the run to a branch, or another way to propagate the result to the branch's pull request?

I 100% understand your question and once you start to work around GitHub's API design things get complicated. My best guess is you will need to resort to using the API when running manually... see: https://github.com/orgs/community/discussions/24616 & https://docs.github.com/en/rest/checks?apiVersion=2022-11-28 & https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks — aknosis, Dec 20 '22 at 22:54
@aknosis Thanks for your response! So there's no "configurable" way to achieve this right now. Well, if that's the answer, then feel free to provide it and I will accept it! I don't see myself tinkering with API for now, I think. A workaround is closing and reopening the PR, and maybe I find a even less wonky way (`pr_comment` don't exist either, sadly) for the time being. :) — NotX, Dec 21 '22 at 09:23
`pr_comment` events are handled via `issue_comment` because pull requests are just issues with code... https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_comment-use-issue_comment — aknosis, Dec 21 '22 at 19:14
@aknosis Oh, I see. After skimming briefly over this topic I thought it would mean a comment in a _referred_ issue (for my defense, I hadn't the time for a proper read yet). So thanks for your clarification, maybe that's a good compromise to head for! — NotX, Dec 22 '22 at 09:49
I've spent the last six months buried in GHA so I have got all the bruises from learning it :) — aknosis, Dec 22 '22 at 21:11

score 0 · Accepted Answer · answered Dec 21 '22 at 19:12

0

Took me a minute to digest what you were asking, but now I get it. (Updated title to be more precise).

Short answer, it isn't possible out of the box. Once you start to work around GitHub's API design things get complicated.

The only plausible solution I can think of today is via GitHub API.

See:

answered Dec 21 '22 at 19:12

aknosis

3,602
20
33

> The only plausible solution I can think of today is via GitHub API. could you expand on this? – develobster Jun 02 '23 at 09:31
@develobster I haven't explored the checks api before, but essentially you need to map all non `pull_request` triggers to a PR and then use the api to set the proper status on the PR. – aknosis Jun 02 '23 at 22:58

score 0 · Answer 2 · answered May 27 '23 at 10:07

0

Not a real solution, as GitHub doesn't support this as you observed, but a workaround is to trigger the workflow from something that happens with the pull request. E.g. it can be triggered when a label is added to the PR (like "run-tests") or the PR is approved (which needs a combination of a trigger and job condition). A special comment would work as well, though that's less intuitive.

While these are not exactly the dispatch trigger you asked about, but I think they cover the "run workflow manually" use-case.

answered May 27 '23 at 10:07

Piedone

2,693
2
24
43

Hey, not sure all of this would work, though. I tried an approach where a `\test` comment in the PR triggered the tests, but this didn't update the checks either. For now, I'm switching a PR to `Draft` and back, which triggere a workflow that get actually recognized, similar to what you've suggested. – NotX Jun 01 '23 at 15:50
@NotX these should work. How does your jobs look like? anyway, I know you said it triggered the tests, but tests that are triggered by `issue_comment` event will only be triggered if the workflow file is in the main branch ([source](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment)) – develobster Jun 02 '23 at 09:37
Yep, we actually use the label approach; first tried the PR approval one what also works but we didn't like it for other reasons. – Piedone Jun 02 '23 at 11:30
@develobster You're right, I did some adjustments and it's working. So now a `/test` comment in the PR triggers a workflow whose result is detected by the PR's status checks. – NotX Jul 07 '23 at 15:43

How can I attach a manual workflow run to a pull request's status checks?

2 Answers2

Linked