If fuse is not available (for example, the kernel module is not loaded,
or /dev/fuse is not exposed in a build chroot), the tests will currently
fail. Avoid that by skipping them gracefully.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #73
Approved by: alexlarsson
The function only does I/O, so could fail. Expose failure to the caller
rather than hiding it.
Coverity CID: #208385
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #74
Approved by: alexlarsson
Rather than dropping the error on the floor entirely.
Coverity CID: #208384
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #74
Approved by: alexlarsson
Move the call inside a preprocessor condition so we don’t end up with
two `return` lines.
Coverity CID: #208383
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #74
Approved by: alexlarsson
This fixes build with builddir ≠ srcdir and a non-existent builddir: the
$(builddir)/tests/ directory was not being created by the time the .test
files were being written.
This will be submitted upstream to glib-tap.mk in GLib.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #68
Approved by: alexlarsson
This mirrors the one for flatpak.git. There are bits of the
flatpak-builder code which are P2P-specific and which couldn’t be
enabled before.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #68
Approved by: alexlarsson
Modules that say "run-tests": true, will run tests after installation,
unless disabled by --disable-tests.
The tests run by default are make check or ninja test, however you
can control the make/ninja target with test-rule, or supply a list
of commands with test-commands. There is also a test-args argument
in build-options, which you can use to give e.g. network access.
The tests are run with readonly access to the install directory, so
they cannot affect the build results.
Closes: #65
Approved by: alexlarsson
If we're bundling sources we really need to fetch from them because
we want to bundle shallow clones. However, this doesn't work for older
git versions, so pre-emptively fetch those deeply.
Closes: #62
Approved by: alexlarsson
Fetching from shallow clones was added in 1.9.0, so we do deep
clones of submodule repos before that to ensure submodule update
works.
Closes: #62
Approved by: alexlarsson
Older versions of git default to only tags when you do --tags instead
of tags + all. So, we force everything with --tags *:*.
Closes: #62
Approved by: alexlarsson
When pulling the commit we need to also pull the tags so we have them
locally, and then we need to peel the ref when we commit it so that we
don't try to create a ref pointing to a non-commit (tag) object.
Closes: #62
Approved by: alexlarsson
The git 1.8.3.2 release notes say:
* Cloning with "git clone --depth N" while fetch.fsckobjects (or
transfer.fsckobjects) is set to true did not tell the cut-off
points of the shallow history to the process that validates the
objects and the history received, causing the validation to fail.
So, on versions prior to this, we always disable fsck when you're
pulling shallowly. If you need fsck validation, use a newer git.
It turns out older versions of git cannot properly check out a commit
if the ref that points to it was not a normal one (branch or tag).
So, we work around this case by detecting it add adding a fake
tag. Also, we change the fake ref we use for commit-only references
to be a regular branch and not a special one for the same reason.
This fixes https://github.com/flatpak/flatpak/issues/1133Closes: #52
Approved by: alexlarsson
In this case we will exec rather than fork + exec, so we don't
want to use prctl, as that can cause the app to die if any
*thread* in the parent dies (rather then the whole process).
In particular, this caused issues for gnome-builder starting
a newly built flatpak:ed app.
Closes: #51
Approved by: alexlarsson
Some manifest (cx.ring.RingGnome) had a git commit id that
was only tip of a non-branch ref (refs/changes/51/8051/8), which
was not cloned by a regular clone, so we need to switch to
a clone --mirror.
Closes: #50
Approved by: alexlarsson
Previously we chained all the state via the internal sha256
checksum, extracting periodic checksums. We now reset
the checksum for each state and instead feed it the previous
stage checksum to chain things.
This means we have different cache checksum values, but the same
chaining behaviour. The advantage being that the checksum is
re-startable from any point, if we know the parent checksum.
Closes: #49
Approved by: alexlarsson