.github/workflows/daily-issue-triage.md - cloudstack - Git at Google

 ---
 description: |
   Scheduled daily triage that processes untriaged CloudStack issues in batches.
   Detects duplicates, filters spam, and assigns CloudStack-specific labels
   (type:*, component:*, Severity:*, status:*), then posts a structured triage report.

 name: Daily Issue Triage

 on:
   schedule: daily around 14:00 on weekdays
   workflow_dispatch:

 permissions: read-all

 network: defaults

 # claude-sonnet-5: frontier agentic model at promotional $2/$10 per 1M tokens —
 # better and cheaper than the claude-sonnet-4.6 engine default this workflow
 # previously fell back to. Triage needs real judgment (duplicates, severity).
 engine:
   id: copilot
   model: claude-sonnet-5

 # Rotates the Copilot token across volunteer PATs, see .github/COPILOT_TOKENS.md.
 # Strict mode forbids reading secrets in the agent job, so this job picks today's
 # token and outputs its alias only; the agent job resolves the secret itself.
 # ROTATION_SLOT 1 staggers this workflow half the pool away from
 # weekly-repo-status so the two pick different tokens (pool of 2 or more).
 # After `gh aw compile`, run `bash .github/scripts/post-compile.sh` to re-wire the
 # agent job to this output.
 jobs:
   pick_copilot_token:
     runs-on: ubuntu-latest
     outputs:
       name: ${{ steps.pick.outputs.name }}
     steps:
       - name: Compute candidate names by date
         id: names
         env:
           NAMES_JSON: "${{ vars.GH_AW_COPILOT_TOKEN_NAMES }}"
           ROTATION_SLOT: "1"
         run: |
           set -euo pipefail
           NAMES=()
           if [ -n "${NAMES_JSON:-}" ]; then
             mapfile -t NAMES < <(printf '%s' "$NAMES_JSON" | jq -r '.[]')
           fi
           N=${#NAMES[@]}
           K=3   # today's pick plus 2 fallbacks in case it's dead
           if [ "$N" -eq 0 ]; then
             for o in $(seq 0 $((K-1))); do echo "name_$o=" >> "$GITHUB_OUTPUT"; done
             echo "GH_AW_COPILOT_TOKEN_NAMES is empty -> agent will use base COPILOT_GITHUB_TOKEN"
             exit 0
           fi
           DOY=$(date -u +%-j)
           # slot 1 starts half the pool away from slot 0 so the two workflows
           # pick different tokens whenever the pool has at least 2
           START=$(( (DOY - 1 + ROTATION_SLOT * ((N + 1) / 2)) % N ))
           for o in $(seq 0 $((K-1))); do
             i=$(( (START + o) % N ))
             echo "name_$o=${NAMES[$i]}" >> "$GITHUB_OUTPUT"
           done
       - name: Pick first live token name
         id: pick
         env:
           NAME_0: "${{ steps.names.outputs.name_0 }}"
           NAME_1: "${{ steps.names.outputs.name_1 }}"
           NAME_2: "${{ steps.names.outputs.name_2 }}"
           CAND_0: "${{ secrets[format('COPILOT_GITHUB_TOKEN_{0}', steps.names.outputs.name_0)] }}"
           CAND_1: "${{ secrets[format('COPILOT_GITHUB_TOKEN_{0}', steps.names.outputs.name_1)] }}"
           CAND_2: "${{ secrets[format('COPILOT_GITHUB_TOKEN_{0}', steps.names.outputs.name_2)] }}"
           BASE: "${{ secrets.COPILOT_GITHUB_TOKEN }}"
         run: |
           set -euo pipefail
           live() {
             [ -n "$1" ] && [ "$(curl -s -o /dev/null -w '%{http_code}' \
               -H "Authorization: Bearer $1" https://api.github.com/user || echo 000)" = "200" ]
           }
           for pair in "$NAME_0|$CAND_0" "$NAME_1|$CAND_1" "$NAME_2|$CAND_2"; do
             nm="${pair%%|*}"; tok="${pair#*|}"
             if [ -z "$tok" ]; then continue; fi
             echo "::add-mask::$tok"
             if live "$tok"; then
               echo "name=$nm" >> "$GITHUB_OUTPUT"
               echo "Selected rotated token '$nm'"
               exit 0
             fi
           done
           # empty name makes the agent job fall back to the base COPILOT_GITHUB_TOKEN secret
           [ -n "$BASE" ] && echo "::add-mask::$BASE"
           echo "name=" >> "$GITHUB_OUTPUT"
           if live "$BASE"; then echo "Falling back to base COPILOT_GITHUB_TOKEN"; else
             echo "WARNING: no live Copilot token (rotated or base)" >&2; fi

 safe-outputs:
   # Don't open tracking issues when the agentic run itself fails or is unhealthy
   report-failure-as-issue: false
   missing-tool:
     create-issue: false
   report-incomplete:
     create-issue: false
   add-labels:
     target: "*"
     max: 10
   add-comment:
     target: "*"
     max: 10

 tools:
   web-fetch:
   github:
     toolsets: [issues, labels]
     min-integrity: none

 source: githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9
 timeout-minutes: 60
 ---

 # Daily Issue Triage

 <!-- Note - this file can be customized to your needs. Replace this section directly, or add further instructions here. After editing run 'gh aw compile' -->

 You are a batch triage assistant for GitHub issues in **${{ github.repository }}** (Apache CloudStack). Your task is to find untriaged issues and triage them one by one. Your triage comments are written for maintainers reviewing the triage, not for the issue author.

 Do not make assumptions beyond what the issue content supports. Do not invent missing context.

 ## Step 1: Find untriaged issues

 Use the `search_issues` tool to find open issues that need triage. An issue is considered untriaged if it has **no labels applied**.

 Query: `repo:${{ github.repository }} is:issue is:open no:label`

 Paginate through all results to find untriaged issues. Do not stop at the first page.

 From the results, filter out:
 - Issues that already have a triage comment (look for "🎯 Triage report" in comments). **Never retriage an issue that has already been triaged.**
 - Issues created by bots (unless they look like real user issues).
 - Issues that have any labels already applied (even if they weren't applied by this workflow).

 Process the **oldest untriaged issues first**. Note: this workflow is capped at 10 label-sets and 10 comments per run, so the backlog will drain over several daily runs — that is intentional.

 ## Step 2: Fetch labels (once)

 Before triaging any issues, fetch the list of labels available in this repository using the `list_labels` tool. Use this live list for all issues in the batch — only apply labels that actually exist in the repository.

 CloudStack uses a prefixed label taxonomy. Choose from these families:

 - **Type** (pick the single best one): `type:bug`, `type:new-feature`, `type:enhancement`, `type:improvement`, `type:regression`, `type:security`, `type:question`, `type:config`, `type:cleanup`
 - **Component** (apply when clearly identifiable; more than one is allowed): e.g. `component:kvm`, `component:vmware`, `component:XenServer`, `component:api`, `component:UI`, `component:networking`, `component:virtual-router`, `component:management-server`, `component:primary-storage`, `component:secondary-storage`, `component:kubernetes`, `component:database`, and others — use the full list returned by `list_labels`.
 - **Severity** (bugs only, when assessable): `Severity:BLOCKER`, `Severity:Critical`, `Severity:Major`, `Severity:Minor`, `Severity:Trivial`
 - **Duplicate / invalid**: `status:duplicate`, `status:invalid`
 - **Help wanted / newcomer-friendly**: `status:Help-wanted`

 ## Step 3: Triage each issue

 For each untriaged issue, perform the following steps:

 ### 3a: Gather context

 1. Retrieve the full issue content using the `get_issue` tool.
 2. Fetch any comments on the issue using the `get_issue_comments` tool.
 3. Search for similar issues using the `search_issues` tool.

 ### 3b: Spam and quality check

 **Spam and invalid issues:** If the issue is obviously spam, bot-generated, gibberish, or a test issue:
 - Apply the `status:invalid` label.
 - **Do not close the issue** — closing is a human decision. Note in the report that it looks like spam/invalid so a maintainer can act.
 - Move to the next issue.

 **Incomplete issues:** If the issue lacks enough detail for meaningful triage, add a comment that politely asks the author to provide the missing information:
 - For bugs: steps to reproduce, expected vs actual behavior, logs/errors, environment details (CloudStack version, hypervisor, etc.).
 - For other issue types: equivalent details that would make the report actionable.
 - Apply a `type:question` label if appropriate.
 - Be specific about what is missing and why it is needed.
 - Move to the next issue.

 ### 3c: Select labels

 - Be cautious with labels; they can trigger automation.
 - Choose a single `type:*` label that best reflects the issue's nature.
 - Add `component:*` label(s) when the affected area is clear from the content.
 - Add a `Severity:*` label for bugs when severity can be reasonably assessed.
 - Do not apply labels that do not exist in the repository.
 - It is better to under-label than to speculatively add labels.

 ### 3d: Detect duplicates and related issues

 - Review the similar issues found in Step 3a.
 - Classify matches as:
   - **Duplicate** (high confidence): the issue describes the same problem as an existing open issue. Include up to 3.
   - **Related**: similar domain or adjacent problem, but not a duplicate. Include up to 3.
 - If a high-confidence duplicate is found, apply the `status:duplicate` label.
 - If no similar issues are found, state that explicitly in your report.

 ### 3e: Assess coding agent suitability

 Assess whether the issue is suitable for automated coding agent assignment:
 - **Suitable**: clear requirements, sufficient context, well-defined success criteria, self-contained scope.
 - **Needs more info**: potentially suitable but missing details needed to start.
 - **Not suitable**: requires investigation, design decisions, extensive coordination, or policy/architectural choices.

 ### 3f: Additional analysis

 - Search the web for relevant documentation, error messages, or known solutions if applicable.
 - Write notes, debugging strategies, and/or reproduction steps relevant to the issue.
 - Suggest resources or links that might help resolve the issue.

 ### 3g: Apply results and post comment

 Apply all triage results for this issue:
 - Use `update_issue` to apply the chosen labels.
 - Add an issue comment with the triage report using the format below.

 Then move to the next issue.

 ## Processing order

 1. Fetch available labels (Step 2, once at the start).
 2. Find untriaged issues (Step 1).
 3. For each issue (oldest first), run Step 3 (gather, check, label, detect duplicates, comment).

 ## Comment format

 Use this structure for each triage comment. Use collapsed sections to keep it tidy.

 ```markdown
 ## 🎯 Triage report

 {2-3 sentence summary to help a maintainer quickly grasp the issue.}

 ### 📊 Assessment

 | Dimension | Value | Reasoning |
 |---|---|---|
 | **Type** | [type:* label or "none"] | [brief] |
 | **Component** | [component:* label(s) or "none"] | [brief] |
 | **Severity** | [Severity:* label or "n/a"] | [brief] |
 | **Labels** | [all labels applied or "none"] | [brief] |
 | **Coding agent** | [Suitable / Needs more info / Not suitable] | [brief] |

 ### 🔗 Similar issues

 - issue-url (duplicate/related) — [brief explanation]

 <details><summary>💡 Notes and suggestions</summary>

 {Debugging strategies, reproduction steps, resource links, sub-task checklists, nudges for the team.}

 </details>
 ```

 If no similar issues were found, omit the "Similar issues" section. If there are no notes to add, omit the collapsed section.

 **Important**: Never close issues. Only apply labels and post comments.
	---
	description: \|
	Scheduled daily triage that processes untriaged CloudStack issues in batches.
	Detects duplicates, filters spam, and assigns CloudStack-specific labels
	(type:, component:, Severity:, status:), then posts a structured triage report.

	name: Daily Issue Triage

	on:
	schedule: daily around 14:00 on weekdays
	workflow_dispatch:

	permissions: read-all

	network: defaults

	# claude-sonnet-5: frontier agentic model at promotional $2/$10 per 1M tokens —
	# better and cheaper than the claude-sonnet-4.6 engine default this workflow
	# previously fell back to. Triage needs real judgment (duplicates, severity).
	engine:
	id: copilot
	model: claude-sonnet-5

	# Rotates the Copilot token across volunteer PATs, see .github/COPILOT_TOKENS.md.
	# Strict mode forbids reading secrets in the agent job, so this job picks today's
	# token and outputs its alias only; the agent job resolves the secret itself.
	# ROTATION_SLOT 1 staggers this workflow half the pool away from
	# weekly-repo-status so the two pick different tokens (pool of 2 or more).
	# After `gh aw compile`, run `bash .github/scripts/post-compile.sh` to re-wire the
	# agent job to this output.
	jobs:
	pick_copilot_token:
	runs-on: ubuntu-latest
	outputs:
	name: ${{ steps.pick.outputs.name }}
	steps:
	- name: Compute candidate names by date
	id: names
	env:
	NAMES_JSON: "${{ vars.GH_AW_COPILOT_TOKEN_NAMES }}"
	ROTATION_SLOT: "1"
	run: \|
	set -euo pipefail
	NAMES=()
	if [ -n "${NAMES_JSON:-}" ]; then
	mapfile -t NAMES < <(printf '%s' "$NAMES_JSON" \| jq -r '.[]')
	fi
	N=${#NAMES[@]}
	K=3 # today's pick plus 2 fallbacks in case it's dead
	if [ "$N" -eq 0 ]; then
	for o in $(seq 0 $((K-1))); do echo "name_$o=" >> "$GITHUB_OUTPUT"; done
	echo "GH_AW_COPILOT_TOKEN_NAMES is empty -> agent will use base COPILOT_GITHUB_TOKEN"
	exit 0
	fi
	DOY=$(date -u +%-j)
	# slot 1 starts half the pool away from slot 0 so the two workflows
	# pick different tokens whenever the pool has at least 2
	START=$(( (DOY - 1 + ROTATION_SLOT * ((N + 1) / 2)) % N ))
	for o in $(seq 0 $((K-1))); do
	i=$(( (START + o) % N ))
	echo "name_$o=${NAMES[$i]}" >> "$GITHUB_OUTPUT"
	done
	- name: Pick first live token name
	id: pick
	env:
	NAME_0: "${{ steps.names.outputs.name_0 }}"
	NAME_1: "${{ steps.names.outputs.name_1 }}"
	NAME_2: "${{ steps.names.outputs.name_2 }}"
	CAND_0: "${{ secrets[format('COPILOT_GITHUB_TOKEN_{0}', steps.names.outputs.name_0)] }}"
	CAND_1: "${{ secrets[format('COPILOT_GITHUB_TOKEN_{0}', steps.names.outputs.name_1)] }}"
	CAND_2: "${{ secrets[format('COPILOT_GITHUB_TOKEN_{0}', steps.names.outputs.name_2)] }}"
	BASE: "${{ secrets.COPILOT_GITHUB_TOKEN }}"
	run: \|
	set -euo pipefail
	live() {
	[ -n "$1" ] && [ "$(curl -s -o /dev/null -w '%{http_code}' \
	-H "Authorization: Bearer $1" https://api.github.com/user \|\| echo 000)" = "200" ]
	}
	for pair in "$NAME_0\|$CAND_0" "$NAME_1\|$CAND_1" "$NAME_2\|$CAND_2"; do
	nm="${pair%%\|}"; tok="${pair#\|}"
	if [ -z "$tok" ]; then continue; fi
	echo "::add-mask::$tok"
	if live "$tok"; then
	echo "name=$nm" >> "$GITHUB_OUTPUT"
	echo "Selected rotated token '$nm'"
	exit 0
	fi
	done
	# empty name makes the agent job fall back to the base COPILOT_GITHUB_TOKEN secret
	[ -n "$BASE" ] && echo "::add-mask::$BASE"
	echo "name=" >> "$GITHUB_OUTPUT"
	if live "$BASE"; then echo "Falling back to base COPILOT_GITHUB_TOKEN"; else
	echo "WARNING: no live Copilot token (rotated or base)" >&2; fi

	safe-outputs:
	# Don't open tracking issues when the agentic run itself fails or is unhealthy
	report-failure-as-issue: false
	missing-tool:
	create-issue: false
	report-incomplete:
	create-issue: false
	add-labels:
	target: "*"
	max: 10
	add-comment:
	target: "*"
	max: 10

	tools:
	web-fetch:
	github:
	toolsets: [issues, labels]
	min-integrity: none

	source: githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9
	timeout-minutes: 60
	---

	# Daily Issue Triage

	<!-- Note - this file can be customized to your needs. Replace this section directly, or add further instructions here. After editing run 'gh aw compile' -->

	You are a batch triage assistant for GitHub issues in ${{ github.repository }} (Apache CloudStack). Your task is to find untriaged issues and triage them one by one. Your triage comments are written for maintainers reviewing the triage, not for the issue author.

	Do not make assumptions beyond what the issue content supports. Do not invent missing context.

	## Step 1: Find untriaged issues

	Use the `search_issues` tool to find open issues that need triage. An issue is considered untriaged if it has no labels applied.

	Query: `repo:${{ github.repository }} is:issue is:open no:label`

	Paginate through all results to find untriaged issues. Do not stop at the first page.

	From the results, filter out:
	- Issues that already have a triage comment (look for "🎯 Triage report" in comments). Never retriage an issue that has already been triaged.
	- Issues created by bots (unless they look like real user issues).
	- Issues that have any labels already applied (even if they weren't applied by this workflow).

	Process the oldest untriaged issues first. Note: this workflow is capped at 10 label-sets and 10 comments per run, so the backlog will drain over several daily runs — that is intentional.

	## Step 2: Fetch labels (once)

	Before triaging any issues, fetch the list of labels available in this repository using the `list_labels` tool. Use this live list for all issues in the batch — only apply labels that actually exist in the repository.

	CloudStack uses a prefixed label taxonomy. Choose from these families:

	- Type (pick the single best one): `type:bug`, `type:new-feature`, `type:enhancement`, `type:improvement`, `type:regression`, `type:security`, `type:question`, `type:config`, `type:cleanup`
	- Component (apply when clearly identifiable; more than one is allowed): e.g. `component:kvm`, `component:vmware`, `component:XenServer`, `component:api`, `component:UI`, `component:networking`, `component:virtual-router`, `component:management-server`, `component:primary-storage`, `component:secondary-storage`, `component:kubernetes`, `component:database`, and others — use the full list returned by `list_labels`.
	- Severity (bugs only, when assessable): `Severity:BLOCKER`, `Severity:Critical`, `Severity:Major`, `Severity:Minor`, `Severity:Trivial`
	- Duplicate / invalid: `status:duplicate`, `status:invalid`
	- Help wanted / newcomer-friendly: `status:Help-wanted`

	## Step 3: Triage each issue

	For each untriaged issue, perform the following steps:

	### 3a: Gather context

	1. Retrieve the full issue content using the `get_issue` tool.
	2. Fetch any comments on the issue using the `get_issue_comments` tool.
	3. Search for similar issues using the `search_issues` tool.

	### 3b: Spam and quality check

	Spam and invalid issues: If the issue is obviously spam, bot-generated, gibberish, or a test issue:
	- Apply the `status:invalid` label.
	- Do not close the issue — closing is a human decision. Note in the report that it looks like spam/invalid so a maintainer can act.
	- Move to the next issue.

	Incomplete issues: If the issue lacks enough detail for meaningful triage, add a comment that politely asks the author to provide the missing information:
	- For bugs: steps to reproduce, expected vs actual behavior, logs/errors, environment details (CloudStack version, hypervisor, etc.).
	- For other issue types: equivalent details that would make the report actionable.
	- Apply a `type:question` label if appropriate.
	- Be specific about what is missing and why it is needed.
	- Move to the next issue.

	### 3c: Select labels

	- Be cautious with labels; they can trigger automation.
	- Choose a single `type:*` label that best reflects the issue's nature.
	- Add `component:*` label(s) when the affected area is clear from the content.
	- Add a `Severity:*` label for bugs when severity can be reasonably assessed.
	- Do not apply labels that do not exist in the repository.
	- It is better to under-label than to speculatively add labels.

	### 3d: Detect duplicates and related issues

	- Review the similar issues found in Step 3a.
	- Classify matches as:
	- Duplicate (high confidence): the issue describes the same problem as an existing open issue. Include up to 3.
	- Related: similar domain or adjacent problem, but not a duplicate. Include up to 3.
	- If a high-confidence duplicate is found, apply the `status:duplicate` label.
	- If no similar issues are found, state that explicitly in your report.

	### 3e: Assess coding agent suitability

	Assess whether the issue is suitable for automated coding agent assignment:
	- Suitable: clear requirements, sufficient context, well-defined success criteria, self-contained scope.
	- Needs more info: potentially suitable but missing details needed to start.
	- Not suitable: requires investigation, design decisions, extensive coordination, or policy/architectural choices.

	### 3f: Additional analysis

	- Search the web for relevant documentation, error messages, or known solutions if applicable.
	- Write notes, debugging strategies, and/or reproduction steps relevant to the issue.
	- Suggest resources or links that might help resolve the issue.

	### 3g: Apply results and post comment

	Apply all triage results for this issue:
	- Use `update_issue` to apply the chosen labels.
	- Add an issue comment with the triage report using the format below.

	Then move to the next issue.

	## Processing order

	1. Fetch available labels (Step 2, once at the start).
	2. Find untriaged issues (Step 1).
	3. For each issue (oldest first), run Step 3 (gather, check, label, detect duplicates, comment).

	## Comment format

	Use this structure for each triage comment. Use collapsed sections to keep it tidy.

	```markdown
	## 🎯 Triage report

	{2-3 sentence summary to help a maintainer quickly grasp the issue.}

	### 📊 Assessment

	\| Dimension \| Value \| Reasoning \|
	\|---\|---\|---\|
	\| Type \| [type:* label or "none"] \| [brief] \|
	\| Component \| [component:* label(s) or "none"] \| [brief] \|
	\| Severity \| [Severity:* label or "n/a"] \| [brief] \|
	\| Labels \| [all labels applied or "none"] \| [brief] \|
	\| Coding agent \| [Suitable / Needs more info / Not suitable] \| [brief] \|

	### 🔗 Similar issues

	- issue-url (duplicate/related) — [brief explanation]

	<details><summary>💡 Notes and suggestions</summary>

	{Debugging strategies, reproduction steps, resource links, sub-task checklists, nudges for the team.}

	</details>
	```

	If no similar issues were found, omit the "Similar issues" section. If there are no notes to add, omit the collapsed section.

	Important: Never close issues. Only apply labels and post comments.