CircleCI now integrates with the GitHub Checks API, so you can see the status of your CircleCI workflows under the Pull Request Checks tab in the GitHub UI. Previously in the GitHub UI, users could only see the status of individual CircleCI jobs for a given pull request - there was no way to see the status of the workflows to which those jobs belonged. With checks enabled, users will now be able to go to the Checks tab in GitHub to view the full hierarchy and status of CircleCI builds.
Enabling GitHub Checks in CircleCI
Important - You cannot enable GitHub Checks for CircleCI from the GitHub UI, you must log into CircleCI and enable checks for your organization. You must have admin privileges for your organization to enable checks.
Once you’ve installed checks for a repository running CircleCI builds, you will see a CircleCI “Check Suite” appear on the Checks tab for open pull requests in that repository. In the CircleCI check suite, you can see the status of your workflows and the status of the jobs within each of those workflows.
Should you need to restart any of your workflows, you can click the rerun icon to rerun the workflow from the beginning. You can also rerun the entire CircleCI check suite, which will rerun all of the project’s workflows from the beginning. More advanced functionality such as rerunning workflows from failed, or running jobs with SSH, is still only accessible through the CircleCI app, not through GitHub Checks. You can go directly to CircleCI from the GitHub Checks tab by clicking View more details on CircleCI Checks .
@KunalJain I’m very excited about this! Can you clarify the wording below?
Enabling this feature will turn off status of every pushed commit with GitHub’s status API.
Because this setting is at the company level, if we enable CCI Checks on “Only select repositories”, will statuses continue working on the ones that don’t have CCI Checks enabled? Some of our repos have automation that rely on statuses working and I wouldn’t want to break those.
Because this setting is at the company level, if we enable CCI Checks on “Only select repositories”, will statuses continue working on the ones that don’t have CCI Checks enabled?
That is accurate. Checks status will be posted on the repositories that you have selected. All repositories that don’t have Checks enabled will use GitHub’s status API.
I would like to give you guys a huge compliment on this new feature. My workflow has 170 jobs and about 100 of them starts in the beginning. As a result, we run into Github API rate limit from the beginning (70/second). So the Github status used to be incomplete until all 170 jobs finish. Now I only see 2 lines for 2 workflows in the PR status and the all the jobs on Checks tab.
You guys just solve one of the biggest headaches I have when running our huge monorepo on your platform. Good job. Keep up the good work.
The upload-coverage job finished 16min ago, but I still see it as “Running” in the GitHub Checks page, am I missing something?
Thank you so much for reporting this issue. We are actively working on resolving this issue. I will update you as soon as we roll out a fix. Thank you so much for your patience.
Thank you so much for reporting this issue. We are actively working on resolving this issue. I will update you as soon as we roll out a fix. Thank you so much for your patience.
@KunalJain looks like this is already solved, thanks! At least, the latest workflows finish correctly
Other issues/improvements: the information is now a lot of clicks away. Could you make the job names link to the actual job on CircleCI? Also, with a long list of jobs it’s hard to visually differentiate which jobs are running/blocked/succeeded:
It’d be nice if we had some kind of visual feedback on each job to see the status. I don’t know if the HMTL can be really customized, but as a fallback you could use emojis as feedback indicators (eg. for succeeded, for enqueued, for failed jobs, etc).
Also, for failed jobs: is it possible to show the output? Something like the screenshots in the GitHub announcement:
While I’m appreciative of the work completed thus far for this feature, the quality of the releases has not been great to date.
My experience thus far has been:
Yesterday
individual commit statuses not reported to by workflow jobs
pull request checks updated by workflow jobs
Today
individual commit statuses reported to by workflow jobs
pull request checks not updated by workflow jobs
This doesn’t give me any confidence in committing our full workload onto CircleCI’s GitHub checks for a while, at least until I can see it working as expected consistently.
We are rolling back the move in our organization and going back to the old status checks API, s this feature seems to be half-baked yet and data is not fully reliable as of now.
I’ll monitor this thread and might come back to this in the future.
Similar issue with a workflow in “on-hold” status which I cancelled manually. Still “in progress” in the “CircleCI Checks” Github UI after some minutes.
I’m pretty excited about this. It looks like the first iteration is pretty bare bones in the way information is presented. I think it would be amazing if we could have something similar to the example in the Github blog post.
In this case, Super-CI is the workflow name. And the sub-jobs there are the jobs in the workflow.
Being able to go directly to the CircleCI job page from there would be nice ( which is what the Details link does in the current status checks implementation ).
Also, It would be amazing if we could Rerun from failed directly from the github checks page.
We did initially think about mapping Super CI to a workflow and core-app-tests, syntax-liner and visual-diff as jobs. The challenge we ran into was how to model multiple workflows within a configuration file. Current implementation handles that case by mapping each core-app-tests, syntax-linter and visual-diff as workflows rather than jobs. This helps customers who have multiple workflows to use the checks functionality. There is no way for us to switch functionality if customers only have one workflow in their configuration file.
Regarding, Rerun from failed functionality. GitHub’s API does not provide a way to pass varying levels of rerun. We are happy to add support for it if we can get granular control via their API.
Hmm. I assumed multiple Super CIs would be possible. Is that not the case?
Regarding Rerun from failed, It might make sense to make that the default option. The re-run concept is to re-run a failed job. But with workflows, because you cannot re-run an individual job without losing coherency with the workflow, you’re forced to wait for the workflow to finish and then press Rerun from failed. Also, it just makes sense that you’d want to re-run something that failed, rather than that thing and a bunch of other things that already passed.
for succeeded, 
for enqueued, 
for failed jobs, etc).
