Enabling GitHub Checks
Last updated
Last updated
GitHub status checks are an excellent way to track and control the CI/CD status of your projects. AutoRABIT will send status checks for the pull requests to your GitHub repo and allows you to control when pull requests can be merged based on the results of the CI job. AutoRABIT reports the status of workflows and all corresponding jobs under the Checks tab on GitHub.
GitHub repositories registered in AutoRABIT should have the pull request feature enabled. [Learn More]
Protected Branches are a feature in GitHub which lets you block merging pull requests into specific branches unless status checks have passed.
If you’re a repository owner, you can update your repositories using protected branches to use status checks per the following:
Go to your repository’s Settings page.
In the left-hand menu, click Branches.
Under Branch protection rules either click Edit for a rule that you would like to change or click Add rule at the top to create a new rule.
If adding a new rule, enter the desired branch name in the Branch name pattern field.
Scroll down to the second box - Require status checks to pass before merging.
From the build status checks in the last week of your repository, select one of them.
Click Create.
The CI JOBS screen is best viewed when the zoom setting is set to 80% on your chrome/firefox browser.
Enable the checkbox: Status Check API for your GitHub Repo under the Build section while creating a new CI job.
Whenever the job runs, AutoRABIT will automatically post the build status back to GitHub, referencing the relevant git commit and the outcome of the job (success or failure).
If a user selects CI deployment job (build and deploy), status check API is updated in the final step, i.e., after the build is successful and the deployment is completed.
If a user selects CI job to build only, status check API is updated after the build is completed.
GitHub Status Checks API works on the Commit revision number but not on the Pull Request. It is to use the REST API to allow external services to mark commits with an error, failure, pending, or success state, which is then reflected in Pull Requests involving those commits.
Let’s take an example:
Let's consider three branches: A, B, and C.
If Branch B is configured in the CI job with status check API
Suppose we have created the Pull request between branch A and branch B. -> above created CI job is triggered automatically on revision number 1234567, which is the latest revision of branch A.
Status Check API is triggered on CI job build revision number 1234567, which means this revision is available in branch A. So, two Pull requests contain the same source branch, and that’s the reason it is showing in multiple pull requests.
After you enable the required status checks, your branch may need to be up-to-date with the base branch before merging. This ensures that your branch has been tested with the latest code from the base branch. If your branch is out of date, you'll need to merge the base branch into your branch.
The results of the deployment status in Github and the AutoRABIT application can sometimes be conflicting. While the deployment is still in progress in AutoRABIT, the status will be updated earlier on Github. This is due to the post-deployment activities being performed in AutoRABIT.
This outlines the functionality of the Status Check API based on the different statuses of CI Jobs. The Status Check API triggers different responses depending on the current status of the CI Job, as detailed below.
Status check API is triggered as "Pending" if the CI job status is "In progress".
Status check API is triggered as "Success" if the cijob status is "Completed," "Partial”
Status check API is triggered as "Error" if the cijob status is "Aborted".
Status check API is triggered as "Failure" if the job status is "Failed" or "Unstable."
If the CI Job status shows as "No Modifications" then the Status Check API should not get triggered at all.
