forgejo_admin/pal-e-platform

Fork 0

Fastlane match — iOS code signing setup #167

New issue

Open

opened 2026-03-26 03:49:43 +00:00 by forgejo_admin · 3 comments

forgejo_admin commented

2026-03-26 03:49:43 +00:00

Owner

Type

Infra

Lineage

project-capacitor-mobile → Board item (platform infrastructure)

Repo

forgejo_admin/pal-e-platform

User Story

As a dev agent
I want signing certificates managed automatically via Fastlane match
So that iOS builds are signed without manual Xcode intervention

Context

Fastlane match stores signing certificates and provisioning profiles in a git repo. Using git storage mode with a private Forgejo repo forgejo_admin/ios-certificates. This is platform infrastructure — serves all iOS apps.

Blocked by: Apple Developer enrollment (pal-e-platform #164).

File Targets

Files to create:

Forgejo repo forgejo_admin/ios-certificates (private)
Fastlane match config (Matchfile) — template for app repos

Files NOT to touch:

App repo code — each app adds its own Matchfile later

Acceptance Criteria

Private Forgejo repo ios-certificates created
fastlane match init configured with git storage pointing to Forgejo repo
fastlane match development generates dev certificate + profile
fastlane match appstore generates distribution certificate + profile
Certificates stored encrypted in git repo

Test Expectations

fastlane match appstore --readonly retrieves certs without error
Certificate valid for westside app bundle ID

Constraints

Git storage mode (Forgejo-compatible, not GitHub-specific)
Match encryption passphrase stored securely (document in secrets management)

Checklist

Repo created
Certificates generated
Readonly retrieval verified

project-capacitor-mobile — signing architecture
pal-e-platform #164 — blocked by Apple enrollment

### Type Infra ### Lineage `project-capacitor-mobile` → Board item (platform infrastructure) ### Repo `forgejo_admin/pal-e-platform` ### User Story As a dev agent I want signing certificates managed automatically via Fastlane match So that iOS builds are signed without manual Xcode intervention ### Context Fastlane match stores signing certificates and provisioning profiles in a git repo. Using `git` storage mode with a private Forgejo repo `forgejo_admin/ios-certificates`. This is platform infrastructure — serves all iOS apps. Blocked by: Apple Developer enrollment (pal-e-platform #164). ### File Targets Files to create: - Forgejo repo `forgejo_admin/ios-certificates` (private) - Fastlane match config (Matchfile) — template for app repos Files NOT to touch: - App repo code — each app adds its own Matchfile later ### Acceptance Criteria - [ ] Private Forgejo repo `ios-certificates` created - [ ] `fastlane match init` configured with git storage pointing to Forgejo repo - [ ] `fastlane match development` generates dev certificate + profile - [ ] `fastlane match appstore` generates distribution certificate + profile - [ ] Certificates stored encrypted in git repo ### Test Expectations - [ ] `fastlane match appstore --readonly` retrieves certs without error - [ ] Certificate valid for westside app bundle ID ### Constraints - Git storage mode (Forgejo-compatible, not GitHub-specific) - Match encryption passphrase stored securely (document in secrets management) ### Checklist - [ ] Repo created - [ ] Certificates generated - [ ] Readonly retrieval verified ### Related - `project-capacitor-mobile` — signing architecture - pal-e-platform #164 — blocked by Apple enrollment

forgejo_admin commented

2026-03-26 10:00:26 +00:00

Author

Owner

Ticket Scope Review: #167

TEMPLATE COMPLIANCE

Checked against template-issue (the canonical Forgejo issue template).

Section	Template Expects	Issue Has	Status
`### Lineage`	Yes	Yes (`project-capacitor-mobile` -> Board item)	PASS
`### Repo`	Yes	Yes (`forgejo_admin/pal-e-platform`)	PASS
`### User Story`	Yes	Yes (As a dev agent / I want signing certificates managed automatically via Fastlane match / So that iOS builds are signed without manual Xcode intervention)	PASS
`### Context`	Yes	Yes (explains match git storage mode, Forgejo repo, blocker)	PASS
`### File Targets`	Yes	Yes (create list + NOT touch list)	PASS
`### Acceptance Criteria`	Yes	Yes (5 checkboxes)	PASS
`### Test Expectations`	Yes	Yes (2 checkboxes)	PASS
`### Constraints`	Yes	Yes (git storage mode, secrets management)	PASS
`### Checklist`	Yes	Yes (3 checkboxes)	PASS
`### Related`	Yes	Yes (project-capacitor-mobile, #164)	PASS

Extra section: ### Type (value: "Infra") -- not in the template. Non-blocking, but this is not a standard template field. The type:infra label on the board item already conveys this. Recommend removing to keep issues template-clean.

Lineage format: Uses project-capacitor-mobile -> Board item (platform infrastructure) which is correct under convention-kanban-over-plans (plans are obsolete, board is the decomposition tool). No plan ancestry expected.

TRACEABILITY CHECK

Label	Traces to project-capacitor-mobile?	Details
`story:cap-build`	YES	User story key `cap-build`: "I want CI to build an iOS binary and upload to TestFlight automatically"
`arch:signing`	YES	Architecture component "Code Signing: Fastlane match, certificates, provisioning profiles (dev + distribution)"
`type:infra`	N/A (type label, not traced to project)	Consistent with infrastructure work
`consumer:westside`	YES	Board convention identifies westside-app as first consumer

All story: and arch: labels trace to documented entries on project-capacitor-mobile. Traceability triangle is intact.

FORGEJO LABEL GAP

The Forgejo issue has zero labels applied (labels array is empty). The board item on board-capacitor-mobile has labels story:cap-build,arch:signing,type:infra,consumer:westside -- but those are board-level labels only. The Forgejo issue itself should carry matching labels for discoverability and hook compatibility (e.g., status:* labels set by QA hooks).

Action required: Apply Forgejo labels to the issue: story:cap-build, arch:signing, type:infra, consumer:westside.

FILE TARGETS ASSESSMENT

Specificity: Adequate for agent execution.

Create: Forgejo repo forgejo_admin/ios-certificates (private) -- clear target
Create: Matchfile template for app repos -- clear target
NOT touch: app repo code -- good boundary

Gap: No explicit file path for where the Matchfile template lives. Is it committed to ios-certificates? To pal-e-platform? The agent will need to decide. Recommend specifying: "Create Matchfile in ios-certificates repo root" or wherever it belongs.

ACCEPTANCE CRITERIA ASSESSMENT

All 5 criteria are testable:

Private repo created -- verifiable via Forgejo API
fastlane match init configured -- verifiable by running command
fastlane match development generates certs -- verifiable by running command
fastlane match appstore generates certs -- verifiable by running command
Certificates stored encrypted in git -- verifiable by inspecting repo contents

TEST EXPECTATIONS ASSESSMENT

Both test expectations are verifiable:

fastlane match appstore --readonly retrieves certs -- command-line verification
Certificate valid for westside app bundle ID -- verifiable via cert inspection

Gap: No bundle ID is specified anywhere in the issue. The agent needs to know the exact bundle ID (e.g., com.westsidebasketball.app or similar). This should be stated in Context or Constraints.

DEPENDENCY CHECK

Blocked by #164 (Apple Developer Program enrollment) -- correctly identified
#164 is on board-capacitor-mobile in backlog column, also not yet done
Dependency chain is valid: you cannot create signing certificates without an Apple Developer account

BOARD ALIGNMENT

Board item #370 exists on board-capacitor-mobile
Currently in backlog column -- consistent with being blocked by #164
Labels match: story:cap-build,arch:signing,type:infra,consumer:westside

ITEMS TO FIX

[Required] Forgejo labels missing -- Apply story:cap-build, arch:signing, type:infra, consumer:westside as Forgejo issue labels (not just board-item labels)
[Required] Bundle ID not specified -- Add the westside app bundle ID to Context or Constraints. The agent cannot generate signing certificates without knowing the exact bundle ID.
[Recommended] Matchfile location ambiguous -- Specify which repo the Matchfile template lives in (ios-certificates root? pal-e-platform docs?)
[Nit] Remove ### Type section -- Not in template-issue; type is already conveyed by the type:infra board label

VERDICT: NEEDS WORK

Two required items before this ticket is ready for next_up:

Apply Forgejo labels to the issue for hook compatibility
Specify the westside app bundle ID -- agent cannot execute signing setup without it

## Ticket Scope Review: #167 ### TEMPLATE COMPLIANCE Checked against `template-issue` (the canonical Forgejo issue template). | Section | Template Expects | Issue Has | Status | |---------|-----------------|-----------|--------| | `### Lineage` | Yes | Yes (`project-capacitor-mobile` -> Board item) | PASS | | `### Repo` | Yes | Yes (`forgejo_admin/pal-e-platform`) | PASS | | `### User Story` | Yes | Yes (As a dev agent / I want signing certificates managed automatically via Fastlane match / So that iOS builds are signed without manual Xcode intervention) | PASS | | `### Context` | Yes | Yes (explains match git storage mode, Forgejo repo, blocker) | PASS | | `### File Targets` | Yes | Yes (create list + NOT touch list) | PASS | | `### Acceptance Criteria` | Yes | Yes (5 checkboxes) | PASS | | `### Test Expectations` | Yes | Yes (2 checkboxes) | PASS | | `### Constraints` | Yes | Yes (git storage mode, secrets management) | PASS | | `### Checklist` | Yes | Yes (3 checkboxes) | PASS | | `### Related` | Yes | Yes (project-capacitor-mobile, #164) | PASS | **Extra section:** `### Type` (value: "Infra") -- not in the template. Non-blocking, but this is not a standard template field. The `type:infra` label on the board item already conveys this. Recommend removing to keep issues template-clean. **Lineage format:** Uses `project-capacitor-mobile -> Board item (platform infrastructure)` which is correct under `convention-kanban-over-plans` (plans are obsolete, board is the decomposition tool). No plan ancestry expected. ### TRACEABILITY CHECK | Label | Traces to project-capacitor-mobile? | Details | |-------|--------------------------------------|---------| | `story:cap-build` | YES | User story key `cap-build`: "I want CI to build an iOS binary and upload to TestFlight automatically" | | `arch:signing` | YES | Architecture component "Code Signing: Fastlane match, certificates, provisioning profiles (dev + distribution)" | | `type:infra` | N/A (type label, not traced to project) | Consistent with infrastructure work | | `consumer:westside` | YES | Board convention identifies westside-app as first consumer | All story: and arch: labels trace to documented entries on project-capacitor-mobile. Traceability triangle is intact. ### FORGEJO LABEL GAP The Forgejo issue has **zero labels applied** (labels array is empty). The board item on board-capacitor-mobile has labels `story:cap-build,arch:signing,type:infra,consumer:westside` -- but those are board-level labels only. The Forgejo issue itself should carry matching labels for discoverability and hook compatibility (e.g., `status:*` labels set by QA hooks). **Action required:** Apply Forgejo labels to the issue: `story:cap-build`, `arch:signing`, `type:infra`, `consumer:westside`. ### FILE TARGETS ASSESSMENT **Specificity:** Adequate for agent execution. - Create: Forgejo repo `forgejo_admin/ios-certificates` (private) -- clear target - Create: Matchfile template for app repos -- clear target - NOT touch: app repo code -- good boundary **Gap:** No explicit file path for where the Matchfile template lives. Is it committed to `ios-certificates`? To `pal-e-platform`? The agent will need to decide. Recommend specifying: "Create `Matchfile` in `ios-certificates` repo root" or wherever it belongs. ### ACCEPTANCE CRITERIA ASSESSMENT All 5 criteria are testable: 1. Private repo created -- verifiable via Forgejo API 2. `fastlane match init` configured -- verifiable by running command 3. `fastlane match development` generates certs -- verifiable by running command 4. `fastlane match appstore` generates certs -- verifiable by running command 5. Certificates stored encrypted in git -- verifiable by inspecting repo contents ### TEST EXPECTATIONS ASSESSMENT Both test expectations are verifiable: 1. `fastlane match appstore --readonly` retrieves certs -- command-line verification 2. Certificate valid for westside app bundle ID -- verifiable via cert inspection **Gap:** No bundle ID is specified anywhere in the issue. The agent needs to know the exact bundle ID (e.g., `com.westsidebasketball.app` or similar). This should be stated in Context or Constraints. ### DEPENDENCY CHECK - **Blocked by #164** (Apple Developer Program enrollment) -- correctly identified - #164 is on board-capacitor-mobile in backlog column, also not yet done - Dependency chain is valid: you cannot create signing certificates without an Apple Developer account ### BOARD ALIGNMENT - Board item #370 exists on board-capacitor-mobile - Currently in **backlog** column -- consistent with being blocked by #164 - Labels match: `story:cap-build,arch:signing,type:infra,consumer:westside` ### ITEMS TO FIX 1. **[Required] Forgejo labels missing** -- Apply `story:cap-build`, `arch:signing`, `type:infra`, `consumer:westside` as Forgejo issue labels (not just board-item labels) 2. **[Required] Bundle ID not specified** -- Add the westside app bundle ID to Context or Constraints. The agent cannot generate signing certificates without knowing the exact bundle ID. 3. **[Recommended] Matchfile location ambiguous** -- Specify which repo the Matchfile template lives in (ios-certificates root? pal-e-platform docs?) 4. **[Nit] Remove `### Type` section** -- Not in template-issue; type is already conveyed by the `type:infra` board label ### VERDICT: NEEDS WORK Two required items before this ticket is ready for next_up: 1. Apply Forgejo labels to the issue for hook compatibility 2. Specify the westside app bundle ID -- agent cannot execute signing setup without it

forgejo_admin referenced this issue

2026-03-26 10:01:11 +00:00

Apple Developer Program enrollment #164

forgejo_admin commented

2026-03-26 14:35:10 +00:00

Author

Owner

Ticket Fix (QA review remediation)

Bundle ID (specified)

com.westsidekingsandqueens.app — as defined in capacitor.config.ts (PR #83).

Forgejo Labels

Need to apply: domain:infra, status:new (or appropriate status label for hook compatibility).

Blocker

This ticket IS blocked by Apple Developer enrollment (#164, blocker:external — budget). Fastlane match requires a paid Apple Developer account to generate signing certificates. Cannot proceed without it.

Labels updated on board item: blocker:external added.

## Ticket Fix (QA review remediation) ### Bundle ID (specified) `com.westsidekingsandqueens.app` — as defined in `capacitor.config.ts` (PR #83). ### Forgejo Labels Need to apply: `domain:infra`, `status:new` (or appropriate status label for hook compatibility). ### Blocker This ticket IS blocked by Apple Developer enrollment (#164, `blocker:external` — budget). Fastlane match requires a paid Apple Developer account to generate signing certificates. Cannot proceed without it. Labels updated on board item: `blocker:external` added.

forgejo_admin commented

2026-03-26 14:38:33 +00:00

Author

Owner

Ticket #167 Re-Review

Re-review following QA scope review (comment 1) which found two required items, and the fix comment (comment 2) which addressed them.

FINDING 1: Bundle ID -- RESOLVED

The fix comment specifies com.westsidekingsandqueens.app. Verified against source of truth:

/home/ldraney/westside-app/capacitor.config.ts line 4: appId: 'com.westsidekingsandqueens.app'
/home/ldraney/westside-app/ios/App/App/capacitor.config.json line 2: confirms same value
Referenced as coming from PR #83 -- provenance is clear

This finding is fully resolved. The agent now has the bundle ID needed to generate signing certificates.

FINDING 2: Forgejo Labels -- NOT RESOLVED

The fix comment states "Need to apply: domain:infra, status:new" but this has two problems:

A) Labels not actually applied. The Forgejo issue still has zero labels (labels: []). The fix comment describes intent but did not execute. The labels must be applied to the issue, not just mentioned in a comment.

B) Suggested labels do not exist on this repo. Available Forgejo labels on pal-e-platform are:

domain:backend, domain:devops, domain:frontend
status:approved, status:in-progress, status:needs-fix, status:qa
type:bug, type:devops, type:feature

Neither domain:infra nor status:new exist. The correct labels to apply from available options would be:

domain:devops (closest match for infrastructure/signing work)
type:devops (matches the infra nature of the work)

No status:* label needed at this point -- the QA hooks set status:approved or status:needs-fix automatically when a PR is reviewed. For a ticket still in backlog with no PR, no status label is expected.

Note: The traceability labels (story:cap-build, arch:signing, consumer:westside) are board-item labels in pal-e-docs, not Forgejo issue labels. This is correct -- the board is the traceability tool. The original review's ask was specifically about Forgejo labels for discoverability and hook compatibility, which means domain:* and type:* labels.

TRACEABILITY VERIFICATION

Trace	Source	Target	Status
`story:cap-build`	Board item #370	project-capacitor-mobile user story "I want CI to build an iOS binary and upload to TestFlight automatically"	VERIFIED
`arch:signing`	Board item #370	project-capacitor-mobile arch table "Code Signing: Fastlane match, certificates, provisioning profiles"	VERIFIED
`blocker:external`	Board item #370	#164 Apple Developer enrollment (budget dependency)	VERIFIED
`consumer:westside`	Board item #370	westside-app is first consumer	VERIFIED

Traceability triangle is intact. All board-level labels trace correctly to project-capacitor-mobile.

BLOCKER STATUS

Confirmed: This ticket is correctly blocked by #164 (Apple Developer Program enrollment, blocker:external -- budget). The blocker:external label was added to the board item as stated in the fix comment. The dependency chain is valid -- Fastlane match cannot generate signing certificates without a paid Apple Developer account.

REMAINING ACTION

One item remains before this ticket is ready for next_up:

Apply Forgejo labels to the issue itself: domain:devops and type:devops (from the available label set). This is a 10-second action via the Forgejo UI or API.

The bundle ID gap is closed. The Matchfile location ambiguity (nit from original review) was not addressed but remains non-blocking -- the agent can infer it from context.

VERDICT: NOT APPROVED

One required finding remains unresolved: Forgejo labels are still not applied to the issue. The fix comment described what labels to add but (a) did not apply them and (b) referenced labels that do not exist on this repo. Apply domain:devops + type:devops from the available label set, and this ticket is ready.

## Ticket #167 Re-Review Re-review following QA scope review (comment 1) which found two required items, and the fix comment (comment 2) which addressed them. ### FINDING 1: Bundle ID -- RESOLVED The fix comment specifies `com.westsidekingsandqueens.app`. Verified against source of truth: - `/home/ldraney/westside-app/capacitor.config.ts` line 4: `appId: 'com.westsidekingsandqueens.app'` - `/home/ldraney/westside-app/ios/App/App/capacitor.config.json` line 2: confirms same value - Referenced as coming from PR #83 -- provenance is clear This finding is fully resolved. The agent now has the bundle ID needed to generate signing certificates. ### FINDING 2: Forgejo Labels -- NOT RESOLVED The fix comment states "Need to apply: `domain:infra`, `status:new`" but this has two problems: **A) Labels not actually applied.** The Forgejo issue still has zero labels (`labels: []`). The fix comment describes intent but did not execute. The labels must be applied to the issue, not just mentioned in a comment. **B) Suggested labels do not exist on this repo.** Available Forgejo labels on pal-e-platform are: - `domain:backend`, `domain:devops`, `domain:frontend` - `status:approved`, `status:in-progress`, `status:needs-fix`, `status:qa` - `type:bug`, `type:devops`, `type:feature` Neither `domain:infra` nor `status:new` exist. The correct labels to apply from available options would be: - `domain:devops` (closest match for infrastructure/signing work) - `type:devops` (matches the infra nature of the work) No `status:*` label needed at this point -- the QA hooks set `status:approved` or `status:needs-fix` automatically when a PR is reviewed. For a ticket still in backlog with no PR, no status label is expected. Note: The traceability labels (`story:cap-build`, `arch:signing`, `consumer:westside`) are board-item labels in pal-e-docs, not Forgejo issue labels. This is correct -- the board is the traceability tool. The original review's ask was specifically about Forgejo labels for discoverability and hook compatibility, which means `domain:*` and `type:*` labels. ### TRACEABILITY VERIFICATION | Trace | Source | Target | Status | |-------|--------|--------|--------| | `story:cap-build` | Board item #370 | project-capacitor-mobile user story "I want CI to build an iOS binary and upload to TestFlight automatically" | VERIFIED | | `arch:signing` | Board item #370 | project-capacitor-mobile arch table "Code Signing: Fastlane match, certificates, provisioning profiles" | VERIFIED | | `blocker:external` | Board item #370 | #164 Apple Developer enrollment (budget dependency) | VERIFIED | | `consumer:westside` | Board item #370 | westside-app is first consumer | VERIFIED | Traceability triangle is intact. All board-level labels trace correctly to project-capacitor-mobile. ### BLOCKER STATUS Confirmed: This ticket is correctly blocked by #164 (Apple Developer Program enrollment, `blocker:external` -- budget). The `blocker:external` label was added to the board item as stated in the fix comment. The dependency chain is valid -- Fastlane match cannot generate signing certificates without a paid Apple Developer account. ### REMAINING ACTION One item remains before this ticket is ready for next_up: 1. **Apply Forgejo labels** to the issue itself: `domain:devops` and `type:devops` (from the available label set). This is a 10-second action via the Forgejo UI or API. The bundle ID gap is closed. The Matchfile location ambiguity (nit from original review) was not addressed but remains non-blocking -- the agent can infer it from context. ### VERDICT: NOT APPROVED One required finding remains unresolved: Forgejo labels are still not applied to the issue. The fix comment described what labels to add but (a) did not apply them and (b) referenced labels that do not exist on this repo. Apply `domain:devops` + `type:devops` from the available label set, and this ticket is ready.

forgejo_admin added the

domain:devops

type:devops

labels

2026-03-26 14:39:28 +00:00