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

## Chat Log9. 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 

...