Skip to content

Publishing

Jump to bottom Edit New page
Piotr Roszatycki edited this page Jun 9, 2025 · 2 revisions

Github Releases

New release requires to run npm-version workflow first that creates a new PR for a new version, then it triggers tag after merge.

As all other automated workflows, it uses automated environment.

The release workflow runs on new tag and first creates a hidden pre-release, then each worker adds a binary artifact to it and after they are all finished correctly, the release is marked as the latest.

The signing environment with all secrets used for it works only from v* tags and sign/* branches. The branches might be created for fixing existing releases.

The process might get stuck if notarization or Azure signing fails, then simple retry of the single job can help.

After the release is published, it should be edited to contain only key points rather than full notes of all single updates.

Secrets and variables

automated environment:

  • GH_TOKEN: PAT of freelensbot for creating a release and uploading release artifacts.

signing environment:

  • APPLEID: used for notarization of the macOS files
  • APPLEIDPASS: used for notarization of the macOS files
  • APPLETEAMID: used for notarization of the macOS files
  • AZURE_CERT_PROFILE_NAME: used for Azure signing; not a secret value
  • AZURE_CLIENT_ID: used for Azure signing
  • AZURE_CLIENT_SECRET: used for Azure signing
  • AZURE_CODE_SIGNING_NAME: used for Azure signing; not a secret value
  • AZURE_ENDPOINT: used for Azure signing; not a secret value
  • AZURE_TENANT_ID: used for Azure signing
  • CSC_INSTALLER_KEY_PASSWORD: used for notarization of the macOS installer
  • CSC_INSTALLER_LINK: used for notarization of the macOS installer
  • CSC_KEY_PASSWORD: used for notarization of the macOS files
  • CSC_LINK: used for notarization of the macOS files

APT repository

The same release workflow creates APT repository and uploads APT indexes as part of the GitHub Releases.

The apt-signing environment with all secrets used for it works only from v* tags and apt-sign/* branches. The branches might be created for fixing existing releases.

Secrets and variables

  • GH_TOKEN: PAT of freelensbot for downloading/uploading release artifacts
  • GPG_KEY_ID: full length of the public key ID; not a secret value
  • GPG_PASSPHRASE: GPG private key must have a passphrase and it is used by pinentry wrapper; must be changed if GPG private key has a new passphrase.
  • GPG_PRIVATE_KEY: GPG private key; we use cv25519 algorithm, which is the default kind of keys (ECC); the secret is from the exported private key with ASCII armor, then sent to the public key server network

AUR

The updates are handled in our freelensapp/freelens-aur repository by the Renovate bot.

If the bot does not see the new release yet, it might be triggered from Dependency Dashboard. It should create a new PR for a new version.

PR must be reviewed and then merged manually. It will publish the new version to AUR.

If pkgrel number must be changed, then only freelens-bin/PKGBUILD file should be edited as freelens-bin/.SRCINFO file will be overwritten.

Secrets and variables

  • AUR_EMAIL: Email address for git commits to the AUR repository.
  • AUR_SSH_PRIVATE_KEY: Private SSH key to AUR repository.
  • AUR_USERNAME: User name for git commits to the AUR repository.

Flathub

The updates are handled by the Flathub project, and after a new version is released the PR should appear in flathub/app.freelens.Freelens repository.

PR must be reviewed and then merged manually.

After ~4 hours after merge it should be published.

Homebrew

The updates are handled by the Homebrew project, and after a new version is released the PR should appear in Homebrew/homebrew-cask repository and it should be merged by the Homebrew project after some time.

Homepage

Our Homepage is hosted as GitHub Pages in our freelensapp/freelensapp.github.io repository.

The updates are managed by the Renovate bot.

If the bot does not see the new release yet, it might be triggered from Dependency Dashboard. It should create a new PR for a new version.

PR must be reviewed and then merged manually. It will publish a new version.

NPM packages

The same release workflow publishes NPM packages.

The publishing environment with all secrets used for it works only from v* tags and publish/* branches. The branches might be created for fixing existing releases.

Secrets and variables

  • NPM_TOKEN: Token for NPM packages in @freelensapp namespace in NPM public registry.

Scoop

The updates are handled by the Scoop project, and after a new version is released, the PR should appear in ScoopInstaller/Extras repository and it should be merged by the Scoop project after some time.

Snapcraft

The updates are handled in our freelensapp/freelens-snap repository by the Renovate bot.

If the bot does not see the new release yet, it might be triggered from Dependency Dashboard. It should create a new PR for a new version.

PR must be reviewed and then merged manually.

Snapcraft build service uses a forked repository dex4er/freelens-snap as the source, then the fork must be synced to start the new build visible on builds page.

All automated builds go to the edge channel, then can be promoted to stable manually on releases page.

WinGet

The updates are handled in our freelensapp/winget-pkgs repository forked from the original repo. Our workflows and the configuration are in a separate updates branch.

The updates are triggered by the Renovate bot.

If the bot does not see the new release yet, it might be triggered from Dependency Dashboard. It should create a new PR for a new version.

PR must be reviewed and then merged manually. It will create a new PR to microsoft/winget-pkgs which will be reviewed and merged by Microsoft.

Add a custom footer
Add a custom sidebar

Clone this wiki locally