Closes#14060
Alternative (legacy) approach to 96a65045e9
Flatpak 1.16 will take some time to land on distros so let's use --device=all
which is retrocompatible and recommended by Flathub linter for this use case.
The only problem is that the "sandbox cops" on our Flathub repo will complain
since we are allowing more devices than needed (even MIDI works as side-effect).
Better approach to 89e88cde
So, we will not either compress nor tar the logs in the end.
As per Jehan comments (I think I've seen something on some MR),
we can bypass the GitLab limitations just by cp-ing the logs.
Partially reverts d07aa8f5 and 73040bce
Just some little improvements:
- Removes --keep-build-dirs to ensure we don't pass build files of modules
(we keep using it for babl and gegl to get the meson-log.txt file)
- Changes ORA build file to _build-cached-$RUNNER.tar.zst for more clarity
(and change back to _build-$RUNNER the final dir passed to the next job)
- Move /build check for the deps jobs (gimp job should just extract)
This reverts 1fcdb724 and 8e6da721, which are inoffensive but inconsistent.
They are added while Jehan's final fix did not landed. Back then, we were
experimenting XZ and other things that we don't use in other parts of the .sh.
So, let's go back to just single tar, since logs are not that big after all.
Apparently that is the reason why the Aarch64 jobs are rebuilding
everything, though I'm not sure to understand why (can gimp-flatpak job
grab the deps-flatpak artifacts from the wrong architecture?).
… delete build/ contents.
We were hitting an error on CI:
> ERROR: Uploading artifacts as "archive" to coordinator... 413 Request Entity Too Large […]
Because the .flatpak-builder/ tarball was huge.
After further testing, it turned out that this is a per-file limit,
since simply not compressing the folder and passing it as artifacts
worked, except this time, we were hitting permission issues: artifacts
end up as root on successive jobs, whereas the CI job runs unprivileged
as a "build" user, which doesn't fly with flatpak-builder still needing
to work and touch previous files.
So I'm doing some in-between by compressing sub-folders (the real
advantage is not the compression part, but the archiving in tar, which
preserves ownership and permissions).
Note that while this kinda partly worked, .flatpak-builder/build/ was
still huge, even when compressing .flatpak-builder/build/* contents in
further individual archives. So I just simply drop this data as it's not
needed at all for flatpak-builder caching (cache/ subfolder is).
See also discussions in #2404.
tar doesn't compress on its own, it's just a container format. It
doesn't look like these 2 files are actually used otherwise, apart from
being log artifacts (at least I couldn't find any script decompressing
these).
This is an attempt to reduce size of artifacts on deps-flatpak because
CI complains with a "Request Entity Too Large" error.
This reverts commit fdb4111e3f.
I did not reverted before because seemed that GNOME guys bumped the
GitLab log limit but we just confirmed that it is still there.
See: Infrastructure/gimp-web-devel@7be7fbe0
In short, such information is not needed to making/building the
packages, just to submitt/release them, which is maintainer-thing.
But let's keep at least a reference so making them easier to find.
