Skip to content

Stable Release Workflow

stable-releases.yml
in FOGProject/fog-workflows is the pipeline that turns whatever's currently
on dev-branch into a tagged, published stable release. It runs monthly
(11 11 11 * * — the 11th at 11:11 UTC) or on demand via
workflow_dispatch. See Version Sync Automation
for how the version number itself gets computed; this page covers what
happens once a release is actually cut.

The flow

  1. create-release-pull-request reads FOG_VERSION straight out of
    dev-branch's system.class.php and compares it to the tag name of the
    latest published GitHub release. If they match, there's nothing new to
    release — the run stops here (no-release-needed posts a "nothing to
    release" note to Discord and exits). If they differ, it opens a
    dev-branch → stable PR titled Stable Release PR For {version} - {date}.
  2. run-install-tests triggers FOGProject/fogproject-install-validation's
    run_all_distros.yml — the full matrix of supported distros.
  3. check-all-tests-completed-successfully polls that run until it
    reports success or failure, and fails the job if the distro tests
    failed.
  4. On success, merge-after-all-tests-passed merges the PR
    (dev-branch into stable). On failure,
    close-pr-if-tests-fail closes the PR instead and posts a failure
    notice to Discord — nothing gets released.
  5. tag-and-release (only after a successful merge) builds the release:
  6. Generates base notes via GitHub's releases/generate-notes API.
  7. Appends a ## Commits section built from git log, filtering out
    merge commits, prior "Stable Release" PR commits, and
    chore: fix stale FOG_VERSION/FOG_CHANNEL fixup commits (see
    Version Sync Automation) — those stay in
    git history, they're just excluded from the rendered changelog so a
    run of near-identical bot commits doesn't spam the notes.
  8. Appends issues closed since the previous release, and any new/updated
    GitHub security advisories — for the latter, it also PATCHes the
    advisory itself    , appending this release's tag to
    patched_versions.
  9. Publishes the GitHub release (gh release create) tagged and titled
    with the version, marked --latest.
  10. sync-branches opens and merges a stable → dev-branch PR, so the
    release commit (and its tag-adjacent history) flows back into
    dev-branch rather than the two branches silently diverging.
  11. discord-success posts the release announcement with a link to the
    GitHub release notes.

Why it's structured this way

  • Reading the version instead of computing it: this workflow only ever
    reads FOG_VERSION to decide whether there's something new to release —
    it never recomputes it. stable's version is entirely the one already
    computed on dev-branch by the mechanisms in
    Version Sync Automation; this workflow just
    decides when to promote it. That's also why the version-sync daily sweep
    runs at 10:10 UTC, just over an hour before this workflow's 11:11 UTC
    slot — a release day always reads a version that's current.
  • Tests gate the merge, not the version: nothing here is a
    pull_request-triggered CI check. The install-validation suite runs
    after the release PR is opened, and only a passing run causes the merge
    to happen — a failing run closes the PR instead of leaving it open
    indefinitely.
  • The sync-back PR exists so stable and dev-branch never drift apart
    after a release — without it, the release/tag commit created directly on
    stable would only ever exist there.
  • Version Sync Automation — how
    FOG_VERSION/FOG_CHANNEL are kept correct on every branch, including
    dev-branch before this workflow ever reads it.
  • Fog Release — the manual side of a release (kernel,
    init, and iPXE binary updates) that typically happens before this
    workflow is triggered.