- Use cancel-in-progress to suppress multiple jobs for multiple pushes to the same pull request
| https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-concurrency-to-cancel-any-in-progress-job-or-run |
- 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
| Via built-in GitHub YAML syntax: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging
Via third-party GitHub Action: https://github.com/dorny/paths-filter |
- Use filters to eliminate unnecessary runs
- Documentation PRs shouldn’t require building and testing code.
| https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet |
- Consider custom docker images for CI with pre-installed and pre-configured dependencies
|
|
- Consider running some jobs on schedule (nightly) rather than on each pull request (e.g. full matrix of platform tests, expensive security scans, code coverage)
|
|
- Inspect Github Actions run results on your own fork prior to opening Pull Request
|
|
- Contact Hyperledger staff for the possibility of dedicated paid runners
|
|
- Consider using development container images which come pre-installed with all the dependencies a contributor need to get started with writing code on the project.
| https://code.visualstudio.com/docs/devcontainers/containers |
- Consider leveraging pre-commit hooks via tools like husky (NodeJS) and lint-staged which can run arbitrary scripts at the time of you making a git commit.
| |