we've implemented a new ci delivery pattern for the kubefirst ecosystem that can help deliver to a new test rig in our internal gitops ecosystem. the process is now for the microservice to publish its own chart, then bump the macro chart's rc version and publish the macro chart. this isn't new, but what is new is that it will tag the macro chart repo (charts) in order to kick off a new ci pipeline responsible for the proliferation of the new macro chart. this used to be the responsibility of the microservice, and that ownership is shifting to the charts repo. the trigger will start subscribed to the convention kubefirst-v*-rc* which matches our typical prerelease convention.
Related Issue(s)
Internal CI shift to support automated test environment
How to test
main branch update should start the process in this repo's github actions. once the macro chart has been published, the remaining ci will deliver from the charts repository's github actions:
https://github.com/kubefirst/charts/actions
Description
we've implemented a new ci delivery pattern for the kubefirst ecosystem that can help deliver to a new test rig in our internal gitops ecosystem. the process is now for the microservice to publish its own chart, then bump the macro chart's rc version and publish the macro chart. this isn't new, but what is new is that it will tag the macro chart repo (charts) in order to kick off a new ci pipeline responsible for the proliferation of the new macro chart. this used to be the responsibility of the microservice, and that ownership is shifting to the charts repo. the trigger will start subscribed to the convention
kubefirst-v*-rc*which matches our typical prerelease convention.Related Issue(s)
Internal CI shift to support automated test environment
How to test
main branch update should start the process in this repo's github actions. once the macro chart has been published, the remaining ci will deliver from the charts repository's github actions: https://github.com/kubefirst/charts/actions