Hello! I’m trying to figure out how to implement an automated version tagging system we want. We’re trying to tag the relevant Github commit when a build successfully completes on master. I’ll split it into two phases:
First off, I’m having some difficulty with this basic functionality. The workflow definition seems easy enough, but I’m not sure about the actual implementation. Can anyone point me to an example config.yml that does it?
Secondly, I’d like to assess the feasibility of a more sophisticated implementation. We’d like to format each tag along the lines of YYYY.MM.DD.N, where N represents the Nth build of the day. Further, we’d like to avoid identical builds with multiple different tags, so ideally we’d find the previous tag and make sure it’s associated with a different commit hash.
Thoughts are appreciated and I hope this isn’t too elementary to address here; I’m a CircleCI novice.
The workflow definition seems easy enough, but I’m not sure about the actual implementation. Can anyone point me to an example config.yml that does it?
Sorry if this is obvious, but CircleCI itself is not able to create tags, so any solution would require calling some script to create and push the tag to GitHub.
This addresses your second question as well. Since you would be using some other script you could make it as complex or simple as you need.
A follow-up. While I think I got this figured out for Bash, we’d prefer to use Ruby instead. Try as I might, I can’t see how to invoke a Ruby script from the config. I imagine it’s something like command: ./.circleci/my_script.rb, but I don’t know how to set up the Ruby code from there. Will I still have access to environment variables as I did in the YML directly?
Generating a date for the tag should be doable whether you are using bash or ruby. I don’t know how you’d determine the Nth build for the day without hitting the CircleCI API with a script and counting. However, Circle does give you the CIRCLE_BUILD_NUM environment variable that you might consider using in your tag.
Usually the working directory for your build is the checkout location of your project. So if my_script.rb is in the root of your project, then you could probably just run it like this: