Instead of announcing ahead of time how many tests will be run, just
log 1..32 or similar at the end, from the done_testing function.
This should go some way towards preventing unnecessary cherry-pick
conflicts when tests added to this script get backported.
Resolves: https://github.com/flatpak/flatpak/issues/6793
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is the equivalent of the function of the same name in Perl's
Test::More. If we already emitted a test plan, it asserts that the
number of tests we planned to do equals the number we actually did.
If not, it assumes that however many tests we have done, that's all of
the tests that we intend to do - this can be useful in test scripts
that routinely increase in length, like test-run.sh which is becoming
rather long (and has frequent conflicts for the "plan" line when we
cherry-pick new test coverage to older branches).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is approximately the equivalent of 'plan' in Perl Test::More:
it announces how many tests we plan to run.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This adds new FlatpakTransaction API, and a new top level CLI command to
preinstall flatpaks, that is to install flatpaks that are considered
part of the operating system.
A new drop-in directory /etc/flatpak/preinstall.d/ allows configuring
what apps should be preinstalled, and a new flatpak preinstall command
installs and removes apps based on the current configuration.
A drop-in loupe.preinstall file can look something like this:
[Flatpak Preinstall org.gnome.Loupe]
Branch=stable
IsRuntime=false
The corresponding API is flatpak_transaction_add_sync_preinstalled()
which can be implemented by GUI clients to drive the actual installs
on system startup.
Resolves: https://github.com/flatpak/flatpak/issues/5579
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
The output might be written to the pipe by `flatpak --help` and/or read
from the pipe by `head -2` in more than one batch. If `head -2` reads
the first two lines before `flatpak --help` has written everything, it
will exit, causing the pipe to have no process at the read end. This
results in `flatpak --help` being killed by `SIGPIPE` next time it tries
to write to the pipe, because it has not opted out of this behaviour
(as shell tools usually shouldn't).
We're running under `set -o pipefail`, so this causes a nonzero exit
status that makes the test fail. Worse, this failure is intermittent,
because `head -2` *usually* doesn't exit until `flatpak --help` has
already written out everything it is going to write - it depends on
the precise behaviour of read(), write() and kernel scheduling.
We know that `flatpak --help` output is not *that* long, so it's OK
for `flatpak --help` not to be terminated early: we can send it all
into an intermediate file, and then run `head` on the file.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is the environment needed to use flatpaks; a following commit will
hook this up to the systemd environment generator.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Rename permission-list and document-list to
permissions and documents, for consistency with
how we handle remotes. The old command names
are kept as hidden aliases.
Closes: #2131Closes: #2366
Approved by: mwleeds
One of the variations tested on Debian's reproducible build
infrastructure is that the second build is done in a French locale.
This test fails there, because it doesn't see "Usage:" in the help.
Signed-off-by: Simon McVittie <smcv@debian.org>
Simon McVittie