ci: add snap build and publish pipeline#1494
Conversation
zyga
requested review from
a team,
derekwaynecarr,
maxamillion and
mrunalp
as code owners
|
Having seen what CI does in this PR I think the main question is exactly when to trigger the new logic. It surely should happen at some time, but given the special arrangement in this repository, I suspect you may want to think where exactly it fits. |
|
I left some initial feedback, but I want to propose an alternative approach first. It seems like we're introducing new patterns for releasing artifacts (eg release candidates) and testing artifacts (eg spread). I want to make sure we don't fragment our codebase with different tools and patterns. To that end, I would propose we start in this PR with something smaller scoped, and then step back and work on a larger release and testing strategy. This probably warrants an RFC and review w/ the broader community. For this PR, let's start by adding snap builds to our existing release pipeline (see deb-package.yml and rpm-package.yml as examples) via a Instead of introducing spread, lets just add a test to the current release canary in Once that's in place, lets set up some time to review where we're at and come up with a more comprehensive plan as an RFC or series of Github issues. Spread looks promising and I wonder if we can use it for other release artifacts. |
|
I'll send updates to this on Monday. Thank you for the review |
|
@drew Please have a look at this much simplified version. |
|
/ok to test 9e53811 |
olivercalder
left a comment
olivercalder
left a comment
There was a problem hiding this comment.
This looks good to me, FWIW. Two small questions.
| - name: Install core24 | ||
| run: | | ||
| set -euo pipefail | ||
| sudo snap install core24 |
There was a problem hiding this comment.
Why install core24 manually? Won't this get pulled in by default as the base for lxd and snapcraft?
There was a problem hiding this comment.
Earlier versions had this cached in github cache, I guess it's somewhat pointless now yes.
| SNAP_NAME="${SNAP_FILE%.snap}" | ||
| SNAP_NAME="${SNAP_NAME%%_*}" |
There was a problem hiding this comment.
Nitpick: personally I'd prefer something clearer rather than these bash-isms, though not sure if there's precedent for using coreutils like cut. All we really need in the end is splitting on first _, right?
olivercalder
left a comment
olivercalder
left a comment
There was a problem hiding this comment.
Looking back at the snap-package inputs, another question
| upload-channel: | ||
| required: true | ||
| type: string | ||
| description: "Snap Store channel to upload to (e.g., latest/edge, latest/candidate, latest/stable)" | ||
| github-environment: | ||
| required: true | ||
| type: string | ||
| description: "GitHub deployment environment for approval gates (e.g., latest/edge, latest/stable)" |
There was a problem hiding this comment.
Ah one more thing: above these always use the same channel. Under what circumstances would these channels differ? And I'm not familiar with "GitHub deployment environment", is this a thing with established channels which just happen to match those used for snaps, or is this an arbitrary value which we're making a simplified subset of the snap channels? That is, is there a fixed set of values which are expected and handled in a particular way?
There was a problem hiding this comment.
It really depends on how it is organized. You could arguably use the same thing for both.
There was a problem hiding this comment.
It just seems like having different values would potentially mask if there's a mismatch. If all you see is the github-environment value but there's a different upload-channel value, maybe it would be easier to make a mistake when approving.
|
|
||
| - name: Upload snap to Snap Store | ||
| environment: | ||
| name: ${{ inputs.github-environment }} |
There was a problem hiding this comment.
What effect does setting this have? If it's just for publishing approval, is there a fixed set of expected values? And is there a way to differentiate between different upload-channel values (e.g. latest/candidate and latest/stable) if they happen to use the same github-environment value?
There was a problem hiding this comment.
this controls both approval and access to secrets
There was a problem hiding this comment.
Ah, so if access to secrets varies, then it sounds like there is a fixed set of potential values, with different secrets handling for each?
I'm trying to understand whether there's need for separate values. If there's a fixed set which affects secrets, and it differs from potential store channels, then I think it makes sense to have separate values.
There was a problem hiding this comment.
It depends on how you set up your secrets.
|
@drew I've updated the PR with some changes and simplifications. I'm still iterating locally and I have not tested this version end to end yet. |
Add a snap-package.yml reusable workflow for building snaps on amd64 and arm64, and wire it into release-dev.yml and release-tag.yml. The release canary ubuntu-snap job downloads the snap from release-dev artifacts using actions/download-artifact with run-id instead of fetching it via an unauthenticated GitHub API call. This is consistent with how all other package types (deb, rpm, etc.) are consumed across the tree and avoids rate-limiting issues. The snap job only runs on workflow_run triggers (not dispatch) since artifacts are only available from a prior release-dev run. The docker snap dependency (sudo snap install docker) is required before installing the openshell snap which plugs the docker interface. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
zyga
force-pushed
the
snap/build-pipeline
branch
2 times, most recently
from
126608d to
525e41d
Compare
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
3 participants
Summary
Add GitHub snap build, test (when spread support is merged) and publishing pipeline.
Related Issue
N/A
Changes
This branch is an adaptation of my https://github.com/zyga/hello-rust project that was developed for allowing GitHub based projects to use the snap store without having to grant individual developers collaborator status on the snap.
The main entrypoing is
Testing
mise run pre-commitpassesChecklist