NVIDIA / NVIDIA/OpenShell

feat(ci): add PR-safe snap package validation

Open
#1,860 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

roadmap
Dominant language
Rust
Stars
8.7k
Forks
1.3k
Avg merge
2d 11h
Merged PRs (30d)
253

Description

Problem Statement

snap-package.yml is only called from the release workflows and combines snap build/pack with Snap Store upload. As a result, PRs that change snap packaging, snapcraft input layout, or workflow copy paths do not validate the snap pack path before merge.

Recent release failures showed this gap:

  • #1855 fixed an invalid actions/download-artifact pin, but the failure was only caught on the main release workflow.
  • #1859 fixed a stale wrapper path after the release workflow progressed further and failed while preparing snap/prebuilt/.

Proposed Design

Split PR-safe snap validation from release publishing:

  • Add a PR-safe workflow or job that builds/packs the snap without Snap Store credentials, deployment environments, or snapcraft upload.
  • Reuse the same binary artifact layout and snap/prebuilt/ assembly path as the release workflow where practical.
  • Consider factoring shared snap input assembly into a script or reusable action so PR and release validation exercise the same logic.
  • Start with amd64-only PR validation to control runtime and runner cost. Keep the full amd64/arm64 matrix for release workflows.
  • Keep release workflows responsible for publishing to latest/edge and latest/stable using SNAPCRAFT_STORE_CREDENTIALS.

A cheap static packaging asset check may also be useful. For example, validate that workflow copy sources exist and that the files required by snapcraft.yaml are produced by the snap assembly step.

Alternatives Considered

  • Keep validating only in release workflows. This misses packaging regressions until after merge.
  • Add snap-package.yml directly to pull_request. This is not appropriate as-is because the workflow currently requires release credentials/environments and always uploads to the Snap Store.
  • Add only static checks. This catches stale paths, but does not prove snapcraft pack still works.

Agent Investigation

  • snap-package.yml currently has only on: workflow_call.
  • It is called from release-dev.yml and release-tag.yml.
  • It requires publish-credentials, mapped to SNAPCRAFT_STORE_CREDENTIALS.
  • It always runs snapcraft upload --release ....
  • It depends on release workflow artifacts named cli-linux-*, gateway-binary-linux-*, and supervisor-binary-linux-*.
  • Run 27299497855 showed #1855 fixed action resolution, then the snap job failed later during Prepare snap build directory due to the stale deploy/snap/bin/openshell-gateway-wrapper path.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading snap-package.yml, release-dev.yml, and release-tag.yml, then inspect the artifact names and the Prepare snap build directory step. Trace how snap/prebuilt/ is assembled and where SNAPCRAFT_STORE_CREDENTIALS and snapcraft upload are used. Done means PRs can run amd64-only snap packing without credentials or publishing while release workflows retain their existing matrix and upload behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, yaml
Domain
build-system, ci-cd, release
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.