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
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.
eeaf22c1ff
3f5d48aa0b
3f5d48aa0b
8444c3749c
8444c3749c
bb3dedbf29
bb3dedbf29
75495aa198
75495aa198
b606d1d85c
b606d1d85c
542dff50bd