Continuous Integration (CI)
Continuous Integration (CI) is the name given to the process of assisting our PR checks and resolving uncertainty in code status.
CI checks are built and maintained by the BHoM CI/CD team, but are operated automatically by our CI systems (including, but not limited to, AppVeyor, Azure DevOps and associated bots1).
The aim of CI checks is to increase confidence in our code, without unduly hindering our ability to prototype, develop, and extend the BHoM.
The pages within this section detail the CI checks we currently have operating, so that everyone can see how the checks are running and help ensure their PRs pass the checks.
| Check | Provider | Command |
|---|---|---|
| Check Core | BHoMBot | Trigger by PR comment @BHoMBot check core |
| Check Installer | BHoMBot | Triggered by PR comment @BHoMBot check installer |
| Check Project Compliance | BHoMBot | Triggered by PR Comment @BHoMBot check project-compliance |
| Check Code Compliance | BHoMBot | Triggered by PR Comment @BHoMBot check code-compliance |
| Check Documentation Compliance | BHoMBot | Triggered by PR Comment @BHoMBot check documentation-compliance |
| Check Copyright Compliance | BHoMBot | Triggered by PR Comment @BHoMBot check copyright-compliance |
| Check Dataset Compliance | BHoMBot | Triggered by PR Comment @BHoMBot check dataset-compliance |
| Check Branch Compliance | BHoMBot | Triggered by PR Comment @BHoMBot check branch-compliance |
| Check Unit Tests | BHoMBot | Triggered by PR Comment @BHoMBot check unit-tests |
| Check Null Handling | BHoMBot | Triggered by PR Comment @BHoMBot check null-handling |
| Check Serialisation | BHoMBot | Triggered by PR Comment @BHoMBot check serialisation |
| Check Versioning | BHoMBot | Triggered by PR Comment @BHoMBot check versioning |
| Check Ready To Merge | BHoMBot | Triggered by PR Comment @BHoMBot check ready-to-merge |
| Check Compliance | BHoMBot | Triggered by PR Comment @BHoMBot check compliance |
| Check Required | BHoMBot | Triggered by PR Comment @BHoMBot check required |
Optional arguments
The following flags may be provided when requesting a check to request specific behaviour from the bot when running your requested check. One or more flags may be used at any one time - for example to trigger a full, forced, versioning check, you could use the command @BHoMBot check versioning -force -full. All flags are prepended by a dash (-). To see how an argument will affect a check, see the individual check page.
| Flag | Action | Example |
|---|---|---|
| -force | Requires a check to run even if it could be bypassed. For example, if a pull request does not change any CS or CSProj files, then the Versioning check may not run as it is time intensive. However, if you want to force the check to run, append -force to your request and it will run even if it could be bypassed. |
@BHoMBot check versioning -force |
| -quick | Requests that the check run in a shortened format if available. For example, the Versioning check can opt to only compile the code in the pull request if no other repositories are depending on the work, allowing for a quicker versioning check compared to the default which will compile all the code used by the installers. | @BHoMBot check versioning -quick |
Use of CI checks
Not all checks are required on all repositories or on all branches, depending on the lifecycle state of the repository. The table below indicates which checks are required for a given repository state.
| Check | Prototype | Alpha | Beta (develop) |
Beta (main) |
|---|---|---|---|---|
| Core |  |
 |
|
|
| Installer | |
|
|
|
| Project Compliance | |
|
|
|
| Code Compliance | |
|
|
|
| Documentation Compliance | |
|
|
|
| Copyright Compliance | |
|
|
|
| Dataset Compliance | |
|
|
|
| Branch Compliance | |
|
|
|
| Unit Tests | |
|
|
|
| Null Handling | |
|
|
|
| Serialisation | |
|
|
|
| Versioning | |
|
|
|
| Ready to Merge | |
|
|
|
1 See more notes on our approach to using and interacting with bots and automated processes as part of our Code of Conducts.