ci: add snap build and publish pipeline#1494
Conversation
Introduce a complete snap build, test, and publish workflow: - install-cached-snap action: reusable composite action that downloads and installs snaps with GitHub Actions caching support. Handles snap components, classic mode, and cache miss cleanup with full artifact discovery. - snapcraft-pack.yml: builds the snap for amd64 and arm64 architectures. Installs snapd, core22, core24, LXD, and snapcraft with configurable channels and optional caching. Captures snap and component filenames as workflow outputs and uploads them as build artifacts. - spread.yml: runs integration tests using the spread test framework with image-garden for VM-based testing. Supports configurable spread systems, architectures, variants, and live mode. Caches pristine and prepared VM images separately. - tasteful-crafts.yml: master reusable workflow that orchestrates the full pipeline — discovers spread systems via spread.yaml, packs for both amd64 and arm64, runs spread smoke tests on the amd64 build, then uploads all artifacts to the Snap Store. Supports skip-spread-tests for manual approval gates and environment-based channel targeting. - snapcraft-build-test-publish.yml: entry-point workflow triggered on push to main, tag, or manual dispatch. Routes tag builds to latest/candidate and branch builds to latest/edge (or $SNAPCRAFT_CHANNEL). Includes workflow_dispatch input to skip spread tests and publish directly. - snapcraft-promote.yml: manual workflow for promoting snap revisions from one Snap Store channel to another (e.g., candidate to stable). Requires a GitHub environment matching the target channel name with SNAPCRAFT_STORE_CREDENTIALS. Depending on the workflow trigger (push or tag), one of two jobs runs: one for uploading and releasing untagged builds to latest/edge, and another for uploading tagged versions to latest/candidate. Environment setup and Snap Store credentials are documented in deploy/snap/PUBLISHING.md. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
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. |
| pull_request: | ||
| branches: [ main ] |
There was a problem hiding this comment.
Reminder to remove, we don't want this building on PRs.
| branches: [ main, snap/build-pipeline ] | ||
| tags: [ 'v*' ] |
There was a problem hiding this comment.
Starting a 🧵 for
main question is exactly when to trigger the new logic
Can we follow our current release strategy? Currently on push to main we publish a dev build, and on every vX.Y.Z tag we publish a tagged release.
We don't currently have the concept of a release candidate or promotion. Eventually we might want to add this, but right now we're optimizing for a fast release cadence.
It might be easier to keep snaps aligned with the current pattern, and then evolve our release strategy as a single unit from there.
| @@ -0,0 +1,298 @@ | |||
| # SPDX-FileCopyrightText: Copyright (c) 2025-2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. | |||
| # SPDX-License-Identifier: Apache-2.0 | |||
| name: tasteful crafts | |||
There was a problem hiding this comment.
what is tasteful crafts? can we rename this to something more descriptive related to what is being done?
|
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. |
2 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