Hands on: Managing Terraform Modules with GitHub Actions

Hands on to Automate your Terraform module releases with GitHub Actions

Introduction

Welcome back, everyone! I hope you had a chance to check out my first article on managing Terraform modules with GitHub Actions. If you haven’t, you can read it here. In the first part, we explored how GitHub Actions can automate the release process of Terraform modules within a mono repository, leveraging Conventional Commits and Release Please Action.

Conventional Commits play a pivotal role in our automated release process, especially when paired with the powerful Release Please Action. They provide a structured way to communicate changes in the codebase. This structured approach allows Release Please to understand the nature of the changes and automate versioning, changelog generation, and GitHub releases seamlessly.

In this article, we will focus on three essential Conventional Commits types: feat for new features, fix for bug fixes, and feat! for breaking changes. Understanding how these commit types interact with the Release Please Action is key to efficient version management and clear communication within the development team.

Let’s dive in and explore how Conventional Commits take full advantage of the Release Please Action for streamlined development workflows and transparent collaboration.

1. feat: New Features

The feat commit type is used to indicate the introduction of a new feature in the codebase. It signifies the addition of functionality, making it a crucial marker for significant enhancements.

git commit -m "feat(modules/simple_storage): add simple Storage module"

After committing your changes, you push them to your branch and create a pull request on your repository’s main branch. Once the pull request is created, GitHub Actions automatically kicks in. The workflow analyzes the Conventional Commit, understands the change, and generates a new README and a CHANGELOG.

Upon reviewing and approving your pull request, you merge it into the main branch. As soon as the merge is completed, the Release Please workflow triggers automatically. The workflow analyzes the Conventional Commit, understands the change, and generates a new pull request dedicated to the release.

This workflow creates an official GitHub release for the module. It includes version tags and detailed changelogs, making it easy for users to understand what has been updated.

2. fix: Bug fixes

The fix commit type is employed when resolving issues or bugs in the code. It communicates that a problem has been addressed, ensuring that the software functions as intended. Following the same steps as before.

git commit -m "fix(modules/simple_storage): Set force destroy to false"

This Conventional Commit clearly communicates a bug fix related to the “simple_storage” module, this commit would trigger an automated release workflow, ensuring that the bug fix is properly documented, versioned, and released to users.

3. feat: Breaking changes

The feat! commit type signals breaking changes in the codebase. These changes are substantial and may require modifications in dependent modules or applications. It's essential to use feat! when there are compatibility-breaking alterations. Following the same steps as before.

git commit -m "feat(modules/simple_storage)!: remove the public access prevention"

This Conventional Commit signals the introduction of a new feature with potential breaking changes to the “simple_storage” module, this commit would initiate an automated release workflow, ensuring that the important new feature is documented, versioned, and released to users.

Conclusion

In this article, we’ve explored the feat, fix, and feat! Conventional Commits types. Understanding these commit types and using them effectively can enhance collaboration, streamline development workflows, and improve transparency within your projects. By incorporating Conventional Commits into your Git practices, you'll contribute to a clearer and more efficient development process.

Stay tuned for more insights, tips, and best practices in the next part of our series. Happy coding!