This is somewhat faster than Autotools. We still use Autotools for
the alt, clang and valgrind builds, to make sure we cover both.
As a bonus, the use of undefined behaviour and address sanitizers here
actually works (unlike in Autotools, see #4844) so we're getting test
coverage with detection of common issues like use-after-free.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This avoids a race condition in versions older than 2.60, while still
verifying that we can compile successfully with GLib 2.56.
Not having GLib 2.60 means we can't compile libmalcontent on Ubuntu 18.04,
so move the libmalcontent dependency to the main build job (on Ubuntu
22.04, which is new enough). This also means we don't have to compile
it from source every time.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This adds a separate, more modern CI build running on ubuntu 22.04
using curl, and leaves the old one around building against soup.
In addition, the modern one uses the system bwrap and dbus-proxy so
that we test these configurations too (and because the modern system
has good versions of these).
I also enabled running parallel make check again, hoping that
whatever made this hang is now fixed. We'll see.
This lets us verify that our ability to do releases hasn't regressed.
Run this as part of the "valgrind" build, since we want to enable
gtk-doc for distcheck, and it's this build that already enables gtk-doc.
We don't want to do this in the main Autotools build, since
that enables AddressSanitizer, which often works badly with the
"scanner" tools in gtk-doc and GObject-Introspection - although this
is currently mitigated by --enable-asan not actually working as
intended (see #4844).
Signed-off-by: Simon McVittie <smcv@collabora.com>
For the build that uses --enable-asan, explicitly disable introspection,
since the GObject-Introspection scanner works poorly with libtool
and AddressSanitizer (see #4844); the only reason this worked until
now is that --enable-asan doesn't currently do anything (again,
see #4844).
For the build that runs tests under valgrind, we already can't use
AddressSanitizer, making this a good place to explicitly enable
introspection, so that we have at least one build with it enabled.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We want to have gtk-doc enabled in the build that will run
`make distcheck`, but the clang/CodeQL build seems like a poor fit for
that, since it runs twice (for C and Python) and has extra
instrumentation. Move it to the build where we will run tests under
valgrind, which is already somewhat slow.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We explicitly enable gtk-doc for one of our builds (the one that uses
clang on Ubuntu 18.04). There's no real need to enable it for more than
one build.
Signed-off-by: Simon McVittie <smcv@collabora.com>
libappstream-glib is mostly unmaintained, and libappstream is more
actively developed (and up to date with the AppStream specification).
Port from libappstream-glib to libappstream. Handily, a lot of the APIs
are exactly the same. The main changes are:
* `AsApp` → `AsComponent`
* `AsStore` → `AsMetadata`
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(Mostly done by Philip, then Phaedrus finished this)
For whatever reason parts of mono is installed, but the repo is not
configured so there is a version conflict on update:
libglib2.0-cil is already the newest version (2.12.45-0xamarin19+ubuntu1604b1).
libglib2.0-cil set to manually installed.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libglib2.0-cil-dev : Depends: libglib2.0-cil (= 2.12.10-6) but 2.12.45-0xamarin19+ubuntu1604b1 is to be installed
E: Unable to correct problems, you have held broken packages.
Similar to /tmp, applications might well use /dev/shm as an IPC
rendezvous between instances, which wouldn't have worked without
--device=shm until now.
Because /dev/shm has specific characteristics (in particular it's
meant to always be a tmpfs), we offload the actual storage into a
subdirectory of the real /dev/shm. Because /dev/shm is a shared
directory between all uids, we have to be extra-careful how we
do this, which is why the test coverage here is important.
This is done on an opt-in basis because of its extra complexity.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This avoids having to download `master` and then check out a specific
commit. v2020.8 includes the commit which we were previously building.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
There’s no need to fetch the entire git history for OSTree or malcontent
for each CI job. Do shallow clones and don’t fetch tags. This reduces
the bandwidth requirement for clones in a CI job by roughly a factor of
8.5 (from 19.5MB to 2.3MB)
See https://tecnocode.co.uk/2020/07/09/easily-speed-up-ci-by-reducing-download-size/
This is slightly complicated by the fact that OSTree is currently being
built from a relatively-recent git commit. Once the flatpak CI can
depend on a tagged OSTree release (say, 2020.8),
```
--branch master --shallow-since 2020-10-27
```
can be changed to
```
--branch v2020.8 --depth 1
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This takes a long time, but doesn't have to be mandatory, also we
only run it if the regular make check passes.
Removes some old no-longer needed ci config workaround.
The new test uses ubuntu-20.04 so we get wider distro testing.
