- 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.
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.
