Reputation: 107
In our CI/CD pipeline, we're looking for a way to do the CI part with cirle ci, the deploy part with Jenkins (technical limitations prevent us from deploying with circle ci).
We've created a branch per environment (testing, acceptance, production) and have jenkins jobs listening on changes on these branches and deploying them if applicable.
We would however like to add a tag to every commit that has passed the CI (e.g. "ci-passed") and check for this tag in the jenkins job. This to make sure crappy code can't be deployed.
We thought about creating dynamic tags (e.g. "ci-pased-{some timestamp}") but feel not sure about this, since this introduces a lot of tags. Is there any type of alternative to a tag that can be reused over different commits.
We know you can move tags, but we want to keep the tags on every commit that has passed the ci, so that any commit can be re-deployed at any time.
Any suggestions would be greatly appreciated.
Upvotes: 3
Views: 978
Reputation: 39824
Well, you're kinda setting yourself up for a conflicting requirement: on one hand you want to add a tag to every commit that has passed the CI
and on the other you're complaining that this introduces a lot of tags
:)
Personally for every commit that passes CI I'd:
ci-passed-{some timestamp}
tag - this would give you a historical/trending perspective and that ability to identify various deployable versions (assuming you eventually accept that this is what you prefer from the above-mentioned conflict)ci-passed-latest
(or similar) tag - giving you the most recent deployable version (typically the most common use case), without having to dig out which particular ci-passed-{some timestamp}
tag should be used.You could also expand this scheme by also encoding the environment in the tag name, to clearly identify what passed testing/acceptance/production (or any other stages may be added in your CD pipeline down the road) checks.
Upvotes: 2