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.
When didn't set the correct environment when building Debian packages
with GitHub actions. The version information wasn't included in the
source file but instead was generated at binary package build time,
at which time not all necessary environment variables were available.
This change will create a patch file on-the-fly which gets
included in the source package that contains the correct information.
Fixes#9878.
This change adds additional checks for the symbols file:
- if a line with a method name gets changed, the package version number
in that line also needs to be updated
- for major API changes (methods renamed or removed) the API version
numbers needs to be incremented
- the API version numbers in the .symbols file and in `CORE_API_VERSION.md`
need to match
This enhances the packaging GHA to be able to verify the renamed
core library. Since the GHA packaging build always uses the action
definition from `master` this change has to land before we can
successfully build the PR that does the actual renaming of the core
library and Debian package. Later we can remove the references to
`libkmnkbp0-0` again.
Part of #9733.
Previously GHA builds always used the "local" environment. This
change now detects test builds as well as release builds and properly
sets the environment.
Don't build Ubuntu 22.10 Kinetic with packaging GHA.
Also prepare for Ubuntu 23.10 Mantic - we can't currently
build that because they are trying to get ibus 1.5.29-beta
to work on so there are often new packages. We wait until that
stabilized before we're providing a new patched ibus version
at which point we can enable building for mantic.
See also #9398.
