Automatic releasing of Terraform modules (mono-repo)

This article is a follow up of a previous article I wrote (Automatic releasing of Terraform modules (per-repo-module)). In that article, I detailed how to configure a repository containing Terraform, to automatically release a new semantic version when changes were committed via a PR using conventional commits.

This article will approach the same problem for a different setup, updating the semantic version for multiple Terraform modules stored in a repository.

As before, this article assumes that you already have your GitHub repository setup with multiple terraform modules written and stored in a structure similar to as below (with individual modules nested under a single modulesdirectory).

If you don’t have a repository that you can use to walk along with, you can use this demo repository: https://github.com/tjtharrison/demo-multiple-terraform-modules

.
├── README.md
└── modules
    ├── ec2
    │   ├── main.tf
    │   ├── outputs.tf
    │   └── variables.tf
    └── s3
        ├── main.tf
        ├── outputs.tf
        └── variables.tf

Photo by ian dooley on Unsplash

Repository configuration:

The setup is going to be slightly different this time, to keep the repository as DRY (don’t repeat yourself) as possible — We are only going to store two keys in the package.json in each module.

package.json

In each module directory within your repository, create a new file called package.json with the following contents:

{
  "name": "your-module-title",
  "description": "A short description, as to what your module does"
}

Now, we are going to use a GitHub workflow to programatically generate the remainder of the package.json file when a PR is merged to main (before semantic-release runs to release the new version).

The workflow:

We’ll create the GitHub workflow that will be completing the semantic releases for us first, as it will help to explain the reasoning behind the script that we’ll go through afterwards.

If you read the other article, you’ll recognise large portions of the GitHub workflow that we’re going to use in this repository.