Publishing

[dex4er]

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 draft release, then each worker adds a binary artifact to
it and after they are all finished correctly, the release is published and
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 snap recipe lives in our
freelensapp/freelens-snap
repository. Version bumps are handled 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.

The snap is built and published directly from that repository by GitHub
Actions.

• The
  Publish
  workflow (weekly schedule on Mondays at 04:00 UTC, or manual
  workflow_dispatch) builds amd64 and arm64 with snapcore/action-build,
  publishes to the candidate channel with snapcore/action-publish, then a
  follow-up job automatically promotes candidate → stable with
  snapcraft promote.
• The
  Publish nightly builds
  workflow (daily at 04:00 UTC) builds from the nightly-builds branch against
  the latest
  freelens-nightly-builds
  release and publishes to the edge channel.

Builds and channel status are visible on the
builds and
releases pages.

Secrets and variables

publishing environment:

• SNAPCRAFT_TOKEN: Snapcraft store credentials, used as SNAPCRAFT_STORE_CREDENTIALS by action-publish and snapcraft promote.
• GH_TOKEN: PAT used by the nightly workflow to read the latest freelens-nightly-builds release.

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.