Terraform Module Versioning for Git Sources

TL;DR — set up a Github Action to override v1 and v1.2 when tagging v1.2.3, then be able to specify either v1 or v1.2 in Terraform.

Developers who use Terraform have been looking to use Semver for modules hosted privately in Git repositories. Although the feature request has been open for years, Hashicorp won’t in my opinion fulfil it any time soon as it is likely part of their business model to redirect companies to use a private registry with Terraform Cloud (20$/month/user).

Now that DAZN have fully moved to Github Action, we came up with a simple solution to use TF + Github + Semver, thanks to a Github Action. The idea is to create and override new major and minor versions every time a full tag is created. This is done on the CI and independently from TF. Then, one can specify major or minor versions to retrieve the latest tag, for example:

module "ecs-service" {
    source = "github.com/getndazn/terraform-module-ecs?ref=v1"

rather than constantly upgrading:

module "ecs-service" {
    source = "github.com/getndazn/terraform-module-ecs?ref=v1.2.3"

On the Github Action side, we are using haya14busa/action-update-semver@v1 on every module repository. It’s just one file that triggers when creating a new tag. Example usage:

# .github/workflows/update_semver.yml
name: Update Semver
on:
  push:
    branches-ignore:
      - '**'
    tags:
      - 'v*.*.*'
jobs:
  update-semver:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: haya14busa/action-update-semver@v1

Pros

• it’s free
• solves the problem
• works with any TF version

Cons

• plan/apply won’t show which version is deployed, but one can always check when a tag was created in comparison to the deployment time
• all module repositories need to use that Action — it can feel repetitive but could be part of your own module template
• if you’re not using Github Action, you will have to look for or create a similar solution for your own CI (which sounds fun to write)

About 20 modules/repositories are now using this Action at DAZN. It’s still up to teams to decide how/if they want to use it.

Let us know in the comments if you can think of ways to improve this workflow or if you just found a different solution.