The snap workflows can't currently run for PRs created from forks, since the repo's policy is not to allow forks to access any secrets.
The caveat here is that, for PRs, we won't be able to assert if the snap can build for architectures other than the GH's runner.arch. I don't think there's a way around this since the multi-arch build relies on LP, and for that we always need credentials.
To be fair, the same would happen if we still had the Snap store connected to this repo, since the multi-arch builds would also only happen on push to master.
In this PR
The snap.yaml workflow builds the snap with basis on the type of event triggering the workflow:
for PRs, the snap build will only take place for amd64, and use snapcraft pack
for every other event (push and release), the snap build will rely on LP (i.e. snapcraft remote-build)
The snap workflows can't currently run for PRs created from forks, since the repo's policy is not to allow forks to access any secrets.
The caveat here is that, for PRs, we won't be able to assert if the snap can build for architectures other than the GH's
runner.arch
. I don't think there's a way around this since the multi-arch build relies on LP, and for that we always need credentials.To be fair, the same would happen if we still had the Snap store connected to this repo, since the multi-arch builds would also only happen on
push
tomaster
.In this PR
The snap.yaml workflow builds the snap with basis on the type of event triggering the workflow:
amd64
, and usesnapcraft pack
push
andrelease
), the snap build will rely on LP (i.e.snapcraft remote-build
)