Release pipelines

Follow builds from source checks to published artifacts. GitHub badges show the latest workflow result; open a pipeline for its running jobs and logs.

Live workflow status

Pipeline	Latest result	Runs and logs
Packages and signed APK publication		Open pipeline
Package source and workflow checks		Open pipeline
Complete device images		Build, verification, and publication
Website deployment		Open pipeline
Porthole checks		Open pipeline
Obscura release		Open pipeline
Tap release		Open pipeline
Phosh NFC release		Open pipeline
Firmware integrity		Open pipeline
pmbootstrap checks		Open pipeline
Chromium checkpoints		Open pipeline
Upstream package drift		Open pipeline
Shared organization automation		Open pipeline
APK repository checks		Open pipeline

Follow a release

1. Packages: source checks and package builds run in pmaports. The publication job signs and uploads the APK indexes and packages.
2. Applications: version releases publish source archives, checksums, and provenance, then propose the matching package update.
3. Device images: available images and their test evidence appear in the downloads and device directory. A green package build does not mean an image has passed hardware testing.
4. Website: the Docs workflow rebuilds the portal and deploys it to Pages.

Published artifacts

• Installable image candidates
• Signed APK repositories
• Obscura releases
• Tap releases
• Phosh NFC releases
• Firmware sources and grant

To receive GitHub notifications, open the relevant repository and choose Watch → Custom → Releases. Workflow failures and running jobs are visible under its Actions tab.

Trigger a release

Maintainers can use Actions → workflow → Run workflow, or the GitHub CLI. Select the primary branch. Branch pushes and pull requests run checks; they do not deploy Pages or publish APKs. Pmaports uses taimen-bringup as its primary branch; the other maintained repositories use main.

# Changed core packages publish automatically after merging. Build selected ones:
gh workflow run build.yml -R porthole-dev/pmaports --ref taimen-bringup -f packages="tap obscura"
# Full image: explicit build using the signed packages already published:
gh workflow run image.yml -R porthole-dev/pmaports --ref taimen-bringup -f device=google-taimen
# Add a complete bundle to an existing candidate without rebuilding its images:
gh workflow run bundle.yml -R porthole-dev/pmaports --ref taimen-bringup -f tag=google-taimen-candidate-6 -f device=google-taimen
# Website refresh:
gh workflow run docs.yml -R porthole-dev/porthole --ref main
# Application release: the version tag must already point to a commit on main:
gh workflow run release.yml -R porthole-dev/tap --ref main -f tag=v0.2.0 -f dry-run=true

The application command rehearses an existing version tag; use dry-run=false when ready to publish that version. Creating a v* tag on a commit merged into main also triggers publication. A tag on an unmerged branch is rejected.

Device image checks evaluate primary-branch pushes and pull requests; expensive image assembly remains explicit. The firmware grant must be approved. Existing candidates and hardware claims are preserved. Core and staged Chromium APK publishers and image/bundle workflows refresh the website after verified upload; the scheduled refresh remains a fallback. For immediate refresh, configure the WEBSITE_TOKEN secret in pmaports’ publish environment: a fine-grained token with only Actions write access to porthole-dev/porthole. The package publisher credential remains scoped to package publication. If no website token is set, the release summary explains that the six-hour scheduled Docs refresh will update the catalog. A configured but invalid token fails visibly.