Terraform Owner Contribution Flow
This section describes the contribution flow for module owners who are responsible for creating and maintaining Terraform Module repositories.
This contribution flow is for Module owners only.
As a Terraform Module Owner you need to be aware of the AVM contribution process overview & shared specifications (including Interfaces) and Terraform-specific specifications as as these need to be considered during pull request reviews for the modules you own.
Make sure module authors/contributors tested their module in their environment before raising a PR. The PR uses e2e checks with 1ES agents in the 1ES subscriptions. At the moment their is no read access to the 1ES subscription. Also if more than two subscriptions are required for testing, that’s currently not supported.
Familiarise yourself with the responsibilities as Module Owner outlined in Team Definitions & RACI and in the TF Issue Triage.
- Watch Pull Request (PR) and issue (questions/feedback) activity for your module(s) in your repository and ensure that PRs are reviewed and merged in a timely manner as outlined in SNFR11.
Make sure module authors/contributors tested their module in their environment before raising a PR. Also because once a PR is raised a e2e GitHib workflow pipeline is required to be run successfully before the PR can be merged. This is to ensure that the module is working as expected and is compliant with the AVM specifications.
Familiarise yourself with the AVM Resource Module Naming in the module index csv’s.
- Example:
terraform-<provider>-avm-res-<rp>-<ARM resource type>
Make sure you have access to the Azure organisation see GitHub Account Link and Access.
Create the module repostory using terraform-azuremrm-avm-template in the
Azure
organisation with the following details (internal only). You will then have to complete the configuration of your repository and start an internal business review.Create GitHub teams as outlined in SNFR20 and add respective parent teams:
Segments:
avm-res-<RP>-<modulename>-module-owners-tf
avm-res-<RP>-<modulename>-module-contributors-tf
Examples:
avm-res-compute-virtualmachine-module-owners-tf
avm-res-compute-virtualmachine-module-contributors-tf
If a secondary owner is required, add the secondary owner to the avm-res-<RP>-<modulename>-module-owners-tf
team.
- Add these teams with the following permissions to the repository:
- Admin:
avm-core-team-technical-terraform
= AVM Core Team (Terraform Technical) - Admin:
terraform-avm
= Terraform PG - Admin:
avm-res-<RP>-<modulename>-module-owners-tf
= AVM Terraform Module Owners - Write:
avm-res-<RP>-<modulename>-module-contributors-tf
= AVM Terraform Module Contributors
- Make sure the branch protection rules for the
main
branch are inherited from theAzure/terraform-azurerm-avm-template
repository:
- Require a pull request before merging
- Dismiss stale pull request approvals when new commits are pushed
- Require review from Code Owners
- Require linear history
- Do not allow bypassing the above settings
Set up a GitHub repository Environment called
test
.Create deployment protection rules for the
test
environment to avoid spinning up e2e tests with every pull request raised by third-parties. Add the following teams as required reviewers:
- AVM Resource Module Owners:
avm-res-<RP>-<modulename>-module-owners-tf
- AVM Resource Module Contributors:
avm-res-<RP>-<modulename>-module-contributors-tf
- AVM Core Team Technical (Terraform):
avm-core-team-technical-terraform
As per SNFR23 the repositories created by module owners MUST have and use the pre-defined GitHub labels. To apply these labels to the repository review the PowerShell script Set-AvmGitHubLabels.ps1
that is provided in SNFR23.
Set-AvmGitHubLabels.ps1 -RepositoryName "Azure/MyGitHubRepo" -CreateCsvLabelExports $false -NoUserPrompts $true
- Add new owner as maintainer in your
avm-res-<RP>-<modulename>-module-owners-tf
team and remove any other individual including yourself. - In case primary owner leaves, switches roles or abandons the repo and the corresponding team then the parent team (if assigned) doesn’t have the permissions to gain back access and a ticket with GitHub support needs to be created (but the team can still be removed from the repo since the team
avm-core-team
has permissions on it).
Grept is a linting tool for repositories, ensures predefined standards, maintains codebase consistency, and quality. It’s using the grept configuration files from the Azure-Verified-Modules-Grept repository.
You can see here which files are synced from the terraform-azurerm-avm-template
repository.
- Set environment variables
# Linux/MacOS
export GITHUB_REPOSITORY_OWNER=Azure
export GITHUB_REPOSITORY=Azure/terraform-azurerm-avm-res-<RP>-<modulename>"
# Windows
$env:GITHUB_REPOSITORY_OWNER="Azure"
$env:GITHUB_REPOSITORY="Azure/terraform-azurerm-avm-res-<RP>-<modulename>"
- Run grept
# Linux/MacOS
./avm grept-apply
# Windows
avm.bat grept-apply
Once the development of the module has been completed, get the module reviewed from the AVM Core team by following the AVM Review of Terraform Modules process here which is a pre-requisite for the next step.
Once a module has been reviewed and is ready to be published, follow the below steps to publish the module to the HashiCorp Registry.
Ensure your module is ready for publishing:
- Create a tag for the module version you want to publish.
- Create tag:
git tag -a 0.1.0 -m "0.1.0"
- Push tag:
git push
- Create a release on Github based on the tag you just created. Make sure to generate the release notes using the
Generate release notes
button. - Optional: Instead of creating the tag via git cli, you can also create both the tag and release via Github UI. Just go to the releases tab and click on
Draft a new release
. Make sure to create the tag from themain
branch.
- Elevate your respository access using the Open Source Management Portal (aka.ms/opensource/portal).
- Sign in to the HashiCorp Registry using GitHub.
- Publish a module by selecting the
Publish
button in the top right corner, thenModule
- Select the repository and accept the terms.
Once a module gets updated and becomes a new version/release it will be automatically published with the latest published release version to the HashiCorp Registry.