Welcome to the Terraform Modules Repository! This repository serves as a mono repo for releasing different versions of Terraform modules. Each module is organized within the modules directory and follows a specific structure. This README will provide an overview of the repository's structure and the automated GitHub Actions workflows that manage module releases.
The repository is structured as follows:
modules/
- project
- simple network
- ...
Each module directory contains, at a minimum, the following files:
README.md: Module-specific documentation.main.tf: The main Terraform configuration file.variables.tf: File for defining variables.versions.tf: File for specifying Terraform versions.
This workflow runs every time a pull request is created with changes in the modules/ directory. Its purpose is to identify the modules affected by the pull request and perform specific tasks for each module:
Description: This step identifies the modules that have been modified in the pull request by comparing the changes with the main branch. It does so by performing the following actions:
- Checking out the repository to access its contents.
- Retrieving the list of changed files in the pull request.
- Extracting module names from the changed file paths using regular expressions.
- Removing duplicate module names from the list.
Conventional Commits: Conventional Commits are encouraged during the development process to ensure that meaningful commit messages make it easier to track changes to the modules.
Description: For each module identified in the previous step, this step generates and updates the module-specific README.md file with Terraform documentation. It achieves this using the terraform-docs GitHub Action, which automates the process of updating documentation.
Conventional Commits: Commit messages in this step should follow Conventional Commit conventions to clearly communicate documentation updates or other changes.
Description: This step performs a basic review of the Terraform code for each changed module. It executes the following Terraform commands:
terraform init: Initializes the Terraform environment.terraform fmt -check: Checks if the code is correctly formatted.terraform validate: Validates the Terraform configuration.
Conventional Commits: Using Conventional Commits is especially useful here to provide context on code formatting improvements and validation changes.
This workflow is triggered when changes are pushed to the main branch, specifically within the modules/ directory. It is responsible for creating new releases for the modified modules.
Description: This step identifies the modules that have changed by comparing the latest tag with the main branch. It performs the following actions:
- Checking out the repository.
- Retrieving the latest release.
- Comparing changes between the latest release and the main branch.
- Identifying modules affected by the changes based on file paths.
Conventional Commits: Conventional Commits play a significant role here in tracking changes accurately and generating meaningful changelogs.
Description: For each affected module, this step uses the Release Please tool to create a pull request that initiates a new release. Release Please automates various aspects of the release process, including generating a changelog and creating GitHub releases.
Conventional Commits: Commit messages generated during the release process follow Conventional Commit conventions, ensuring that each release is well-documented and its purpose is clear.
Description: After the pull requests for new releases are merged, this step creates GitHub releases for the modules. It uses the same Release Please tool to manage the release process, including the creation of release notes and version tags.
Conventional Commits: The release notes and version tags generated by Release Please are based on Conventional Commits, making it easy for users to understand the significance of each release.
We follow a standardized commit message format known as Conventional Commits in this repository. Conventional Commits provide a structured and human-readable way to document changes to the codebase. Each commit message adheres to the following format:
<type>(<scope>): <description>
<type>: Indicates the purpose or nature of the change. Common types include:feat: A new feature or enhancement.fix: A bug fix.chore: Routine tasks, maintenance, or tooling changes.docs: Documentation updates.style: Code style or formatting changes.refactor: Code refactoring without functionality changes.test: Adding or modifying tests.
<scope>(optional): Provides context for the change, such as a module name or specific component.<description>: A clear and concise description of the change.
Here's an example of a Conventional Commit:
feat(network): add VPC module
In this commit message:
featindicates that a new feature has been added.networkprovides context or a scope for the change.add VPC moduleis a clear description of the change.
By adhering to Conventional Commits, we maintain a consistent and structured commit history. This format enhances collaboration among team members and enables automated tools like Release Please to automate the release process based on the nature of the commits.
Using Conventional Commits helps us create meaningful changelogs and simplify version management, making it easier for both contributors and users to understand the changes introduced in each release.
For more information on Conventional Commits, please refer to the official specification.
This repository is licensed under the Apache License 2.0. You may obtain a copy of the License at http://www.apache.org/licenses/.