Once a check run transitions from the in_progress state to completed state, it’s not possible to modify its status nor its conclusion further.

But what about when a check run transitions from in_progress to stale? Can I modify the status then?

But what about when a check run transitions from in_progress to stale ? Can I modify the status then?

@danthedaniel - Great follow-up question!

Every check run has a status and a conclusion.

A status can be one of the following values: queued, in_progress, or completed. Unless otherwise specified, queued is its default status.

Here’s the order in which a status value can change:

• queued ➡️ in_progress ➡️ completed

If a check run’s status has a value of either queued or in_progress respectively, its conclusion value will be null.

Here’s why: it’s only when a check run’s status is updated to completed that a conclusion must be provided.

The value of conclusion can be one of the following values:

• success
• failure
• neutral
• cancelled
• skipped
• timed_out
• action_required
• stale (:warning: only GitHub can update a check run’s conclusion to this value.)

Thus, when a check run’s status’ value is completed and its conclusion's value is stale, it’s not possible to update that check run with a different conclusion.

If you have a specific use case for which you would find it helpful to update a check run’s conclusion after the conclusion has been determined, we encourage you to share that with our product team our official product feedback form. That’s the best place to share requests like these in consideration for future iterations of GitHub features.

Thanks for explaining!

Actually I have another follow up question. If a run is marked stale can I create a new check run (from the same app) on the same commit as the original check run?

Basically what I want is some way to be able to require a check run from my GitHub app even though it could take > 2 weeks to perform. The tool I’m planning to build would block merging a PR until a certain label is applied to all associated issues (if there’s another way to do this please let me know).

Actually I have another follow up question. If a run is marked stale can I create a new check run (from the same app) on the same commit as the original check run?

Because a check suite can have more than one check run, you should be able to create as many check runs from the same application as you’d like on the same commit. I’d be curious to see if that isn’t the case!

Basically what I want is some way to be able to require a check run from my GitHub app even though it could take > 2 weeks to perform. The tool I’m planning to build would block merging a PR until a certain label is applied to all associated issues (if there’s another way to do this please let me know).

Ahh, thanks for sharing that context! One of my colleagues developed a GitHub App called Semantic Pull Request that might be of interest:

zeke/semantic-pull-requests

🤖 Let the robots take care of the semantic versioning - zeke/semantic-pull-requests

Its sole purpose is to ensure that pull requests follow the Conventional Commits spec. It’s built on Probot, a framework for building GitHub Apps in Node.js. You could check out its implementation and possibly adapt it for your project.

I thought it also might be worth sharing––on a cursory search of Probot’s List of Apps, I noticed that there’s a pr_label_enforcer app that enforces certain labels on a PR before merging by using status checks (source @ https://github.com/fossapps/pr_label_enforcer). I can’t say that I’ve used that particular application nor am I able to provide support for either (since I’m neither a maintainer nor owner), but have used semantic-pull-requests in other projects and it works like a charm. 👌

I hope this helps as some helpful resources to check out as you go about with your project! 🙌

Thank you so much! I should have searched around more because PR Label Enforcer looks like just what I need.