fix(ci): promote workflow fixes from main to lts (conflict-resolved)

[castrojo]

Summary

Brings lts up to date with all CI workflow fixes that landed on main since the last promotion (PR #1153). Conflicts in PR #1159 were caused by diverged history from old pull-bot merge commits on lts; all conflicts resolved by taking main's version.

Changes

• Remove schedule: from all 5 caller workflows (owned exclusively by scheduled-lts-release.yml)
• Remove sbom: input from reusable workflow; SBOM steps now gated on github.ref == refs/heads/lts && inputs.publish
• Add continue-on-error: true to all 3 SBOM steps
• Gate Push Manifest and sign job on inputs.publish (fixes build failures on push-to-lts validation builds)
• Change publish default from true to false
• Fix generate-release.yml to only fire on workflow_dispatch-triggered builds (not push-to-lts)
• Simplify promote-to-lts.yml to use gh pr create --head main (no intermediate branch)
• Delete docs/plans/ directory
• Update AGENTS.md with authoritative CI architecture documentation

Why conflicts existed

lts diverged from main at 64cb487 due to pull-bot merge commits landing directly on lts. Those commits (fbd92a4, cb9f096, 7d95440) have no counterpart in main's history, forcing a 3-way merge. All conflicts were in workflow files — resolved by taking main's version in every case.

After merging

Validation builds (push-triggered, publish=false) will run on lts for all 5 variants. They should all pass cleanly — this was verified as the fix for the failures that occurred after PR #1153 merged.

Closes #1159

[castrojo]

Closing — approach was wrong. A merge drags polluted history into lts. Replacing with a direct file-update commit.

[dosubot]

Related Documentation

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

bluefin

Bluefin OS

View Suggested Changes

@@ -101,7 +101,7 @@
 
 **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 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.
+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 from `main` to `lts` using `gh pr create --base lts --head main` (no intermediate branch), 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.
 
 **Build Triggers:**
 
@@ -119,10 +119,12 @@
 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 gated on `inputs.publish`, 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" job are gated on `inputs.publish`, which prevents "image not known" errors 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.
+
+For complete CI/CD architecture documentation, including workflow roles, publish conditions, and troubleshooting guidance, see [`AGENTS.md`](https://github.com/ublue-os/bluefin-lts/blob/main/AGENTS.md) in the repository.
 
 ### Rebasing Between Variants
 
@@ -186,7 +188,7 @@
 
 ### SBOM Generation
 
-SBOM (Software Bill of Materials) generation with Syft is performed 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, ensuring supply chain transparency for production releases without risking build failures.
+SBOM (Software Bill of Materials) generation with Syft is performed 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. This provides supply chain transparency for production releases without risking build failures from external dependencies.
 
 [Automated Brewfile validation runs in the CI pipeline](https://app.dosu.dev/documents/4da0c9c8-3220-465d-9212-174c99baf3fe), and [GitHub Actions matrix builds handle variants and streams](https://github.com/ublue-os/bluefin/blob/1a5c8d9e5aaf38c7b10f35d7162f5f36d9f883f7/.github/workflows/reusable-build.yml#L36-L39). [image-versions.yml tracks SHA256 digests for base images](https://github.com/ublue-os/bluefin/blob/1a5c8d9e5aaf38c7b10f35d7162f5f36d9f883f7/image-versions.yml#L1-L14), with [version format: stream-fedora_version.YYYYMMDD[.point]](https://github.com/ublue-os/bluefin/blob/1a5c8d9e5aaf38c7b10f35d7162f5f36d9f883f7/Justfile#L156-L171).
 

[Accept] [Decline]

Universal Blue Build and Update System

View Suggested Changes

@@ -57,7 +57,7 @@
 
 **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` 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.
+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 `AGENTS.md` in the repository for authoritative CI architecture documentation.
 
 **Branch Management and Promotion Strategy:**
 
@@ -65,7 +65,7 @@
 
 **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`)
-- Creates pull requests directly from `main` → `lts` using `gh pr create --base lts --head main`
+- Creates pull requests directly from `main` → `lts` using `gh pr create --base lts --head main` (no intermediate branches)
 - 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
@@ -99,7 +99,7 @@
 
 ### SBOM Generation
 
-SBOM (Software Bill of Materials) generation occurs only on the `lts` branch when images are published. The system uses Syft to scan container images and generate SBOMs, which are attached as attestations to signed images for supply chain transparency. All SBOM-related steps include `continue-on-error: true` to ensure that SBOM failures (such as Sigstore/Rekor service outages) never block image publishing.
+SBOM (Software Bill of Materials) generation occurs only on the `lts` branch when images are published. The system uses Syft to scan container images and generate SBOMs, which are attached as attestations to signed images for supply chain transparency.
 
 **SBOM generation behavior:**
 
@@ -109,7 +109,7 @@
 - ❌ Skipped on pull requests to any branch
 - ❌ Skipped on validation builds (push events to `lts` branch that don't publish)
 
-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.
+SBOM behavior is controlled entirely by step-level conditions (`if: ${{ github.ref == 'refs/heads/lts' && inputs.publish }}`) checking the branch reference and publish status, not by input parameters. The workflow defaults `publish` to `false` for safety—callers must explicitly opt in to publishing. All SBOM-related steps include `continue-on-error: true` to ensure that SBOM failures (such as Sigstore/Rekor service outages) never block image 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.
 
@@ -158,11 +158,11 @@
 - Pull requests to `main` branch validate (build without publishing)
 - The publish condition enforces this behavior: `(github.event_name == 'workflow_dispatch' && (github.ref == 'refs/heads/lts' || github.ref == 'refs/heads/main')) || (github.event_name == 'push' && github.ref == 'refs/heads/main')`
 
-> **Bug Fix (PR #1154 & #1157)**: Critical bugs were fixed in the manifest generation and publishing steps:
+> **Bug Fix (PR #1154 & #1157 & #1160)**: Critical bugs were fixed in the manifest generation and publishing steps:
 > 
 > - **Manifest Step (PR #1154)**: The manifest generation step had inconsistent conditional logic compared to the build step. The build step correctly added `-testing` suffix for all non-production branches, but the manifest generation step only added it for pull requests and merge groups—omitting pushes to `main`. This caused `main` branch merges to accidentally push images to the production `:lts` tag instead of `:lts-testing`. PR #1154 resolved this by aligning manifest step logic with build step logic: both now use `if [ "${REF_NAME}" != "${PRODUCTION_BRANCH}" ]`, ensuring consistent tagging behavior.
 > 
-> - **Push Manifest and Sign Steps (PR #1157)**: Both the "Push Manifest" and "sign" steps used `github.event_name != 'pull_request'` conditionals, which caused them to fire even when `inputs.publish` was `false`. This resulted in "image not known" errors during validation builds on `lts` push events. PR #1157 fixed this by gating both steps on `inputs.publish` instead, ensuring they only execute when publishing is intended. The same fix was applied to signing steps in the `build_push` job to prevent signing non-existent images.
+> - **Push Manifest and Sign Steps (PR #1157 & #1160)**: Both the "Push Manifest" and "sign" steps used `github.event_name != 'pull_request'` conditionals, which caused them to fire even when `inputs.publish` was `false`. This resulted in "image not known" errors during validation builds on `lts` push events. PR #1157 and #1160 fixed this by gating both the "Push Manifest" step, the separate "sign" job, and individual signing steps on `inputs.publish`, ensuring they only execute when publishing is intended.
 
 Changes on the main branch typically go live within 30 minutes to 2 hours. Production releases on the lts branch occur weekly via the automated dispatcher or on-demand via manual dispatch.
 
@@ -385,6 +385,7 @@
 
 | File Path | Description | URL |
 |-----------|-------------|-----|
+| `AGENTS.md` | Authoritative CI architecture documentation | [View](https://github.com/ublue-os/bluefin/blob/main/AGENTS.md) |
 | `.github/workflows/scheduled-lts-release.yml` | Dispatcher workflow for weekly LTS releases | [View](https://github.com/ublue-os/bluefin/blob/main/.github/workflows/scheduled-lts-release.yml) |
 | `.github/workflows/promote-to-lts.yml` | Manual promotion workflow from main to lts | [View](https://github.com/ublue-os/bluefin/blob/main/.github/workflows/promote-to-lts.yml) |
 | `.github/renovate.json5` | Renovate configuration with branch restrictions | [View](https://github.com/ublue-os/bluefin/blob/main/.github/renovate.json5) |
@@ -401,6 +402,7 @@
 | `.github/workflows/build-latest.yml` | Latest stream build configuration | [View](https://github.com/ublue-os/main/blob/5ef6bb2adf95dd36b4d428e643a88ad510b7b988/.github/workflows/build-latest.yml) |
 | `.github/workflows/build-image-gts.yml` | GTS stream build configuration | [View](https://github.com/ublue-os/bluefin/blob/3f18fcfb4b16d8ae005cef071395c0132672ebce/.github/workflows/build-image-gts.yml) |
 | `.github/workflows/build-image-stable.yml` | Stable stream build configuration | [View](https://github.com/ublue-os/bluefin/blob/3f18fcfb4b16d8ae005cef071395c0132672ebce/.github/workflows/build-image-stable.yml) |
+| `.github/workflows/generate-release.yml` | Release generation triggered on workflow_dispatch builds | [View](https://github.com/ublue-os/bluefin/blob/main/.github/workflows/generate-release.yml) |
 
 ### Key Repositories
 

[Accept] [Decline]

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

^{How did I do? Any feedback?}