Azure Verified Modules
Glossary GitHub GitHub Issues Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Last updated: 03 Apr 2024

Terraform Issue Triage

Overview

This page provides guidance for Terraform Module owners on how to triage AVM module issues and AVM question/feedback items filed in their Terraform Module Repo(s), as well as how to manage these GitHub issues throughout their lifecycle.

The following issues can be filed in a Terraform repository:

  • AVM Module Issue: Issues specifically related to an existing AVM module, such as feature requests, bug and security bug reports.
  • AVM Question/Feedback: Generic feedback and questions, related to existing AVM module, the overall framework, or its automation (CI environment).

Do NOT file the following types of issues in a Terraform repository, as they MUST be tracked in the AVM repo:

Every module needs a module proposal to be created in the AVM repository.

Module Owner Responsibilities

During the triage process, module owners are expected to check, complete and follow up on the items described in the sections below.

Module owners MUST meet the SLAs defined on the Module Support page! While there’s automation in place to support meeting these SLAs, module owners MUST check for new issues on a regular basis.

  • To look for items that need triaging, look for issue labled with ➡️ Needs: Triage 🔍⬅️.
  • To look for items that need attention, look for issue labled with ➡️ Needs: Attention 👋 ⬅️.

Module Issue

An issue is considered to be an “AVM module issue” if

  • it was opened through the AVM Module Issue template in the Terraform repository,
  • it has the label of “Needs: Triage 🔍” applied to it, and
  • it is assigned to the “AVM - Module Issues” GitHub project.

Module issues can only be opened for existing AVM modules. Module issues MUST NOT be used to file a module proposal.

If the issue was opened as a misplaced module proposal, mention the @Azure/AVM-core-team-technical-terraform team in the comment section and ask them to move the issue to the AVM repository.

Triaging a Module Issue

  1. Check the Module issue:
    • Use the AVM module indexes to identify the module owner(s) and make sure they are assigned/mentioned/informed.
    • If the module is orphaned (has no owner), make sure there’s an orphaned module issue in the AVM repository.
    • Make sure the module’s details are captured correctly in the description - i.e., name, classification (resource/pattern), language (Bicep/Terraform), etc.
    • Make sure the issue is categorized using one of the following type labels:
      • Type: Feature Request ➕
      • Type: Bug 🐛
      • Type: Security Bug 🔒
  2. Apply relevant labels for module classification (resource/pattern): “Class: Resource Module 📦” or “Class: Pattern Module 📦
  3. Communicate next steps to the requestor (issue author).
  4. Remove the “Needs: Triage 🔍” label.
  5. When more detailed plans are available, communicate expected timeline for the update/fix to the requestor (issue author).
  6. Only close the issue, once the next version of the module was fully developed, tested and published.

General Question/Feedback and other standard issues

An issue is considered to be an “AVM Question/Feedback” if

  • it was opened through the AVM Question/Feedback template in your Terraform repository,
  • it has the labels of “Needs: Triage 🔍” and “Type: Question/Feedback 🙋‍♀️” applied to it, and
  • it is assigned to the “AVM - Issue Triage” GitHub project.

Triaging a General Question/Feedback and other standard issues

  1. When triaging the issue, consider adding one of the following labels as fits:

    • Type: Documentation 📄
    • Type: Feature Request ➕
    • Type: Bug 🐛
    • Type: Security Bug 🔒

To see the full list of available labels, please refer to the GitHub Repo Labels section.

  1. Add any (additional) labels that apply.
  2. Communicate next steps to the requestor (issue author).
  3. Remove the “Needs: Triage 🔍” label.
  4. When more detailed plans are available, communicate expected timeline for the update/fix to the requestor (issue author).
  5. Once the question/feedback/topic is fully addressed, close the issue.
If an intended module proposal was mistakenly opened as a “AVM Question/Feedback ❔” or other standard issue, a new issue MUST be created in the AVM repo using the “New AVM Module Proposal 📝” issue template. The mistakenly created “AVM Question/Feedback ❔” or other standard issue MUST be closed.