ci: Split Docker builds into sequential release and max-perf stages #1017
No reviewers
Labels
No labels
Bug
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status/Blocked
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
To-Merge
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!1017
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "tom/release-max-perf"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Separate fast release builds from slow max-perf builds to optimise runner utilisation and provide quicker feedback.
Release builds complete first with standard optimisations, followed by Haswell-optimised dragrace builds once the safe builds pass successfully.
Extract build logic into focused composite actions for better log visibility in Forgejo UI.
Split monolithic build action into prepare-docker-build, inline docker build step, and upload-docker-artifacts to ensure each phase completes independently and shows logs immediately.
Creates separate manifests at each stage to avoid waiting for all builds before publishing.
eeaf22c1ff3f5d48aa0b3f5d48aa0b8444c3749c8444c3749cbb3dedbf29bb3dedbf2975495aa19875495aa198b606d1d85cb606d1d85c542dff50bd