A commonly used CI workflow [1] is to chain the following steps:
> flatpak-builder --stop-at=<module>
> flatpak build <commands to build module from local checkout>
> flatpak-builder --finish-only
Unfortunately, the last step always purge all the compilation cache
created by the first one. All build steps are marked unused by default
and since they are skipped due to the option --finish-only, all of them
are always pruned by the gc function.
As a result, flatpak-builder cache becomes useless, a full compilation
is always performed.
Improve this by not cleaning unused stages when no compilation is done
by flatpak-builder (i.e: when flatpak-builder is used with --export-only
or --finish-only option).
[1]: https://gitlab.gnome.org/GNOME/Initiatives/wikis/DevOps-with-Flatpak
This means we can build without xattrs
This only affects new caches, old ones will work fine with the
bare-user repo though.
Closes: #80
Approved by: alexlarsson
This stores the cache in the canonical format (i.e. uid/gid 0 and no
weird permissions). This has two advantages, first of all it matches
what flatpak build-export will produce, so diff:ing with the final
result will make things easier to read, shared repos will be smaller,
etc. Secondly, it will allow us to switch to bare-user-only mode which
means we don't need/use xattrs for the build filesystem.
Note: We bump the cache format as the cache will change affecting
e.g. ostree diff between different cachepoints, so this will rebuild
everything once.
Closes: #80
Approved by: alexlarsson
We used to have a hack where we used a bare-user cache
and a non-user-mode checkout to force a copy. But these
days ostree has a force_copy mode, so lets just use that.
This doesn't really change anything for now, but it will allow
us later to canonicalize the uid/gid in the cache without then
failing to check out due to permission issues.
Closes: #80
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
Alexander Larsson