DRAFT DOCUMENT - Best Practices for Automated Pipelines

Protect code branches. In GitHub settings “Branch protection rules” select:

“Require a pull request before merging” “Require approvals”	https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging
“Require status checks to pass before merging”	https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging

GitHub Actions is the preferred CI platform to implement checks. Create a test pipeline, consider required checks for:

DCO (required)	https://github.com/apps/dco
Linters
Unit tests
Integration tests
Code coverage
Documentation	Example - ReadTheDocs webhook: https://docs.readthedocs.io/en/stable/integrations.html
Static analysis aka Static Application Security Testing (SAST)	Example - CodeQL: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-with-codeql Example - Snyk: https://docs.snyk.io/integrations/git-repository-scm-integrations/github-integration
Software Composition Analysis dependency scans And/or setup Dependabot in Settings/Security	Dependabot: https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates
Note: use Reusable github actions to reduce the number of top-level checks	https://docs.github.com/en/actions/using-workflows/reusing-workflows

Use GitHub Actions efficiently and reduce unnecessary runner usage:

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	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
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.	https://www.npmjs.com/package/lint-staged https://www.npmjs.com/package/husky https://www.npmjs.com/package/@commitlint/cli

Where appropriate, implement pre-commit rules (Stephen Curran can you clarify?) - Peter: I've added an item above for what I think this means. (If it's not a match, we can add more/different items of course)

Encourage developers to run tests locally before opening a pull request.

Document how to run tests locally
Document how to run individual failing tests
Document how to add tests of all types.