infra: Project board custom fields (Solution, Priority, Category) not auto-populated on new issues

[kristopherjturner]

Problem

When new issues are created (via gh issue create or the GitHub UI), they are successfully auto-added to the Azure Local Solutions project board (Project #3), but the custom fields — Solution, Priority, and Category — are left blank.

Evidence

All issues created from #49 onwards have empty custom fields:

Issue	Repo	Solution	Priority	Category
#49+ (sofs-fslogix)	azurelocal-sofs-fslogix	❌ empty	❌ empty	❌ empty
#50-#55 (sofs-fslogix)	azurelocal-sofs-fslogix	❌ empty	❌ empty	❌ empty
#10-#12 (docs site)	azurelocal.github.io	❌ empty	❌ empty	❌ empty

Meanwhile, issues #1-#48 (created earlier, presumably with manual field population) all have these fields correctly set.

Root Cause

The add-to-project.yml workflow uses actions/add-to-project@v1.0.2 which only adds the issue to the project — it does not set custom field values:

# .github/workflows/add-to-project.yml (current)
- uses: actions/add-to-project@v1.0.2
  with:
    project-url: https://github.com/orgs/AzureLocal/projects/3
    github-token: ${{ secrets.ADD_TO_PROJECT_PAT }}

The actions/add-to-project action supports a project-field-values parameter (or the workflow can use gh project item-edit as a follow-up step), but neither is configured.

Project Board Fields

The project has these custom SingleSelect fields that need population:

Field	ID	Options
Solution	PVTSSF_...XuY	SOFS/FSLogix, AVD, Load Tools, VM Conversion, Docs Site, Workspace
Priority	PVTSSF_...Xvs	P1-High, P2-Medium, P3-Low
Category	PVTSSF_...XxA	Feature, Documentation, Infrastructure, Bug
Effort	PVTSSF_...Xxs	XS, S, M, L, XL
Sprint	PVTIF_...tpM	Iteration field

Required Work — Research and Implement

1. Research: Best Approach for Auto-Population

Investigate the following approaches:

Approach	How It Works	Pros	Cons
A: Label-based mapping	Workflow reads issue labels (solution/sofs, priority/high, type/docs) and maps them to project field values	Uses existing label conventions, no extra input needed	Requires label→field mapping logic in workflow
B: actions/add-to-project field values	Use the project-field-values parameter (if supported in v1.0.2+)	Single action, simple	May not support dynamic mapping
C: gh project item-edit post-step	After adding to project, use gh CLI to set each field based on labels	Full control, can use any logic	More workflow steps, needs field option IDs
D: GitHub App / built-in automation	Use GitHub Projects built-in automation rules (Settings → Workflows)	No custom workflow needed	Limited to auto-set on add, may not read labels
E: Issue forms with project fields	Use issue templates that prompt for Solution/Priority/Category	Data captured at creation time	Requires discipline, doesn't work for gh issue create CLI

Recommended: Approach A or C — Map existing labels to project fields automatically.

2. Label-to-Field Mapping

We already have labels that correspond 1:1 with project fields:

Label	→ Project Field	→ Value
solution/sofs	Solution	SOFS/FSLogix
solution/avd	Solution	AVD
solution/loadtools	Solution	Load Tools
solution/vmconvert	Solution	VM Conversion
solution/docs-site	Solution	Docs Site
solution/workspace	Solution	Workspace
priority/high	Priority	P1-High
priority/medium	Priority	P2-Medium
priority/low	Priority	P3-Low
priority/critical	Priority	P1-High (or add P0-Critical)
type/feature	Category	Feature
type/docs	Category	Documentation
type/infra	Category	Infrastructure
type/bug	Category	Bug

3. Implementation

• Research which approach works best with our current setup
• Update add-to-project.yml in all repos that use it (or create an org-level reusable workflow)
• Test with a new issue to verify fields are populated
• Backfill the 10+ issues (feat: azurelocal-keyvault-manager — app-facing Key Vault secret management tool #49-#55, epic: Migrate TierPoint Azure Local content to AzureLocal Cloud organization #10-feat: Create azurelocal-toolkit repo and migrate toolkit content #12) that are currently missing field values

4. Repos That Need the Updated Workflow

• azurelocal-sofs-fslogix — .github/workflows/add-to-project.yml
• azurelocal.github.io — needs add-to-project.yml added (currently missing!)
• aurelocal-avd — check if workflow exists
• azurelocal-loadtools — check if workflow exists
• azurelocal-vm-conversion-toolkit — check if workflow exists

Acceptance Criteria

• New issues auto-populate Solution, Priority, and Category on the project board based on labels
• Workflow is consistent across all repos
• Existing issues with empty fields are backfilled
• Documentation updated if the workflow is changed

References

• Project board: https://github.com/orgs/AzureLocal/projects/3
• Current workflow: .github/workflows/add-to-project.yml
• actions/add-to-project docs: https://github.com/actions/add-to-project

[kristopherjturner]

Implementation Summary

Workflow update (committed to \main\ on all repos):

• \�zurelocal-sofs-fslogix\ — c41ddc7
• \�urelocal-avd\ — 394c952
• \�zurelocal-loadtools\ — 0672dc6
• \�zurelocal-vm-conversion-toolkit\ — f609fff
• \�zurelocal.github.io\ — 3798492

What changed:

• \�dd-to-project.yml\ now has a second job (\set-fields) that runs after \�dd-to-project\
• Maps \solution/\ labels to Solution field, \priority/\ to Priority, \ ype/*\ to Category
• Uses \gh project item-edit\ with Projects V2 field/option IDs

Backfill completed:

• Set Solution, Priority, and Category on issues #50-#55 (sofs), epic: Migrate TierPoint Azure Local content to AzureLocal Cloud organization #10-infra: Project board custom fields (Solution, Priority, Category) not auto-populated on new issues #13 (docs-site)

All new issues with matching labels will auto-populate project board fields.