...
GitHub Actions is the recommended CI platform, although use efficiently due to limits on number of runners, some ideas to limit runner usage:
- We are doing trials with BuildJet and faster GitHub runners (will report back)
- Use cancel-in-progress to suppress multiple jobs for multiple pushes to the same pull request
- Uncheck branch protection rule "Require branches to be up to date before merging" to reduce number of runs (potentially add a scheduled run if you are concerned about incompatible PRs getting merged)
- Use filters to eliminate unnecessary runs, e.g. doc PRs shouldn't require building and testing code.
- Consider running some jobs on schedule (nightly) rather than on each pull request (e.g. full matrix of platform tests)
- Inspect Github Actions run results on your own fork prior to opening Pull Request
Pull request checks
Unit tests
Integration tests
- Scans - see Security section, consider running on schedule (nightly) rather than on each pull request
- Be wary - just because a change passes checks doesn't mean it is necessarily good, it still requires judicious maintainer review
Test coverage reporting - run on-demand or nightly
- Keep CI clean and green at all times, address failures and flakes
See also proposed Automated Pipelines task force
...
Define repository settings in .github/settings.yml so that they can be managed and tracked via pull requests
Use recommended repository settings as a starting point, e.g. Repository options, Branch protection rules (TBD by TOC and Hyperledger staff)
Rebase merging is preferred over Merge commits and Squash merging to keep commit history and PR description clean (assuming contributors squash/amend their own pull requests) - opinion or best practice?
Although there are often multiple paths to achieve an outcome in git and GitHub, there is value in defining a suggested path, both for the benefit of new GitHub users, and for the sake of project consistency.
Examples - amending amend commits versus instead of squashing commits, Mergifyio to simplify cherry picks and backports.
Example guidance for forking, branching, remotes, creating pull requests, updating pull requests, cherry picking - https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html