Versions Compared

Old Version 60

changes.mady.by.user David Enyeart

Saved on

compared with

New Version 61

changes.mady.by.user David Enyeart

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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

    • DCO - Developer Certificate of Origin

    • 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


GitHub configuration and workflow

  • Define repository settings in .github/settings.yml so that they can be managed and tracked via pull requests, see Fabric example.

    • Use recommended repository settings as a starting point, e.g. Repository options, Branch protection rules (TBD by TOC and Hyperledger staff)

  • Consider using a CODEOWNERS file to specify write permission per directory, see Fabric example with additional /docs maintainers.
  • Consider using a PULL_REQUEST_TEMPLATE.md and ISSUE_TEMPLATE


GitHub workflow

  • 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
    • 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.