Page Comparison

...

8. Arun S M — Today at 7:56 AM
It is also possible to run resource exhaustive CI checks on GitHub but on personal forks.
PR reviewers can request for this log in their review process

9. From Stephen via Discord TOC chat

1. FYI -- my brainstorming on CI/CD best practices. None of these are earth shattering but it took a long time to get these in place -- often because we didn't think of them, or there were not good examples to follow that fit our project. Even today, the different Aries sub-projects do these to different levels. My thought is that by providing a list, and pointing to repos on a per language basis to show what's been done, it will be easier for other projects to pick up these best practices.

2. Ideas: GitHub Practices

   • Protect the main branch, turn on DCO Protection
   • Require reviews on merges
   • Use GitHub setting to cancel test runs when irrelevant -- e.g. PR tests when a merge is done in the middle.
   Use GHA - CI Pipelines
   • Create a test pipeline executed on PRs before publishing
   • Include unit tests, integration test, linting/code style, static analysis and coverage reporting
   • Document how to run tests locally, run individual failing tests, and how to add tests of all types.
   • Where appropriate, implement pre-commit rules.
   • Try to circumvent test runs when updates are to documentation
   Release - CD Pipelines
   • Document a release process and automate as much as possible.
   • Create a changelog that is useful to developers, deployers and solicit feedback on the usefulness of the documentation. A simple PR list is generally not enough.
   • Define a release pipeline triggered when a release is tagged.
   • Publish packages to well-known places
   • Publish container images to ghcr
   • Publish a Development Release that reflects main
   • Create, Maintain and Publish per release documentation -- Documentation as a possible part of every PR

   
   

3. Another nice to have is to have infrastructure as code reference implementations to help people use Hyperledger projects in their environment -- e.g. encourage the creation of docker compose setups for local development, the use of devcontainers, the creation of Helm Charts for deploying components.

Tasks

•  Produce first draft of Best Practices document: Peter Somogyvari Stephen Curran David Enyeart 
•  Perform a general check-up of existing CI workflows for all graduated & incubated projects where the execution times are high: Peter Somogyvari
•   Evaluate possibilities for a self-hosted, open source alternative for BuildJet that could be powered by cheap AWS spot instances or other cloud providers with competitive pricing (such as Hetzner): Peter Somogyvari 
•   Investigate backstage.io Stephen Curran 
•  Favorite tools survey: Marcus Brandenburger Bobbi Muscara 

Links/Reading List

Chat Log

---

Dave Enyeart — Today at 11:16 AM
My feeling is to leave code coverage decisions to the projects. Especially when dictated from above, I've seen projects with high coverage metrics spend too much time on low-value tests trying to hit the goal, while not spending enough time on other important integration/system/user tests.
Project maintainers are in the best position to decide where to invest their test time and how much weight code coverage should carry 

...