ldraney/pal-e-platform
1
0
Fork 0
Code Issues 91 Pull requests 5 Projects Releases Packages Wiki Activity Actions

Seed standard label set on new repos (story:*, arch:*, type:*) #311

New issue
Open
opened 2026-04-27 20:14:28 +00:00 by forgejo_admin · 0 comments
forgejo_admin commented 2026-04-27 20:14:28 +00:00
Contributor
Copy link

Type

Chore

Lineage

Discovered scope from Wave 2A of westside-admin bootstrap (2026-04-26). Dev agent on PR #10 (Dockerfile) tried to apply story:admin-row-crud and arch:harbor labels but the westside-admin repo has no labels defined at all. Same gap likely exists for any newly-created Forgejo repo. Worth a one-time bootstrap ticket so the next new-repo arc doesn't hit the same friction.

Repo

forgejo_admin/pal-e-platform (or wherever the repo-init scripts live — verify)

What Broke

When a brand-new Forgejo repo is created via the platform's onboarding flow, no labels are pre-defined. Dev agents writing PRs that reference story:* and arch:* labels per feedback_traceability_triangle find the labels don't exist, so labels can't be applied (or worse, agents try to create labels ad-hoc with inconsistent naming).

Repro Steps

  1. Create a new Forgejo repo via whatever current onboarding flow exists
  2. Try to apply a story:admin-row-crud label to a PR via mcp__forgejo__set_label or via the UI
  3. Observe label doesn't exist
  4. Repeat for arch:harbor, type:bug, etc.

Expected Behavior

Newly-created repos have the standard pal-e label set seeded at creation:

  • type:bug, type:feature, type:chore, type:infra, type:spike
  • story:* (the active story labels)
  • arch:* (the canonical arch IDs per convention-architecture-ids)
  • Status labels: status:approved, status:needs-changes, etc. (whatever the existing repos use)

Environment

  • Forgejo on tail5b443a
  • Repo creation via terraform module in pal-e-services (per Service Onboarding SOP) OR via manual UI / mcp__forgejo__create_repo

User Story

story:platform-stability — As a dev agent dispatched against a new repo's first ticket, I need the standard label set already present so I can apply traceability labels per feedback_traceability_triangle without filing yet another bootstrap ticket.

Context

Two implementation paths:

  1. Terraform-side: add a forgejo_label resource per label, for_each over the standard set, applied to every repo in the services map. Cleanest, version-controlled.
  2. Bootstrap script: a one-shot script that the operator runs after mcp__forgejo__create_repo (or as part of an extended service-onboarding-sop).

Prefer (1) — single source of truth, applies to existing repos retroactively, matches platform IaC philosophy.

File Targets

  • pal-e-services/terraform/services.tf (or a new terraform/labels.tf) — forgejo_label resources or a module wrapping them
  • Possibly: update service-onboarding-sop to remove any "manually create labels" step if present

