Skip to content

release_process.md

Latest commit

 

History

History
100 lines (65 loc) · 4.65 KB

release_process.md

File metadata and controls

100 lines (65 loc) · 4.65 KB

Release process

To release a new version of the CLI, you must:

  1. Do a quick test of the CLI in your local development. At this stage, you are only verifying there is no complete failure of the CLI.

  2. To preview which commits will be included in a release, run this command:

    git log --oneline --invert-grep --grep="Merge branch" --invert-grep --grep="chore" $(git describe --tags --abbrev=0)..main | sort -k2

If those changes are appropriate to be released, proceed with the process:

  1. Tag the latest commit on main (such as git tag v1.74.1).
  2. Push with these commands: git push origin main and git push origin v1.74.1

Notifying maintainers

If the release is time-sensitive, such as for a security release, consider emailing the maintainers of the community-maintained channels. Contacts for the different maintainers are available in CLI 1Password Vault in the Maintainers of Community packages note.

Access to distribution channels

Homebrew

Homebrew releases were automated by the CI build. These manual instructions are provided if the automation fails.

Prerequisites:

  • An account on GitHub. (Any account is fine.)

To manually update the version available through Homebrew:

  1. Generate a new token with the repo, workflow, and gist scopes using this link. If you have an existing token with the correct scope, you can use it instead.

  2. On the Releases page for this project, identify the release version you want to publish.

  3. In the Assets area for the release, download the packaged source code (Source code (tar.gz)) for this release.

  4. To compute the SHA256 checksum, run sha256sum cli-v1.74.1.tar.gz.

  5. Create a pull request with the update with this command, modifying the source code URL and SHA as needed:

    brew bump-formula-pr --strict glab \
--url="https://gitlab.com/gitlab-org/cli/-/archive/v1.74.1/cli-v1.74.1.tar.gz" \
--sha256=b1b8ed3f4c7d8839b540d8a264b3a3ef670e78ae369ef0c01ef5d5e502714905

  6. When the pull request is merged, the update is complete.

Snapcraft

Snapcraft releases are automated:

  • The latest/edge channel is automatically built on every commit to main.
  • The latest/stable channel is automatically built when a new tag is pushed.

No manual action is required for Snapcraft releases.

Scoop

No manual action required.

The glab project was moved to GitLab in pull request 4168. Scoop uses the autoupdate URL for updating to newer versions.

WinGet

Prerequisites:

To update the WinGet package:

  1. On the Releases page for this project, identify the release version you want to publish.

  2. In the Assets area for the release, identify the Windows installer package (the filename should end in _installer.exe) and download it.

  3. Compute the SHA256 checksum for the file by running sha256sum filename.exe, replacing filename with the name of release installer you downloaded in the previous step. For example:

    $ sha256sum glab_1.23.1_Windows_x86_64_installer.exe

36f9d45f68ea53cbafdbe96ba4206e4412abb4c2b8f00ba667054523bd7cc89e  glab_1.23.1_Windows_x86_64_installer.exe

  4. Copy the SHA from the result.

  5. On GitHub, create a pull request in the microsoft/winget-pkgs project. Use the pull request to update to version 1.23.1 as an example.

Setting up CI/CD for releasing

For automated testing, you need to set up credentials for unit testing.

For releasing, you also need to add a GITLAB_TOKEN_RELEASE. To create this token:

  1. Go to Settings -> Access Tokens
  2. Generate a new project token with api scope and Maintainer role.
  3. Add the new token as GITLAB_TOKEN_RELEASE protected and masked CI/CD variables.