Summary:
- At present, PR checks, build and test are all performed through .github/workflows/build.yml.
- Releasing over various channels (website, homebrew, chocolatey...) is performed manually.
- Docker Build and Push Jobs have scope for improvement.
- These are currently based loosely on patterns described in:
- This pattern does the below:
- (a) Build and push by digest.
- (b) Leverage
docker buildx imagetoolsto write desired tags.
- This pattern is only required because if tag pushes are done concurrently, then identical multi-architecture tags are clobbered in a reverse race condition.
- NOTE. Be careful selecting from the available github actions runners. Some runnner instances may be incompatible with assumed toolchain.
- Docker images:
In lieu of a full implementation of github actions best practices, currently:
- Pull request checks use the pull_request event, as per best practices.
- Integration test steps, which require secrets, leverage the github context to avoid running where secrets are absent.
- Therefore, external fork PRs, which are the community contribution model, do not run integration tests. Strategically, we may funnel community contribution though a staging branch and/or adopt release branches. This is not an urgent consideration, and we shall decide after some reflection.
According to this swagger-codegen example, it is not overly difficult to generate python mocks from openapi docs. This can then be used for credible regression testing against new provider docs and certainly the relationship of endpoints to stackql resources. Know weakness: will not detect defective transform from source (eg: MS-graph, AWS) to openapi.