Checks appear under a different workflow

[khaeru]

Thanks for the useful action! It works well, but I'm having trouble configuring it properly to overcome a minor weirdness in the effects. Perhaps this is just my limited knowledge of the API semantics.

I have two workflow files. In cq.yml (this is trimmed to illustrate the issue):

name: Code quality
# ...
jobs:
  lint:
    # Various stuff; doesn't use checks-action

In pytest.yml:

name: Test suite & diagnostics
# ...
jobs:
  pytest:
    # Job configuration that includes...
    steps:
    # Other steps
    - uses: LouisBrunner/checks-action@v1.1.1
      with:
        name: Upload historical database & diagnostics

See here: https://github.com/transportenergy/database/pull/64/checks

What I expect: that the check output appears under the "Test suite & diagnostics" section with the three other jobs corresponding to the file in which appears (the action is actually used within one of these jobs).

Instead, I observe: it appears under the "Code quality" section defined by the other file.

Is there a simple way to avoid this?

[LouisBrunner]

Hi @khaeru,

Thanks for your report. Unfortunately the only information the API accepts when creating a check is the SHA (see here).
I haven't tested it but I reckon GitHub assigns the check to the first workflow which ran for a given SHA?
Maybe you could manage to get the check on the right workflow if you made sure the first workflow to run was the pytest.yml one (not sure if you can put dependencies between them?).

Sorry, I can't think of another solution :/

[khaeru]

Maybe you could manage to get the check on the right workflow if you made sure the first workflow to run was the pytest.yml one (not sure if you can put dependencies between them?).

Hm, that's a good suggestion—thanks! Maybe it's alphabetical—cq comes before pytest, and thus that's the one to which it gets attached? In any case, I will give it a try and report the results.

I did peek at that documentation page, but despite being verbose it's not too illuminating (for me) about which fields are related to which parts of the workflow file(name), or how.

[khaeru]

Maybe it's alphabetical—cq comes before pytest, and thus that's the one to which it gets attached? In any case, I will give it a try and report the results.

This seemed to work: I renamed to 0-pytest.yaml and 1-cq.yaml. So it seems that whichever of the workflow files sorts first is the group (“suite”? The API docs are not clear) to which the checks from this action become attached.

Thanks again for the hint!

[rabernat]

Thanks for this great action.

I am experiencing similar issues with my workflow name. I have a matrix of checks I want to run based on a slash command in the PR comments. I have set up a slash-command-dispatch workflow to trigger a workflow via repository dispatch. That workflow creates a check and then updates it.

It works great! Example PR...

...Except the name of the check is picking up the name of one of my other workflows. 🤦

Here pre-commit is a completely separate workflow. Contrary to what was suggested above (#17 (comment)), this is not the alphabetically first workflow. The subsequent name ("Test Notebook") is the one I want.

Does this have to do with "check suites"? Is there any other possible workaround? Can I create my own suite?

[LouisBrunner]

According to the API you can create your own suite, but I didn't see from the documentation how that would help unfortunately...

This is a really odd behavior and I don't have any idea why this is happening, sorry :/

Maybe someone with more understanding of Github Actions might be able to help?

[edhgoose]

Hey @rabernat - did you ever discover a solution to this issue? I'm seeing the same - the checks are appearing in an unusual place in the UI for us too.