BRM Issue Triage

Overview

This page provides guidance for Bicep module owners on how to triage AVM module issues and AVM question/feedback items filed in the BRM repository (Bicep Registry Modules repository - where all Bicep AVM modules are published), as well as how to manage these GitHub issues throughout their lifecycle.

As such, the following issues are to be filed in the BRM 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 the BRM repository, as they MUST be tracked in the AVM repo:

Note

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.

Important

The BRM repository includes other, non-AVM modules and related GitHub issues. As a module owner, make sure you’re only triaging, managing or otherwise working on issues that are related to AVM modules!

Tip

Module Issue

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

Note

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/azure-verified-modules-tooling-contributors 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:
    • Make sure the issue has the  Type: AVM 🅰️ ✌️ ⓜ️  applied to it.
    • Use the AVM module indexes to locate the module and its root metadata.json for the full owner list. Make sure the owners are assigned/mentioned/informed. Submit corrections through the metadata review process.
    • 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.

Triaging a Module PR

  1. Request knowledgeable review from module owners identified in the root metadata.json when available. An eligible BRM repository team member may approve and merge ordinary module code changes; a module owner’s approval is not mandatory. If the author is the sole owner, request another eligible reviewer rather than the author.
  2. For metadata.json changes, obtain approval from an eligible member of either metadata code-owner team through the metadata review process.
  3. Apply relevant labels
    • Categorize the PR using applicable labels, such as:
      •  Type: Feature Request ➕ 
      •  Type: Bug 🐛 
      •  Type: Security Bug 🔒 
    • For module classification (resource/pattern):  Class: Resource Module 📦  or  Class: Pattern Module 📦 
  4. If the module is orphaned (has no owner), make sure the related Orphaned module issue (in the AVM repository) is associated to the PR in a comment, so the new owner can easily identify all related issues and PRs when taking ownership.
  5. Remove the  Needs: Triage 🔍  label.
Give your PR a meaningful title
  • Prefix: Start with one of the allowed keywords - fix: or feat: is the most common for module related changes.
  • Description: Add a few words, describing the nature of the change.
  • Module name: Add the module’s full name between backticks ( ` ) to make it pop.
Who needs to approve the PR?

For ordinary Bicep module code changes, any eligible repository team member may approve and merge under BRM rules. Reviewer routing requests module owners and applies triage labels, but does not impose a module-owner approval requirement. The metadata.json code-owner rule and other protected-path rules still apply.

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 the BRM repository,
  • it has the labels of  Needs: Triage 🔍 ,  Type: Question/Feedback 🙋‍♀️  and  Type: AVM 🅰️ ✌️ ⓜ️  applied to it, and
  • it is assigned to the “AVM - Issue Triage” GitHub project.

An issue is considered to be a “standard issue” or “blank issue” if it was opened without using an issue template, and hence it does NOT have any labels assigned, OR only has the  Needs: Triage 🔍  label assigned.

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.
Note

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.