cli/docs/release_process.md

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. Tag the latest commit on main (such as git tag v1.22.1).
3. Push with these commands: git push origin main and git push origin v1.22.1
4. Manually add attribution to the changelog by editing the release entry on the releases page.

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 in 15.9. 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.23.0.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.23.0/cli-v1.23.0.tar.gz" \
   --sha256=4fe9dcecc5e601a849454a3608b47d709b11e2df81527f666b169e0dd362d7df
   

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

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

The SHA is not computed during build, and must be computed manually as part of your update. For more information, see Release CI: compute SHA256 of the Windows installer).

Prerequisites:

• You must have a GitHub account.
• You must have signed Microsoft's Contributor License Agreement (CLA).
• You have read the GitLab policy for Contributing to a third-party project on behalf of GitLab. (The confidential, internal legal issue is also available.)

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. This is how you 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.