You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 07a05f8
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: CI.md
+12-10Lines changed: 12 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,8 +42,8 @@ missing baselines, merge conflicts, and tool failures always fail the check.
42
42
43
43
Release Tag compares the tagged candidate cumulatively against the previous
44
44
stable release, using the same minor-versus-patch policy. Its result is part
45
-
of the qualification profile: failure blocks stable publication, while a
46
-
pre-release can still publish with failed qualification recorded. This checks
45
+
of the qualification profile: failure blocks both pre-release and stable
46
+
publication. Failed candidates retain build artifacts and evidence in Actions. This checks
47
47
protobuf compatibility; SDK/configuration compatibility and migration review
48
48
remain separate qualification work.
49
49
@@ -188,9 +188,8 @@ candidate snapshot. Cargo Deny uses its existing NVIDIA self-hosted runner and
188
188
CI container.
189
189
190
190
Tagged releases treat Cargo Deny and Codex Security findings as failures of the
191
-
currently implemented qualification profile. A profile failure does not prevent
192
-
a pre-release candidate's complete artifact set from being published, but it
193
-
does prevent stable publication. CodeQL, Trivy, and Zizmor findings are
191
+
currently implemented qualification profile. A profile failure prevents both
192
+
pre-release and stable publication. CodeQL, Trivy, and Zizmor findings are
194
193
temporarily informational for tagged releases: the existing findings were
195
194
reviewed and accepted for v0.1.0 and will be addressed in 0.1.x releases.
196
195
Scanner failures still fail qualification.
@@ -209,8 +208,9 @@ gh workflow run security-scan.yml --ref main \
209
208
-F fail-on-static-findings=false
210
209
```
211
210
212
-
To integrate it into a larger workflow, run it after the job that pushes the
213
-
candidate tag and publishes the artifacts. This example assumes an existing
211
+
To integrate it into a larger workflow, run it after the job that creates the
212
+
candidate tag and stages source-addressed artifacts for scanning. Release-facing
213
+
publication follows successful qualification. This example assumes an existing
214
214
`build` job with outputs named `candidate_tag`, `gateway_image`, `sandbox_image`,
215
215
and `chart_ref`; adapt those names to your workflow:
216
216
@@ -241,8 +241,8 @@ jobs:
241
241
Set `needs: security` on a downstream promotion job to require successful scans.
242
242
The tagged release workflow records protobuf, security, and integration outcomes in a
243
243
qualification job after publishing its commit-addressed OCI images. A failed
244
-
check remains visible in the workflow, but pre-release artifact assembly and
245
-
publication continue. Stable publication currently requires the implemented
244
+
check remains visible in the workflow, with build artifacts and evidence retained
245
+
in Actions storage. Both pre-release and stable publication require the implemented
246
246
`release-tag-v1`profile to pass; that profile is an incremental subset of RFC
247
247
0014 qualification.
248
248
@@ -498,7 +498,9 @@ These workflows run after merge to publish dev/tagged artifacts and verify them.
498
498
| File | Role |
499
499
|---|---|
500
500
| `.github/workflows/release-dev.yml` | Publishes the rolling `dev` build on every push to `main`. Builds gateway, sandbox, and supervisor images and binaries, packages, wheels, and pushes the Helm chart as `oci://ghcr.io/nvidia/openshell/helm-chart:0.0.0-dev` (plus an immutable `0.0.0-dev.<sha>` pin). Also dispatchable manually. |
501
-
| `.github/workflows/release-tag.yml` | Publishes tagged stable releases and manually dispatched pre-releases. Its automatic tag trigger excludes `-pre.*`. Protobuf, security, and integration failures do not block pre-release artifact publication. Stable publication requires the currently implemented qualification profile to pass; the summary identifies the remaining RFC 0014 coverage. |
501
+
| `.github/workflows/release-tag.yml` | Publishes tagged stable releases and manually dispatched pre-releases. Its automatic tag trigger excludes `-pre.*`. Both require the currently implemented qualification profile to pass before publication; the summary identifies the remaining RFC 0014 coverage. Failed candidates retain build artifacts and evidence in Actions storage. Source-SHA OCI images remain available as qualification inputs. |
502
+
| `.github/workflows/snap-package.yml` | Builds Snap and component artifacts for Release Dev and Release Tag without Store credentials or publication. |
503
+
| `.github/workflows/snap-publish.yml` | Uploads existing Snap and component artifacts to the Store without rebuilding. Release Dev calls it directly for `latest/edge` after Snap builds and requires it to succeed before creating the dev release. Release Tag calls it for `latest/stable` only for stable releases, after qualification and release assembly succeed. |
502
504
| `.github/workflows/release-canary.yml` | Smoke-tests published dev artifacts in the `macos`, `ubuntu-deb`, `ubuntu-snap-system-docker`, `fedora`, and `kubernetes` (kind + Helm) jobs. Each job reaches its gateway and creates, exercises, and deletes a sandbox. The Snap lanes verify a compatible system Docker lifecycle and `ubuntu-snap-docker-preflight` tests fail-fast behavior when Docker is absent or supplied by the Docker snap. The positive Snap lane also runs a local policy containment check with the packaged prover. It runs automatically after `Release Dev` succeeds and supports manual dispatch (`gh workflow run release-canary.yml --ref <branch>`). See the `test-release-canary` skill for the playbook and local kind reproduction. |
Copy file name to clipboardExpand all lines: docs/about/support-matrix.mdx
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,6 +19,12 @@ the release cycle. Use a stable release for production deployments.
19
19
| Pre-release | Built nightly when `main` has changed and normal CI passes. Versions use the form `X.Y.Z-pre.N`. | Validating the immutable artifact set proposed for the next stable release. Pre-releases use the stable feature set but may not have passed qualification. |
20
20
| Stable | Promoted from a pre-release that passes conformance, upgrade, API compatibility, artifact, and security checks. Versions use the form `X.Y.Z`. | Production use within this support matrix. |
21
21
22
+
The tagged release pipeline publishes pre-release and stable artifacts only
23
+
after its current qualification profile passes. Failed candidates retain build
24
+
artifacts and qualification evidence in CI storage. The current profile covers
25
+
part of the complete release qualification policy; passing it does not establish
26
+
full RFC 0014 coverage.
27
+
22
28
Tagged stable releases generally go out every week. OpenShell targets Tuesday
23
29
publication when there are changes and every blocking qualification check
0 commit comments