Promote main to lts

[github-actions]

Summary

Promotion of tested changes from to production branch.

IMPORTANT: This PR should ONLY contain commits from → . Never merge in the opposite direction.

[castrojo]

Closing in favor of a conflict-resolved replacement PR.

[dosubot]

Related Documentation

3 document(s) may need updating based on files changed in this PR:

bluefin

Bluefin Newsletter 2.0

View Suggested Changes

@@ -1,7 +1,7 @@
 ## Recent Completed Work
 | Date Completed | Task | Overview | Impact |
 |---|---|---|---|
-| 2026-03-02 | Prevent Branch Pollution with Manual LTS Promotion | A comprehensive three-layer defense was implemented to prevent branch pollution. **Layer 1:** The automated Pull app (`.github/pull.yml`) was removed and replaced with a manual `.github/workflows/promote-to-lts.yml` workflow triggered via workflow_dispatch, requiring manual operator approval for promotions. **Layer 2:** Renovate configuration updated with `baseBranchPatterns: ["main"]` to restrict automated PRs to the main branch only, preventing dependency updates on lts. **Layer 3:** Added `lts` to push triggers in 5 build workflows (build-dx-hwe.yml, build-dx.yml, build-gdx.yml, build-regular-hwe.yml, build-regular.yml) to enable validation builds that catch accidental merges. | Protects production lts branch from automated updates and prevents reverse merges. Ensures controlled, deliberate promotions from main to lts via explicit human action. Validation builds provide safety net against accidental merges without publishing. [Details](https://github.com/ublue-os/bluefin-lts/pull/1152) |
+| 2026-03-02 | Semi-Automated LTS Promotion and Release System | A comprehensive workflow system was implemented to protect the production lts branch while enabling efficient releases. **Layer 1:** The automated Pull app (`.github/pull.yml`) was completely removed and replaced with two workflows: (a) `.github/workflows/promote-to-lts.yml` for manual PR creation from main → lts via workflow_dispatch, ensuring one-way merge direction with proper guardrails, and (b) `.github/workflows/scheduled-lts-release.yml` that runs every Sunday at 2 AM UTC, automatically triggering all 5 build workflows (build-regular, build-dx, build-gdx, build-regular-hwe, build-dx-hwe) on the lts branch for weekly production releases. **Layer 2:** Renovate configuration restricted with `baseBranchPatterns: ["main"]` to prevent automated PRs on lts. **Layer 3:** Push triggers on lts branch enable validation builds (publish=false) when promotion PRs are merged, catching issues before the next scheduled release. Schedule triggers removed from individual build workflows—all scheduled production builds centralized in `scheduled-lts-release.yml`. | Protects production lts branch from automated updates and reverse merges. Decouples promotion from release: maintainers control when main → lts promotions happen, while production releases happen automatically every Sunday or on-demand. Validation builds verify merged code compiles cleanly before production publishing. [Details](https://github.com/ublue-os/bluefin-lts/pull/1152) [Refinement](https://github.com/ublue-os/bluefin-lts/pull/1159) |
 | 2026-02-12 | Expand Renovate Automerge for Container Digests | Renovate automerge now covers digest updates for three additional containers: `quay.io/centos-bootc/bootc-image-builder` (CI tooling), `ghcr.io/ublue-os/akmods-zfs` (ZFS kernel modules), and `ghcr.io/ublue-os/brew` (Homebrew). NVIDIA driver digests remain manual for compatibility review. | Reduces manual PR review for frequent security/bugfix container updates while maintaining CI and branch protections. Improves automation and security posture. [Details](https://github.com/ublue-os/bluefin-lts/pull/1105) |
 | 2026-01-31 | Add ibus-chewing to Bluefin LTS for zh_TW | The ibus-chewing input method is now included in Bluefin LTS, matching the default for the zh_TW locale in Bluefin Stable. This resolves issues where Chewing was configured but not available when installing from older ISOs, and improves the Traditional Chinese typing experience out of the box. | Ensures consistent and functional Traditional Chinese input for zh_TW users on both Stable and LTS. Reduces manual configuration and improves i18n parity. [Details](https://github.com/ublue-os/bluefin-lts/pull/1076) |
 | 2025-12-16 | Reintroduce Renovate Automation | The Renovate dependency automation was restored. The `.github/renovate.json5` configuration was updated to include `ghcr.io/projectbluefin/common` in the automerge dependencies, ensuring that updates to this key dependency are now automatically merged. | Keeps dependencies up to date with less manual intervention, improving security and reliability. [Details](https://github.com/ublue-os/bluefin/pull/3853) |
@@ -24,7 +24,7 @@
 ## Summary Table
 | Date       | Change Summary |
 |------------|---------------|
-| 2026-03-02 | Renovate restricted to main branch; Pull app replaced with manual promotion workflow; validation builds added to lts branch |
+| 2026-03-02 | Pull app removed; semi-automated LTS promotion and release system implemented with manual PR creation and weekly automated production builds |
 | 2026-02-12 | Renovate automerge expanded to cover additional container digests: bootc-image-builder, akmods-zfs, and brew |
 | 2026-01-31 | ibus-chewing input method added to Bluefin LTS for zh_TW locale parity |
 | 2025-12-16 | Renovate automation restored for `ghcr.io/projectbluefin/common` |

[Accept] [Decline]

Bluefin OS

View Suggested Changes

@@ -101,14 +101,14 @@
 
 **Promotion Process:**
 
-Changes flow from `main` to `lts` via the `.github/workflows/promote-to-lts.yml` workflow, which is manually triggered via `workflow_dispatch`. The workflow creates a pull request directly using `gh pr create --base lts --head main`, allowing maintainers to review and approve the promotion. This simplified approach replaced the previous checkout+merge+intermediate-branch method and requires only `pull-requests: write` and `issues: write` permissions (no longer needs `contents: write`).
+Changes flow from `main` to `lts` via the `.github/workflows/promote-to-lts.yml` workflow, which is manually triggered via `workflow_dispatch`. The workflow creates a pull request with the title "Promote main to lts" using `gh pr create --base lts --head main`, allowing maintainers to review and approve the promotion. This approach ensures the merge direction is always `main` → `lts` (never `lts` → `main`) and requires only `pull-requests: write` and `issues: write` permissions. The previous `.github/pull.yml` configuration file has been removed.
 
 **Build Triggers:**
 
 All LTS build workflows (build-dx.yml, build-dx-hwe.yml, build-gdx.yml, build-regular.yml, build-regular-hwe.yml) trigger on both `main` and `lts` branches:
 
 - **Builds on `main`**: Triggered by pushes, pull requests, and merge groups for validation and testing
-- **Builds on `lts`**: Triggered by pushes (including merged promotion PRs) for production releases. Weekly scheduled builds (Sundays at 2 AM UTC) are centralized through a dispatcher workflow (`scheduled-lts-release.yml`), with individual workflow `schedule:` triggers removed to prevent duplicate builds
+- **Builds on `lts`**: Triggered by pushes (including merged promotion PRs) for production releases. Weekly scheduled builds (Sundays at 2 AM UTC) are centralized through a dispatcher workflow (`scheduled-lts-release.yml`) that triggers all 5 build workflows on the `lts` branch via `workflow_dispatch`. Individual workflow `schedule:` cron triggers have been removed to prevent duplicate builds
 
 **Dependency Management:**
 
@@ -119,10 +119,10 @@
 The build workflows have been refined to ensure reliable image publishing:
 
 - **Tag pollution prevention**: The manifest step logic aligns with the build step logic, checking `if [ "${REF_NAME}" != "${PRODUCTION_BRANCH}" ]` to apply the `-testing` suffix consistently. This prevents production tags from being overwritten by testing builds when merging to `main`.
-- **Manifest and signing fixes**: The "Push Manifest" and "sign" steps are now properly gated on `inputs.publish` instead of `github.event_name != 'pull_request'`, which fixes "image not known" errors that previously occurred when these steps fired on validation builds.
+- **Manifest and signing fixes**: The "Push Manifest" and "sign" steps are gated on `inputs.publish`, which fixes "image not known" errors that previously occurred when these steps fired on validation builds.
 - **Default publish behavior**: The `publish` input in `reusable-build-image.yml` defaults to `false` for improved safety, requiring callers to explicitly opt in to image publishing.
 
-SBOM (Software Bill of Materials) artifacts are generated only for builds on the `lts` branch when `inputs.publish` is true (condition: `github.ref == 'refs/heads/lts' && inputs.publish`). All SBOM steps include `continue-on-error: true` to ensure that external service outages (such as Sigstore/Rekor) never block image publishing. The `sbom:` input parameter has been removed from the reusable workflow.
+SBOM (Software Bill of Materials) artifacts are generated only for builds on the `lts` branch when `inputs.publish` is true (condition: `github.ref == 'refs/heads/lts' && inputs.publish`). All SBOM steps include `continue-on-error: true` to ensure that external service outages (such as Sigstore/Rekor) never block image publishing.
 
 ### Rebasing Between Variants
 
@@ -180,9 +180,9 @@
 Build workflows trigger on multiple events to support both development and production workflows:
 
 - **main branch**: Builds triggered by push events, pull requests, and merge groups for validation and testing
-- **lts branch**: Builds triggered by push events (including merged promotion PRs) for production releases. Weekly scheduled builds (Sundays at 2 AM UTC) are centralized through a dispatcher workflow (`scheduled-lts-release.yml`), with individual workflow `schedule:` triggers removed to prevent duplicate builds
-
-All LTS variant build workflows (build-dx.yml, build-dx-hwe.yml, build-gdx.yml, build-regular.yml, build-regular-hwe.yml) trigger on both branches to ensure changes are validated before promotion to production.
+- **lts branch**: Builds triggered by push events (including merged promotion PRs) for production releases. Weekly scheduled builds (Sundays at 2 AM UTC) are centralized through a dispatcher workflow (`scheduled-lts-release.yml`) that triggers all 5 build workflows (build-dx.yml, build-dx-hwe.yml, build-gdx.yml, build-regular.yml, build-regular-hwe.yml) on the `lts` branch via `workflow_dispatch`. Individual workflow `schedule:` cron triggers have been removed to prevent duplicate builds
+
+All LTS variant build workflows trigger on both branches to ensure changes are validated before promotion to production.
 
 ### SBOM Generation
 

[Accept] [Decline]

Universal Blue Build and Update System

View Suggested Changes

@@ -46,30 +46,31 @@
 - Manual `workflow_dispatch` triggers
 
 **LTS branch triggers:**
-- A dispatcher workflow (`scheduled-lts-release.yml`) runs weekly on Sunday at 2 AM UTC on the default branch
-- The dispatcher triggers all 5 build workflows on the `lts` branch via `workflow_dispatch` events
+- The `scheduled-lts-release.yml` dispatcher workflow runs weekly on Sunday at 2 AM UTC (`cron: '0 2 * * 0'`) on the default branch
+- The dispatcher triggers all 5 build workflows (`build-regular.yml`, `build-dx.yml`, `build-gdx.yml`, `build-regular-hwe.yml`, `build-dx-hwe.yml`) on the `lts` branch via `gh workflow run` commands with `--ref lts`
 - Push events to `lts` branch trigger validation builds but do NOT publish production tags
 - Pull requests to `lts` branch do NOT trigger workflows (prevents accidental publishes)
 - Manual `workflow_dispatch` triggers (for emergency releases)
-- Individual build workflows no longer have `schedule:` triggers—the centralized dispatcher eliminates 10 duplicate no-op builds that previously ran on `main` every Sunday alongside the 5 dispatcher runs on `lts`, working around GitHub Actions limitation that scheduled triggers always run on the default branch
+- Individual build workflows no longer have `schedule:` triggers—the centralized dispatcher is the sole owner of scheduled production releases, eliminating duplicate no-op builds and working around GitHub Actions limitation that scheduled triggers always run on the default branch
 
 This architecture prevents accidental production tag publishing while maintaining validation builds on merges. The validation builds on `lts` push events provide a third layer of defense against branch pollution by verifying code integrity when promotion PRs merge.
 
 **Dispatcher Workflow Architecture:**
 
-The dispatcher pattern solves a GitHub Actions constraint where scheduled triggers always execute on the default branch. The `scheduled-lts-release.yml` workflow runs on `main` and uses GitHub CLI to trigger all 5 build workflows on the `lts` branch via `workflow_dispatch` events. This ensures production releases build from the stable `lts` branch code rather than the more frequently updated `main` branch. See [docs/plans/2026-03-02-fix-lts-tag-publishing.md](https://github.com/ublue-os/bluefin/blob/main/docs/plans/2026-03-02-fix-lts-tag-publishing.md) for complete implementation details.
+The dispatcher pattern solves a GitHub Actions constraint where scheduled triggers always execute on the default branch. The `scheduled-lts-release.yml` workflow runs on `main` with `schedule: - cron: '0 2 * * 0'` (weekly on Sunday at 2 AM UTC) and uses GitHub CLI commands (`gh workflow run [workflow].yml --ref lts -R ${{ github.repository }}`) to trigger all 5 build workflows on the `lts` branch via `workflow_dispatch` events. The workflow also includes `workflow_dispatch:` trigger to allow manual execution for on-demand production releases. This ensures production releases build from the stable `lts` branch code rather than the more frequently updated `main` branch. See [docs/plans/2026-03-02-fix-lts-tag-publishing.md](https://github.com/ublue-os/bluefin/blob/main/docs/plans/2026-03-02-fix-lts-tag-publishing.md) for complete implementation details.
 
 **Branch Management and Promotion Strategy:**
 
 The system implements a three-layer defense strategy to protect the `lts` production branch from accidental pollution:
 
-**Layer 1: Manual Promotion Workflow** - A manual `promote-to-lts.yml` workflow enables explicit promotion of tested changes from `main` to `lts`. The workflow:
+**Layer 1: Manual Promotion Workflow** - The `promote-to-lts.yml` workflow enables explicit promotion of tested changes from `main` to `lts`. The workflow:
 - Requires manual trigger via GitHub Actions UI (`workflow_dispatch`)
-- Uses `gh pr create --base lts --head main` to directly create promotion PRs without intermediate branches
-- Opens pull request with documentation warning against reverse merges
+- Creates pull requests directly from `main` → `lts` using `gh pr create --base lts --head main`
+- Includes customizable PR title (default: "Promote main to lts") and body warning against reverse merges
+- Adds `promotion` label to PRs for easy identification
 - Requires operator review and approval before merging
 - Only requires `pull-requests: write` and `issues: write` permissions (no `contents: write` needed)
-- Replaces the previous automatic Pull app (`.github/pull.yml` has been deleted)
+- Replaces the previous automatic Pull app (`.github/pull.yml` was deleted in PR #1159)
 
 **Layer 2: Renovate Restriction** - Renovate configuration restricts dependency updates to target only the `main` branch via `baseBranchPatterns: ["main"]`. This prevents automated dependency PRs from targeting the `lts` branch, ensuring the production branch receives updates only through manual promotion.
 
@@ -108,7 +109,7 @@
 - ❌ Skipped on pull requests to any branch
 - ❌ Skipped on validation builds (push events to `lts` branch that don't publish)
 
-The `sbom:` input parameter has been removed from `reusable-build-image.yml`. SBOM behavior is controlled entirely by step-level conditions checking the branch reference and publish status. The workflow defaults `publish` to `false` for safety—callers must explicitly opt in to publishing.
+SBOM behavior is controlled entirely by step-level conditions (`if: ${{ github.ref == 'refs/heads/lts' && inputs.publish }}`) checking the branch reference and publish status. The workflow defaults `publish` to `false` for safety—callers must explicitly opt in to publishing.
 
 For LTS production releases, SBOMs are generated weekly through the dispatcher pattern. The ublue-os/main repository has SBOM generation disabled but implementation preserved.
 

[Accept] [Decline]

Note: You must be authenticated to accept/decline updates.

^{How did I do? Any feedback?}