Acceptance Criteria

  • Standard label set defined as terraform resources (or equivalent IaC)
  • Applied to all existing forgejo_admin/* repos (idempotent — existing labels left alone)
  • New repos created via the onboarding flow get labels automatically
  • Dev agents can mcp__forgejo__set_label against a new repo's first PR without errors
  • Documentation: which labels are canonical (cross-link to convention-architecture-ids, feedback_traceability_triangle)

Test Expectations

  • Pick a recently-created repo (westside-admin) — apply labels via terraform, verify they appear in Forgejo UI
  • Create a synthetic test repo, run terraform, verify labels appear

Constraints

  • Don't overwrite existing labels in repos that already have manual customizations (use lifecycle.ignore_changes for label color if operators have customized colors)
  • Keep label set lean — no aspirational labels nobody uses

Checklist

  • Reviewed via /review-ticket and moved backlog → todo
  • Standard label set canonicalized (likely a list in pal-e-docs convention-architecture-ids or new convention-labels)
  • Terraform implementation
  • PR opened with Closes #THIS
  • Verified on westside-admin retroactively

Related

  • Triggered by: Wave 2A dev agent (PR westside-admin#10)
  • Memory: feedback_traceability_triangle, feedback_discovered_scope_always_tracked
### Type Chore ### Lineage Discovered scope from Wave 2A of westside-admin bootstrap (2026-04-26). Dev agent on PR #10 (Dockerfile) tried to apply `story:admin-row-crud` and `arch:harbor` labels but the westside-admin repo has no labels defined at all. Same gap likely exists for any newly-created Forgejo repo. Worth a one-time bootstrap ticket so the next new-repo arc doesn't hit the same friction. ### Repo forgejo_admin/pal-e-platform (or wherever the repo-init scripts live — verify) ### What Broke When a brand-new Forgejo repo is created via the platform's onboarding flow, no labels are pre-defined. Dev agents writing PRs that reference `story:*` and `arch:*` labels per `feedback_traceability_triangle` find the labels don't exist, so labels can't be applied (or worse, agents try to create labels ad-hoc with inconsistent naming). ### Repro Steps 1. Create a new Forgejo repo via whatever current onboarding flow exists 2. Try to apply a `story:admin-row-crud` label to a PR via `mcp__forgejo__set_label` or via the UI 3. Observe label doesn't exist 4. Repeat for `arch:harbor`, `type:bug`, etc. ### Expected Behavior Newly-created repos have the standard pal-e label set seeded at creation: - `type:bug`, `type:feature`, `type:chore`, `type:infra`, `type:spike` - `story:*` (the active story labels) - `arch:*` (the canonical arch IDs per `convention-architecture-ids`) - Status labels: `status:approved`, `status:needs-changes`, etc. (whatever the existing repos use) ### Environment - Forgejo on tail5b443a - Repo creation via terraform module in `pal-e-services` (per Service Onboarding SOP) OR via manual UI / `mcp__forgejo__create_repo` ### User Story story:platform-stability — As a dev agent dispatched against a new repo's first ticket, I need the standard label set already present so I can apply traceability labels per `feedback_traceability_triangle` without filing yet another bootstrap ticket. ### Context Two implementation paths: 1. **Terraform-side:** add a `forgejo_label` resource per label, `for_each` over the standard set, applied to every repo in the services map. Cleanest, version-controlled. 2. **Bootstrap script:** a one-shot script that the operator runs after `mcp__forgejo__create_repo` (or as part of an extended `service-onboarding-sop`). Prefer (1) — single source of truth, applies to existing repos retroactively, matches platform IaC philosophy. ### File Targets - `pal-e-services/terraform/services.tf` (or a new `terraform/labels.tf`) — `forgejo_label` resources or a module wrapping them - Possibly: update `service-onboarding-sop` to remove any "manually create labels" step if present ### Acceptance Criteria - [ ] Standard label set defined as terraform resources (or equivalent IaC) - [ ] Applied to all existing forgejo_admin/* repos (idempotent — existing labels left alone) - [ ] New repos created via the onboarding flow get labels automatically - [ ] Dev agents can `mcp__forgejo__set_label` against a new repo's first PR without errors - [ ] Documentation: which labels are canonical (cross-link to `convention-architecture-ids`, `feedback_traceability_triangle`) ### Test Expectations - Pick a recently-created repo (westside-admin) — apply labels via terraform, verify they appear in Forgejo UI - Create a synthetic test repo, run terraform, verify labels appear ### Constraints - Don't overwrite existing labels in repos that already have manual customizations (use `lifecycle.ignore_changes` for label color if operators have customized colors) - Keep label set lean — no aspirational labels nobody uses ### Checklist - [ ] Reviewed via /review-ticket and moved backlog → todo - [ ] Standard label set canonicalized (likely a list in pal-e-docs `convention-architecture-ids` or new `convention-labels`) - [ ] Terraform implementation - [ ] PR opened with `Closes #THIS` - [ ] Verified on westside-admin retroactively ### Related - Triggered by: Wave 2A dev agent (PR westside-admin#10) - Memory: `feedback_traceability_triangle`, `feedback_discovered_scope_always_tracked`
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix-gem-bin-path
netpol-westside-ror
fix-woodpecker-multi-pipeline
345-harbor-mobile-css
290-payment-pipeline-observability
spec-board-centric-renderer
284-fix-add-pal-e-docs-namespace-to-postgres
284-add-pal-e-docs-postgres-netpol
188-cross-repo-worktree-isolation-for-parall
111-fix-keycloak-probe
86-fix-rotate-woodpecker-api-token-in-salt
71-feat-deploy-pyrra-slo-manager-with-servi
64-hotfix-woodpecker-oauth-login-broken-for
18-fix-grafana-duplicate-default-datasource-v2
18-fix-grafana-duplicate-default-datasource
13-fix-cnpg-all-parameters
No results found.
Labels
Clear labels   
domain:backend

   
domain:devops

   
domain:frontend

   
status:approved

QA passed, awaiting merge approval

  
status:in-progress

Dev agent is actively working

  
status:needs-fix

QA found issues, back to dev

  
status:qa

PR submitted, awaiting QA review

  
type:bug

Bug fix

  
type:devops

Infrastructure/CI/config work

  
type:feature

New functionality

No labels
domain:backend
domain:devops
domain:frontend
status:approved
status:in-progress
status:needs-fix
status:qa
type:bug
type:devops
type:feature
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ldraney/pal-e-platform#311
No description provided.