Closed wjt closed 8 months ago
I really think this is the wrong approach and the container should just be run with a UID matching the owner of the checkout… but perhaps that is one for another day.
I realised I didn't actually test this branch.
I tested this and it seems to find the root of the git checkout correctly!
(Initially I just reverted 7d6496d2b71f1b970cee3a5574d23af1155ca6ce but I think this is better.)
Modern git refuses to operate against a repo owned by a different user. This happens in a GitHub action because the 'checkout' action checks out the repo as UID 1001 but this app's container image runs as UID 0.
We attempt to detect this "dubious ownership" situation and mark the repo as safe, subverting the check. Since 7d6496d2b71f1b970cee3a5574d23af1155ca6ce we attempt to handle the case where the manifest is not in the root of the git checkout. However, using
git rev-parse --show-toplevel
in this situation does not work because git considers the repo to have dubious ownership (which is what we are trying to solve).Instead, walk the ancestors of the manifest path, looking for a
.git
file. (It need not be a directory: working copies created withgit worktree
have a text file at.git
, whose contents describe where the main checkout is.)Kludgy but it just might work.
Fixes https://github.com/flathub/flatpak-external-data-checker/issues/395