Skip to content

Release workflow has no validation path short of pushing a tag #79

Description

@yashranaway

.github/workflows/release.yml only triggers on push: tags: ["v*"]. Nothing else runs it, so any change to it — or to an action it depends on — is unverified until a real release is cut, and a failure there is public and hard to undo.

This is not hypothetical. Dependabot proposed bumping actions/download-artifact 4→8 (#57) and softprops/action-gh-release 2→3 (#58). Both showed green CI, and that green means nothing: neither action appears in ci.yml. Merging on that signal would have been merging on a check that never exercised the code. Both are being held for this reason. The v1.0.0 release run also failed historically, with v1.0.1 and v1.0.2 cut immediately after to fix CI issues — evidence that this path breaks in exactly the way an untested workflow does.

Options

  1. workflow_dispatch on release.yml with a dry_run input that builds and packages every artifact but skips the publish job. Cheapest, and makes the release path runnable on demand.
  2. A packaging job in ci.yml that runs build.sh/build-linux.sh and asserts the artifacts exist with the right names, on PRs that touch build scripts, Dockerfile.linux, or release.yml (path filter). Catches breakage at PR time.
  3. Pre-release rehearsal on a v*-rc* tag pattern publishing to a draft release.

Option 1 plus a path-filtered version of option 2 is probably the right combination.

Definition of done

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Status
    Done

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions