We tried this in bug 1795042 but ran into issues (bug 1795732).

The task fails with:

+ ostree commit --repo=repo --canonical-permissions --branch=screenshots/x86_64 build/screenshots
error: Cannot write to repository: Operation not permitted

In https://treeherder.mozilla.org/jobs?repo=try&revision=5047db29246d23ba84b5bc43787f8ccc673d055d&selectedTaskRun=ZEGWeKX5S-SWNNfc3EfjPg.0 I'm strace-ing the ostree call:

+ strace -f ostree commit --repo=repo --canonical-permissions --branch=screenshots/x86_64 build/screenshots
execve("/usr/sbin/ostree", ["ostree", "commit", "--repo=repo", "--canonical-permissions", "--branch=screenshots/x86_64", "build/screenshots"], 0x7ffc81166b20 /* 28 vars */) = 0
brk(NULL)                               = 0x556457332000
[...]
openat(AT_FDCWD, "/home/worker/workspace/repo", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_EMPTY_PATH) = 0
openat(3, "objects", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
faccessat2(4, ".", W_OK, 0)             = -1 EPERM (Operation not permitted)

https://github.com/GoogleContainerTools/kaniko/issues/1573 and https://github.com/moby/moby/issues/41704 look relevant, in which some docker / libseccomp versions don't handle the faccessat2 syscall properly.

I don't remember exactly what we did, but this ended up being fixed.

Nvm, it's actually still busted. Though apparently only fails on level 3 and not level 1.

Interesting that this passes on the L1 image. Either we are mocking out the bits that would have called this in the L1 task, or perhaps this will be resolved when we are able to re-generate the L3 images again.

Edit: Looks like the latter afaict: https://firefox-ci-tc.services.mozilla.com/tasks/GG6Ty8D1TISuR23MxvRNvw/runs/0/logs/public/logs/live.log#L265

Oh and looks like this task used to fail on try, at least as recently as Julien's try push from comment 1. So that supports the theory that an L3 image update might fix this (since L1 images have been updated since then but L3 images have not).

The L3 image was updated, though I'm not 100% sure how to test it other than land it and wait for the next beta release again...

Should we try this early in the 110 beta cycle?

Wfm! Thanks for remembering about this.

Comment on attachment 9312412 [details]
Bug 1795884 - migrate release-flatpak-repackage task to gcp. r?ahal

Beta/Release Uplift Approval Request

• User impact if declined: none
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The risk is a missing flatpak build for one beta if it doesn't work.
  The reason I'm asking for uplift is this task only runs on beta and release so we can't really test any other way. Previous attempt bounced even though this appeared to work on try because of differences between the level 1 vs level 3 workers; we believe these have been resolved now.
• String changes made/needed:
• Is Android affected?: No

https://hg.mozilla.org/mozilla-central/rev/b785f8207f5c

Comment on attachment 9312412 [details]
Bug 1795884 - migrate release-flatpak-repackage task to gcp. r?ahal

Approved for 110 beta 3, thanks

https://hg.mozilla.org/releases/mozilla-beta/rev/1e96af070ae2