[GitHub Tools] Add a unified release workflow with semver tagging and GitHub Releases

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Component/s: GitHub Tools
    • None
    • Not Needed

      Summary

      Today, releasing this repo only supports moving a floating major-version tag (e.g. v3) to the tip of main. There is no way to cut an immutable, versioned release with generated release notes, and no dry-run option to preview a release before it happens. Semgrep also flags this floating-tag pattern with the github-actions-mutable-action-tag rule, since a mutable tag can be silently repointed after consumers have already pinned to it. We want a single workflow that bumps the version (patch/minor/major), creates a signed release tag, and publishes a GitHub Release, replacing the current ad hoc tag-update process.

      Motivation

      Who is the affected end user?

      Maintainers of this repo who cut releases, and the MongoDB driver teams that consume its actions.

      How does this affect the end user?

      Maintainers have no supported way to produce a versioned, documented release. Consumers can only pin to a floating major tag, which moves over time and isn't reproducible or auditable.

      How likely is it that this problem or use case will occur?

      Main path; every release of this repo goes through this process.

      If the problem does occur, what are the consequences and how severe are they?

      Releases stay undocumented and unreproducible; consumers can't confirm which commit a given version actually pointed to at release time. The floating tag itself is a standing static-analysis finding (semgrep: github-actions-mutable-action-tag), since anyone able to move it can retarget what consumers pinned to without their knowledge; a supply-chain integrity concern.

      Is this issue urgent?

      Not blocking, but wanted before the next major version bump, since that is when floating tags stop being produced.

      Is this ticket required by a downstream team?

      No specific downstream ask; benefits all driver teams that consume this repo indirectly.

      Is this ticket only for tests?

      No, functional change.

      Acceptance Criteria

      • A workflow accepts a version-bump type (patch/minor/major) and a dry-run option.
        It computes the next version from existing tags, creates a signed release tag, and publishes a GitHub Release with generated notes.
      • Dry-run mode previews the release without pushing or publishing anything.
      • The existing floating major-version tag stays in sync while that major version is still supported, with a clear signal once it no longer applies.
      • The prior ad hoc tag-update process is retired so there is a single, supported way to cut a release.

            Assignee:
            Steve Silvester
            Reporter:
            Steve Silvester
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: