Closed jinnatar closed 1 month ago
Ah, nope. It would use the secrets of the parent repo, and failed because they're not set. So to go beyond here, we need the kanidm_ppa key material on this repo's secrets.
Ok, they're in there - the signing key's gzip'd then base64'd, which ended up being the way to get it working in kanidm_ppa
- see https://github.com/kanidm/kanidm_ppa/blob/main/.github/workflows/update_ppa.yml for how it's used... though I used your secret names above 'cause I'm easily distracted.
In my testing so far just plain ascii armor has been enough, no need to get rid of linebreaks. Since it's a ready made action, not sure if injecting undoing of those steps is feasible.
Latest snapshot build was a success, albeit without signing on purpose: https://github.com/kanidm/kanidm_ppa_automation/actions/runs/11277242532/artifacts/2041132718 .. vs. signed with my fork demo key on that side: https://github.com/jinnatar/kanidm_ppa_automation/actions/runs/11277241665/artifacts/2041127593
diff <(tree pr/dists) <(tree fork/dists)
1c1
< pr/dists
---
> fork/dists
4a5
> │ ├── InRelease
18a20
> │ ├── Release.gpg
34a37
> │ ├── InRelease
35a39
> │ ├── Release.gpg
51a56
> ├── InRelease
65a71
> ├── Release.gpg
80c86
< 19 directories, 59 files
---
> 19 directories, 65 files
Other things:
For this to work, repo secrets must contain:
GPG_PRIVATE_KEY
: An ASCII armored GPG private key.PASSPHRASE
: The passphrase for said key.I assume the PR will use my demo key from the fork.