Support for Ubuntu 25.04 Plucky ends on 15th January 2026 after which
it is no longer possible to upload and build on Launchpad. This change
removes Plucky.
Fixes: #14955
Cherry-pick-of: #15423
Test-bot: skip
Due to recent changes in NPM package publishing security requirements,
we have to move from TeamCity build to a GitHub Action to publish our
NPM packages, so we can take advantage of trusted publishing. This
change also consolidates and centralizes the npm publishing into
resources/build/ci/npm-publish.sh, which removes a lot of boilerplate
from each of the build.sh scripts, and ensures consistency.
Packages will be `npm pack`ed on PR and test builds, and published in
release builds.
Ref: https://docs.npmjs.com/trusted-publishers
Ref: https://github.blog/changelog/2025-09-29-strengthening-npm-security-important-changes-to-authentication-and-token-management/Fixes: #14963
Test-bot: skip
Build-bot: release:developer
Cherry-pick-of: #15029
So far the GHA was called "Ubuntu packaging" but the status reported as
"Debian packaging" which was confusing. This change now uses "Ubuntu
packaging" in both places.
We still keep the filename `deb-packaging.yml` because we're packaging
the .deb format, and because it's shorter.
Fixes: #13497
- remove useless branch name from name (this is always `master` due to
the way the workflow gets triggered)
- add PR# to step summary so that it's visible on the Summary page
- fix PR check message to say "API verification" instead of "Package build"
The previous wildcard was too broad and matched on `libkeymancore-dev`
which is missing the API version number in the filename. This change
requires a digit after the name.
This change reverts #11659 and moves setting the environment and
restoring the artifacts in the same job as the actual API verification.
It keeps checking out the git files to a separate directory.
In #11571 we tried to fix the failing API verification by moving
setting up the environment and restoring artifacts to the same job
as the api verification itself. However, this doesn't help and the
`artifacts` subdirectory still vanishes, caused by
https://github.com/actions/checkout/issues/1201.
This change reverts the change introduced in #11571 and changes the
git checkout to end in a separate subdirectory.
Reverts: #11571
Previously we had an extra job where we setup the environment and
restored the artifacts. However, the artifacts then were no longer
available in the next job, `api_verification`. Instead of restoring
the artifacts a second time this change squashes the two jobs. This will
hopefully fix the API verification.
This temporary change will always set the result to SUCCESS so as not
to block PRs. Once we get the API verification working we should undo
these changes again.
The previous attempt where we set a environment variable for the
artifacts key resulted in a chicken/egg problem: we needed the environment
variable to be able to restore the cached artifacts, but we needed
the cached artifacts in order to be able to read the variables...
This change now properly uses run_id: in `deb-packaging.yml` we can
directly use `run_id` from the context. In `api-verification.yml` we get
it from the payload context.
Cf https://docs.github.com/en/webhooks/webhook-events-and-payloads#workflow_run
The recent merge from `beta` into `master` introduced a problem when
resolving merge conflicts, resulting in duplicate definition of
`binary_packages_unreleased` which prevents the workflow from loading.
This change rectifies the file.
This change shows failed package builds for the next Ubuntu version
as failed. With the last change it still showed as green in the overview,
despite my experiments. Turns out it depends where you put the
`continue-on-error: true` statement: if it's in the `steps` section
it'll show up green, if you put it in the job's metadata it'll work as
expected and show up as failed.
We want to run the `deb_signing` job after building binary packages for
both released and unreleased Ubuntu versions finished, so we have to
specify those in the `needs` field. But that on its own causes the
signing job to be skipped if the binary package build for the next
Ubuntu version fails. This change adds conditions so that the
`deb_signing` job always runs if source package build and the binary
package build for the released Ubuntu versions succeeds.
This reverts commit 2fe4da7cca.
In my tests in a test repo `continue-on-error` worked as desired but also
seeds the total result as succeeded if the other jobs succeed. It's
possible that we got the behavior we saw because of syntax errors
in our file, so this change tries with the original approach again.
Previously failed package builds for the next Ubuntu release showed up
with a green check mark. This change allows them to fail, but ignores
them for the following steps.
