I wrote a series of articles about GitHub Actions. To:
- validate that no one submits code that breaks the build
- automate nightly deploy and update online documentation
The flow below shows the current setup.
Read it down to up, to understand what automations are happening during a development cycle.
- A developer that works on a new feature is never blocked. There are no automations, but they can run the existing validations manually if wanted.
- When the feature is tested by the developer, and deemed mature, the developer creates a pull request. At that time, the first validation kicks in:
If the code breaks the build, the pull request will fail.
A build break at that time would impact the whole team. Buggy code in your feature repo is OK. But when you consider your code "ready for upstream", it should build.
When that's successful, the development branch manager can accept the pull request and merge it to the development branch. - If that's successful, a new set of firmware binaries is built, and uploaded to the GitHub nightly release. (action, not validation)
- When it's time to cut a new release, the development branch manager will create a pull request from development to master. At that time, another validation kicks in:
If the code breaks the build, the pull request will fail.
A build break at that time would impact the next release.
When that's successful, the main branch manager can accept the pull request and merge it to the main branch
If that's successful, DoxyGen will re-generate the documentation, and publish it to github.io. (action, not validation).
Note: this approach doesn't slow down a developer while developing. They can check in incomplete or buggy code to the feature branch.
Developers should get the value of version control, and check in often. Without hurdles.
But it 'll ensure that when the job is (deemed to be) complete, due diligence is done before requesting integration into the official code base.
Link to all posts.