forgejo_admin/westside-landing
1
0
Fork 1
Code Issues 17 Pull requests 2 Projects Releases Packages Wiki Activity Actions

iOS build pipeline — .woodpecker/ios.yml #79

New issue
Open
opened 2026-03-26 03:49:52 +00:00 by forgejo_admin · 1 comment
forgejo_admin commented 2026-03-26 03:49:52 +00:00
Owner
Copy link

Type

Infra

Lineage

project-capacitor-mobile → Board item (westside first consumer)

Repo

forgejo_admin/westside-app

User Story

As a dev agent
I want push-to-main to trigger an iOS build and TestFlight upload
So that every merge produces a testable iOS build automatically

Context

Woodpecker pipeline that runs on Mac agent (platform=darwin). Steps: npm ci → build → cap sync ios → xcodebuild archive → export → fastlane pilot upload to TestFlight.

Blocked by: Capacitor init (westside-app #78), Mac CI agent (pal-e-platform #166), Fastlane signing (pal-e-platform #167).

File Targets

Files to create:

  • .woodpecker/ios.yml — iOS build pipeline

Files NOT to touch:

  • Existing .woodpecker/*.yml — web pipeline unchanged
  • Application code

Acceptance Criteria

  • Push to main triggers iOS pipeline on Mac agent
  • Pipeline builds SvelteKit → syncs to iOS → archives → exports .ipa
  • Fastlane pilot uploads .ipa to TestFlight
  • Web pipeline continues working independently

Test Expectations

  • Pipeline completes green on Mac agent
  • TestFlight shows new build after pipeline
  • Web pipeline unaffected by new ios.yml

Constraints

  • labels: platform: darwin routes to Mac agent
  • when: branch: main, event: push — only main branch
  • Fastlane match --readonly in pipeline (certs fetched, not generated)

Checklist

  • PR opened
  • Pipeline tested
  • TestFlight build received

Related

  • project-capacitor-mobile — iOS Build Pipeline architecture
  • westside-app #78 — depends on Capacitor init
### Type Infra ### Lineage `project-capacitor-mobile` → Board item (westside first consumer) ### Repo `forgejo_admin/westside-app` ### User Story As a dev agent I want push-to-main to trigger an iOS build and TestFlight upload So that every merge produces a testable iOS build automatically ### Context Woodpecker pipeline that runs on Mac agent (platform=darwin). Steps: npm ci → build → cap sync ios → xcodebuild archive → export → fastlane pilot upload to TestFlight. Blocked by: Capacitor init (westside-app #78), Mac CI agent (pal-e-platform #166), Fastlane signing (pal-e-platform #167). ### File Targets Files to create: - `.woodpecker/ios.yml` — iOS build pipeline Files NOT to touch: - Existing `.woodpecker/*.yml` — web pipeline unchanged - Application code ### Acceptance Criteria - [ ] Push to main triggers iOS pipeline on Mac agent - [ ] Pipeline builds SvelteKit → syncs to iOS → archives → exports .ipa - [ ] Fastlane pilot uploads .ipa to TestFlight - [ ] Web pipeline continues working independently ### Test Expectations - [ ] Pipeline completes green on Mac agent - [ ] TestFlight shows new build after pipeline - [ ] Web pipeline unaffected by new ios.yml ### Constraints - `labels: platform: darwin` routes to Mac agent - `when: branch: main, event: push` — only main branch - Fastlane match --readonly in pipeline (certs fetched, not generated) ### Checklist - [ ] PR opened - [ ] Pipeline tested - [ ] TestFlight build received ### Related - `project-capacitor-mobile` — iOS Build Pipeline architecture - westside-app #78 — depends on Capacitor init
forgejo_admin commented 2026-03-26 10:00:19 +00:00
Author
Owner
Copy link

Ticket Scope Review -- Issue #79

TEMPLATE COMPLIANCE

Checked against template-issue (pal-e-docs). All required sections present:

  • ### Lineage -- project-capacitor-mobile -> Board item (westside first consumer)
  • ### Repo -- forgejo_admin/westside-app
  • ### User Story -- As a dev agent / I want push-to-main to trigger an iOS build and TestFlight upload / So that every merge produces a testable iOS build automatically
  • ### Context -- explains pipeline flow and lists blockers inline
  • ### File Targets -- .woodpecker/ios.yml to create; existing .woodpecker/*.yml and application code explicitly excluded
  • ### Acceptance Criteria -- 4 checkboxes, all testable
  • ### Test Expectations -- 3 items covering pipeline green, TestFlight receipt, web pipeline independence
  • ### Constraints -- platform label routing, branch filter, fastlane match readonly
  • ### Checklist -- standard 3-item checklist
  • ### Related -- references project-capacitor-mobile and #78

Also includes ### Type (Infra) -- not in the canonical template, but consistent with sibling issue #78 and adds clarity. No objection.

TRACEABILITY

Label Source Verified
story:cap-build project-capacitor-mobile User Stories table Yes -- "I want CI to build an iOS binary and upload to TestFlight automatically"
arch:ios-pipeline project-capacitor-mobile Architecture Component IDs table Yes -- ".woodpecker/ios.yml -- npm ci -> build -> cap sync -> xcodebuild -> fastlane pilot"
type:infra Convention label Yes
consumer:westside Board convention for cross-repo items Yes

Board item confirmed on board-capacitor-mobile (item #371, column: backlog).

Note: The traceability labels (story:cap-build, arch:ios-pipeline, type:infra, consumer:westside) live on the board item. The Forgejo issue itself carries domain:backend, domain:devops, domain:frontend. These are two different label systems -- board labels for traceability, Forgejo labels for domain routing. No conflict, but the Forgejo labels could be more precise (this is purely devops/infra, not really frontend or backend work).

FILE TARGETS ASSESSMENT

Specific enough for agent execution:

  • Create: .woodpecker/ios.yml -- single file, clear scope
  • Do not touch: existing .woodpecker/*.yml, application code -- explicit exclusion prevents scope creep

The architecture section on project-capacitor-mobile even documents the exact pipeline steps: npm install -> npm run build -> npx cap sync -> xcodebuild archive -> xcodebuild -exportArchive -> fastlane pilot upload. An agent has everything it needs.

ACCEPTANCE CRITERIA ASSESSMENT

All 4 criteria are testable and map to observable outcomes:

  1. Mac agent receives and executes iOS pipeline -- observable in Woodpecker UI
  2. Pipeline builds SvelteKit -> syncs to iOS -> archives -> exports .ipa -- observable in pipeline logs
  3. Fastlane pilot uploads .ipa to TestFlight -- observable in App Store Connect
  4. Web pipeline continues working independently -- regression check

DEPENDENCY CHECK

Three blockers listed in Context:

Dependency Status Board Column
westside-app #78 (Capacitor init) Done (closed, board: done) Resolved
pal-e-platform #166 (Mac CI agent) Open todo
pal-e-platform #167 (Fastlane signing) Open backlog

Two of three blockers are unresolved. This issue CANNOT move to next_up until #166 (Mac CI agent) and #167 (Fastlane signing) are at minimum in in_progress. The pipeline has nothing to run on without a Mac agent, and nothing to sign with without Fastlane match certificates.

NITS

  1. Forgejo labels mismatch -- domain:frontend is misleading for a CI pipeline file. Consider domain:devops only, or add a blocked label to signal the dependency state.
  2. Test Expectations item 2 ("TestFlight shows new build after pipeline") is a manual verification step, not automatable by the agent. Consider rephrasing to "Pipeline logs show successful fastlane pilot upload exit" for something the agent can verify programmatically.

VERDICT: APPROVED

Ticket is well-scoped, follows template, traceability is fully verified against project-capacitor-mobile (both story and arch labels trace to documented entries). File targets are precise. Acceptance criteria are testable. Dependencies are correctly identified.

Recommended column: remain in backlog until pal-e-platform #166 and #167 are resolved. Once those blockers clear, this is ready for todo -> next_up without further scoping.

## Ticket Scope Review -- Issue #79 ### TEMPLATE COMPLIANCE Checked against `template-issue` (pal-e-docs). All required sections present: - [x] `### Lineage` -- `project-capacitor-mobile` -> Board item (westside first consumer) - [x] `### Repo` -- `forgejo_admin/westside-app` - [x] `### User Story` -- As a dev agent / I want push-to-main to trigger an iOS build and TestFlight upload / So that every merge produces a testable iOS build automatically - [x] `### Context` -- explains pipeline flow and lists blockers inline - [x] `### File Targets` -- `.woodpecker/ios.yml` to create; existing `.woodpecker/*.yml` and application code explicitly excluded - [x] `### Acceptance Criteria` -- 4 checkboxes, all testable - [x] `### Test Expectations` -- 3 items covering pipeline green, TestFlight receipt, web pipeline independence - [x] `### Constraints` -- platform label routing, branch filter, fastlane match readonly - [x] `### Checklist` -- standard 3-item checklist - [x] `### Related` -- references `project-capacitor-mobile` and #78 Also includes `### Type` (Infra) -- not in the canonical template, but consistent with sibling issue #78 and adds clarity. No objection. ### TRACEABILITY | Label | Source | Verified | |-------|--------|----------| | `story:cap-build` | project-capacitor-mobile User Stories table | Yes -- "I want CI to build an iOS binary and upload to TestFlight automatically" | | `arch:ios-pipeline` | project-capacitor-mobile Architecture Component IDs table | Yes -- ".woodpecker/ios.yml -- npm ci -> build -> cap sync -> xcodebuild -> fastlane pilot" | | `type:infra` | Convention label | Yes | | `consumer:westside` | Board convention for cross-repo items | Yes | Board item confirmed on `board-capacitor-mobile` (item #371, column: backlog). Note: The traceability labels (`story:cap-build`, `arch:ios-pipeline`, `type:infra`, `consumer:westside`) live on the board item. The Forgejo issue itself carries `domain:backend`, `domain:devops`, `domain:frontend`. These are two different label systems -- board labels for traceability, Forgejo labels for domain routing. No conflict, but the Forgejo labels could be more precise (this is purely devops/infra, not really frontend or backend work). ### FILE TARGETS ASSESSMENT Specific enough for agent execution: - **Create:** `.woodpecker/ios.yml` -- single file, clear scope - **Do not touch:** existing `.woodpecker/*.yml`, application code -- explicit exclusion prevents scope creep The architecture section on `project-capacitor-mobile` even documents the exact pipeline steps: `npm install -> npm run build -> npx cap sync -> xcodebuild archive -> xcodebuild -exportArchive -> fastlane pilot upload`. An agent has everything it needs. ### ACCEPTANCE CRITERIA ASSESSMENT All 4 criteria are testable and map to observable outcomes: 1. Mac agent receives and executes iOS pipeline -- observable in Woodpecker UI 2. Pipeline builds SvelteKit -> syncs to iOS -> archives -> exports .ipa -- observable in pipeline logs 3. Fastlane pilot uploads .ipa to TestFlight -- observable in App Store Connect 4. Web pipeline continues working independently -- regression check ### DEPENDENCY CHECK Three blockers listed in Context: | Dependency | Status | Board Column | |------------|--------|-------------| | westside-app #78 (Capacitor init) | **Done** (closed, board: done) | Resolved | | pal-e-platform #166 (Mac CI agent) | Open | todo | | pal-e-platform #167 (Fastlane signing) | Open | backlog | Two of three blockers are unresolved. This issue CANNOT move to `next_up` until #166 (Mac CI agent) and #167 (Fastlane signing) are at minimum in `in_progress`. The pipeline has nothing to run on without a Mac agent, and nothing to sign with without Fastlane match certificates. ### NITS 1. **Forgejo labels mismatch** -- `domain:frontend` is misleading for a CI pipeline file. Consider `domain:devops` only, or add a `blocked` label to signal the dependency state. 2. **Test Expectations item 2** ("TestFlight shows new build after pipeline") is a manual verification step, not automatable by the agent. Consider rephrasing to "Pipeline logs show successful `fastlane pilot upload` exit" for something the agent can verify programmatically. ### VERDICT: APPROVED Ticket is well-scoped, follows template, traceability is fully verified against project-capacitor-mobile (both story and arch labels trace to documented entries). File targets are precise. Acceptance criteria are testable. Dependencies are correctly identified. **Recommended column: remain in `backlog` until pal-e-platform #166 and #167 are resolved.** Once those blockers clear, this is ready for `todo` -> `next_up` without further scoping.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
142-validate-coach-login-and-read-only-roste
139-fix-admin-dashboard-stats-showing-all-ze
129-validate-girls-draft-board-coach-login-a
204-auto-tag-update
deploy-update-image-tag
110-fix-harbor-push-target
No results found.
Labels
Clear labels   
domain:backend

   
domain:devops

   
domain:frontend
No labels
domain:backend
domain:devops
domain:frontend
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
forgejo_admin/westside-landing#79
No description provided.