The recent update of one of the `docker/build-push-action` dependency
referenced in the `gha-ubuntu-packaging` dependency now adds the
`.dockerbuild` log files as artifacts which confuses the
`prepare_api_verification` step. This change now limits the artifacts
we pass to the API verification to the keyman package related ones.
Test-bot: skip
This change fixes the fix that #13891 implemented. However that only
used the string `VERSION` instead of the variable... Fixes the package
builds of `stable-18.0` branch.
Fixes: #13891
Test-bot: skip
Previously the builder scripts defined a readonly `VERSION` environment
variable for the Keyman version. That caused problems when another
(external) script tried to define a `VERSION` variable. We encountered
this problem when trying to move the TC build steps of a configuration
into a single script (#13399) when we tried to source `~/.nvm/nvm.sh`.
This change uses a Keyman specific prefix for the version variables and
renames `VERSION` → `KEYMAN_VERSION` etc. Unfortunately these variables
are used in a lot of places, so this turned out to be a bit of a yak
shave.
Test-bot: skip
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
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.
This change splits the package builds into building packages for the
released Ubuntu versions and for the next version. A failure to build
packages for the next version will no longer fail the packaging GHA.
Closes#11143.
(cherry picked from commit 043f2c65f5)
This change splits the package builds into building packages for the
released Ubuntu versions and for the next version. A failure to build
packages for the next version will no longer fail the packaging GHA.
Closes#11143.
With the new download-artifact version when using `merge-multiple:true`
all artifacts end up in the same directory. This change adjusts for that.
Another follow-up of #10577.
We have a C API, but (internal) C++ template instantiations are visible
and so get flagged by `dpkg-gensymbols`. This change ignores the one
use of C++ by marking it optional. This is listed as a usage scenario
in the dpkg-gensymbols man page.
Note this requires a change how we call dpkg-gensymbols: if the `-O`
parameter is specified, the file is not treated as being a template file
(see man deb-src-symbols) and so the tags are not interpreted.
Additionally the file gets overwritten with the non-tag version. So this
change removes the `-O` parameter, and changes the archiving of the
generated file.
