Skip to content

Files

Latest commit

36b251f · Jun 5, 2025

History

History
85 lines (53 loc) · 3.8 KB
·

RELEASING.md

File metadata and controls

85 lines (53 loc) · 3.8 KB
·

Releasing

Daily snapshots

We generate a snapshot build via the goreleaser_snaphot and go_msi_snapshot evergreen tasks, these tasks run on master and can be patched at any time.

  • goreleaser_snaphot: used with goreleaser to generate linux, mac and windows builds, the mac build will also be signed and notarized
  • go_msi_snapshot: used with go-msi to generate a Windows msi installer

Stable release

Stable releases are now managed by internal tooling (PCT)

Package Managers

Package Managers are published after a stable release happens, in which binaries are stored in GitHub releases and also uploaded to our download center (https://www.mongodb.com/try/download/atlascli.

Docker Image

Our Docker image release for AtlasCLI is managed through the docker-release.yml workflow. This process is automated to run daily, ensuring the latest versions of the image dependencies are updated. github_action

Release Steps

Step 1: SBOM Generation

An SBOM Lite is generated using the maintained purls.txt file and uploaded to Kundukto. The SBOM Lite is also included as an artifact in the public repository release.

Step 2: Build and Stage

The AtlasCLI Docker image is built from the (Dockerfile) and tagged in three ways: latest, vX.Y.Z (reflecting the latest release version, e.g., v1.22.0), and vX.Y.Z-date (adding the current date, e.g., v1.22.0-2024-01-01). This image is initially published to a staging registry to prepare for signature in the next step.

Step 3: Sign and Publish

We retrieve the image from the staging registry and use its OCI index to identify the three relevant digests. Each digest is signed using cosign, and the corresponding signature is stored in the MongoDB cosign repository. The signed image is then pushed to the public repository.

Step 4: Verify Signature

The Docker image's signature is verified to confirm its authenticity.

Step 5: Trace Artifacts

Papertrail runs to record detailed metadata about the release for improved traceability and accountability.

Step 6: Compliance Reporting

A GitHub workflow generates a compliance report after the release and opens a PR with the report.

Manual Release (Deprecated)

Important

This action will only publish a release for maintainers of the cli

To manually generate a new stable release, you can run:

./scripts/release.sh atlascli/v1.0.0

Important

Please use the atlascli/vX.Y.Z format for the version to release

This will do the following things:

  1. Tag a new version, ie: git tag -a -s atlascli/v1.0.0 -m "atlascli/v1.0.0"
  2. Publish the new tag, ie: git push origin atlascli/v1.0.0
  3. The evergreen release task will run after a tag event from master.
  4. If everything goes smoothly, the release will be published in the release page, and download center.