Not better/cleaner, but different: you can cause a rebuilt with request coming to your webhook from github or some other place. And they can send it on new commits to master branch. I personally try to build the releases for all branches (not just master) on CI/CD pipelines.
Instead to rely on that single file with the version number, I’d go the same way that @idi527 proposed.
Run builds and tests on every push to your VCS, and for a limited set of commits depending on your branching model. At my company and in my personal life we use master as the branch for releases. Every tagged commit on master gets build as a release, and master is always buildable.
Thanks folks, really appreciate the feedback. I decided to go with triggering a build when a new tag is pushed. Turns out it was trivially easy to grab that information and write it to a file. Here’s the python script I’m using to accomplish the goal in case anyone else would find it useful:
That requires GitPython, which seems pretty available via packages. The last line just trims the ‘v’ off my tag, so I get ‘1.0.0’ instead of ‘v1.0.0’
Salt makes it trivial to run that script and write the output to a file, then ‘listen’ to that file for changes. When it changes, I read the new release number from it, and use it to automagically un-tar the new release to it’s deployment location – pretty slick…
Happy to post the Bash script I’m using to accomplish the rest of the work, since it did take me awhile to figure out all the gritty details.