Specify check suite when creating a checkrun

[jwgmeligmeyling]

When creating a check run through the API, a check suite is newly created unless a check suite for the requesting application has already been made, in which case that check suite seems to be reused.

This leads to issues however: due to Github Actions workflows, and each Workflow Run (workflow/event) having its own check suite, multiple check suites may exist for a given commit SHA. As a result, annotations generated in a Github action during a step executed in the “pull request” event, end up in the “workflow” for the "push’ event.

Through hoops, it is possible to find the check run ID during a Github Action: one can look up the Workflow Run by the run_id and then extract the Check Suite ID from the checkSuiteUrl. However, there is no way to specify the Check Suite ID when creating a new check run (its ignored in the request) and neither there seems to be any dedicated endpoint for creating check runs for a particular check suite.

It would be great if it were possible to more easily find the corresponding Check Suite for a Workflow Run, and if it were possible to create Check Runs for this particular Check Suite rather than have one picked “randomly” for you.

See also the issue thread jwgmeligmeyling/pmd-github-action#4 and proof of concept code in jwgmeligmeyling/pmd-github-action#3

[francisfuzz]

jwgmeligmeyling:

It would be great if it were possible to more easily find the corresponding Check Suite for a Workflow Run, and if it were possible to create Check Runs for this particular Check Suite rather than have one picked “randomly” for you.

@jwgmeligmeyling - Welcome back to the Support Community and thanks for this feedback! 🙇‍♂️

After reviewing your particular case, I’d like to confirm here that it is not currently possible to create a check run associated with a particular check suite with the GitHub Actions-provided GITHUB_TOKEN. I acknowledge that it is something that would be valuable given your use case.

We’re always working to improve GitHub and the GitHub Support Community, and we consider every suggestion we receive. Would you mind submitting this through our official product feedback form so that our product team can track your request? That’s the best place to share requests like these in consideration for future iterations of GitHub features, including Actions.

[carlspring]

@francisfuzz ,

Ping? Please, see the comments below.

[ghost]

@francisfuzz
Ping?! Please, see the comments below!

[samus-aran]

Hi @ruben-hoenle-fnt 👋

Thanks for sharing and we appreciate your patience. You can check our public roadmap to see the kinds of work we are focusing on for the coming year. Smaller fixes won’t be listed, but are often included when work is happening adjacent to it.

While it has been a while since we have updated on this thread, the absence of an update is simply that - there has been no update because there is so far nothing to report. That doesn't mean it isn't being worked on - it might simply be that we're unable to share details about work that isn't ready for release.

As a GitHub user, the most you can do is to share your feedback on this Discussion space with the correct tags (include examples), and trust that we are always working to make GitHub as awesome as possible. We can't guarantee that every bit of feedback sees action, but we are paying attention.

[jwgmeligmeyling]

Thanks for your response! I’ve submitted the product feedback form.

[bewuethr]

Is it really useful to copy-paste ChatGPT answers here ("last knowledge update in September 2021")?

[queenofcorgis]

@Akashh2151 While we encourage non-AI answers to questions in community, we also love experimenting and using new technologies. We ask if you do use ChatGPT or similar programs, please disclose what software and model version number you used to generate the response you used in your reply in order to promote transparency in the community.

ChatGPT answers in a tone that sounds like a tech support professional and while we support trying out this software, it is important to verify that they are solutions before posting otherwise it may mislead users into thinking that they are receiving official responses when they are not.

Per ChatGPT's website, the program does have limitations like:

• "May occasionally generate incorrect information"
• "May occasionally produce harmful instructions"
• "Limited knowledge of world and events after 2021"

[jwgmeligmeyling]

So instead of reporting this junk as spam we encourage it and ask for the version number? This whole thread is getting more insane by the day.

[EnricoMi]

Is this product feedback submitted by @jwgmeligmeyling publicly visible? What is the best way to track progress of this issue?

[jwgmeligmeyling]

No I don’t think its publicly available. I didn’t receive any response as well. I’ve filed another support ticket, maybe that gets things going.

[francisfuzz]

@EnricoMi - Great question! Because product feedback submitted through this form isn’t publicly visible, it’s not possible to track its progress. However, it may be worth sharing that our team announced the GitHub public roadmap to give everyone more transparency into what each of our teams are planning and to help everyone understand our product vision. It’s publicly viewable if you’re interested in following what our team is working on next, though it doesn’t currently show any feedback submitted from that form. I hope this helps!

[jonico]

It might be worth trying out to use the token of a separate GitHub App when creating the check run. Here is an action that retrieves a temporary token from a GitHub App created just for this purpose: https://github.com/peter-murray/workflow-application-token-action

[NasAmin]

Yes I have the same problem.
When you have multiple workflows triggered on a pull_request event and one of the workflows is creating check runs using the Create Check API, the check runs end up randomly in one of the workflows.

I have also submitted a suggestion on the feedback form.

[dobegor]

@francisfuzz is there any update on this issue? I wasn’t able to find it on the roadmap you’ve mentioned.

[eblot]

I was expecting to use several runners to perform distinct, unrelated checks, but the results appear in a randomly picked workflow tab. Is there any known workaround for now? Thanks.

(note: it sounds weird to have this thread flagged as “solved” :-))

[francisfuzz]

@dobegor - I don’t have any updates to share on my part nor am I able to provide any in the future. The public roadmap is still the best place to keep up with upcoming features.

[lukash]

Hello @francisfuzz, this seems to be a “minor” bug from the roadmap PoV, and is unlikely to ever be listed there. Hence this response from you is not really useful at all, as we don’t even know whether the issue is still being tracked by Github internally or it just “fell through the cracks”.

It’s a shame especially because at least on the surface this seems like it should be an easy fix to actually use the Check Suite ID. For my use case it’s causing this: Report check item appears under the wrong workflow name · Issue #39 · ScaCap/action-surefire-report · GitHub and again, it’s a shame, because that action allows reasonable and very simple test result reporting via workflow annotations, which is clear and easy to find/read even by outside contributors. There are very few options with regards to test result reporting that don’t require outside resources!

I have submitted another feedback form for this, hopefully it can get some more attention. Thank you.

[thegecko]

This issue makes it difficult to locate checks for specific workflows and is serious enough for us to consider moving away from GH actions 😦

[inket]

This is a BREAKING issue for GitHub Actions, and it’s honestly mindblowing that it’s come down to “submit feedback and get no answer”. We have zero acknowledgment that our feedback was even seen by anyone working on GitHub Actions.

It’s especially sad since we all know this would be a very easy fix. You can literally put an intern on it they’ll get it done in less than a day.

[radiomix]

It reminds me of the old 🪟 behavior It's not a bug. It's a feature

[jwgmeligmeyling]

Sad to see this was still not communicated to the appropriate folks. It is a trivial fix. A dozen people have requested this feature.

And annotations are practically useless as it is.

Someone made a stinky API decision and successfully managed to sweep it under the carpet. Of course we want to be able to specify to which check run annotations should be added, rather than have one picked randomly for us! It’s just common sense.

[MostefaKamalLala]

This is seriously needed by my team. We moved to github actions and we are even paying for the service. We cannot have test results, annotations spread all over the place randomly. When will we get an update on the API?

[alexmaurizio]

It is now May 2024 and this trivially fixable problem still plagues the whole GitHub Actions ecosystem.

I'm definitely baffled.

[bfollonikea]

Encountered this issue recently. Sad to see this thread was open in 2022 and the problem still exists.

[mashedkeyboard]

Just encountered this myself and spent a solid ten minutes staring at the code, the workflow run, and the GitHub support form, before finding this discussion... this seems bizarre! Adding a voice to ask for this to be fixed please.

[eXorus]

Same for me, I had to redo all my code to account for this bug.

[br3akzero]

+1 experiencing this issue with this awesome eslint action helper ataylorme/eslint-annotate-action#35

[diegopalat]

Any news on this topic?

[radiomix]

I came across the issue and first looked at this post in 2022. ⏳

Recently we configured GitHub Advanced Security to trigger CodeQL runs. ✔️

Sadly they and up with the status of our maven-surefire check. ❌

Maybe I need to ponder a workaround 🤔

[mdreano]

I just found this post, I spent sometime trying to configure my workflow only to finally understand that it is a bug.
Any update would be appreciated although I understand it may not be a major issue and priority for github team.

[man1207]

Still not fixed

[nguyta02]

do we have any future plan to fix this issue ?

[tanin47]

I just also encountered this issue which would be solved by this capability : mikepenz/action-junit-report#1361 (comment)

[thompsonjared]

This is also an issue for me, had check runs & code annotations working exactly as I wanted in my deployment pipeline.

Then I enabled automatic dependency submission to take advantage of GitHub dependency scanning...which introduced a 2nd workflow run on the same commit.

End result my deployment workflow check runs mysteriously disappear from the workflow they were created from and instead show up in the automated GitHub security workflow run.

GitHub is 99% of the way towards make this a great feature for actions, and then it's just fumbled on the 1 yard line.... with apparently no progress on the issue for 5 years of comment history.

[hrkh]

We're also experiencing this issue where Check Runs created via the API are being linked to the wrong workflow, especially when several workflows run for the same commit. This makes tracking our CI processes more difficult than it should be.

To resolve this, it would be extremely valuable if the API allowed us to specify check_suite_id when creating a Check Run.

[lewis-jackson-bots]

Just tripped up on this too after a day of trying to figure out why it wasn't working. We're trying to avoid running ~20 test shards by posting skipped (successful) checks in certain scenarios.

Running 20 jobs for <2 seconds each to get a successful check costs us 20 minutes of GitHub action runner time as the minimum is 1 minute.

[zuzusik]

Facing this issue as well. If a pipeline is run more than once for commit, then all the subsequent checks created via API with GITHUB_TOKEN are attached to check suite created with the first run. This results in inability to merge PR if check is marked as required, as checks end up being attached to the stale check suite.