Automating release builds via server config managment software

Been thinking about how to automate an Elixir release build via my server configuration management software (Salt).

The cleanest method I’ve come up with so far is to abstract the app’s version string into its own file, then detect when that file changes and trigger the release build.

Two questions:

  1. Is there a better/cleaner way to handle this?

  2. If not, what is the cleanest way to read the version string from this separate file? Digging around a bit, the only example I found was this:

    defmodule MyApp.Mixfile do
      use Mix.Project
      def project do 
        [
          app: :my_app,
          version: String.trim(File.read!("VERSION")),
        ]
      end
    end
1 Like

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.

1 Like

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.

1 Like

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:

import git

def run():
  repo = git.repo.Repo(git_repo_dir)
  latest_tag = repo.git.describe('--abbrev=0', '--tags')
  return latest_tag[1:]

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… :slight_smile:

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.

6 Likes