The generated protobuf/gRPC modules under python/openshell/_proto/ are
gitignored. maturin honors .gitignore when collecting python-source files
from a git checkout, so native builds (Linux release CI, local
pip install .) dropped these modules and shipped an unimportable wheel.
The macOS wheel only included them by accident: it builds in a Docker
context whose COPY omits .git, so maturin had no gitignore to apply.
Pin the stubs back in with explicit, package-relative
[tool.maturin].include globs so inclusion no longer depends on whether
.git is present in the build context.
Add a wheel smoke check to the release-tag and release-dev workflows that
installs each Linux wheel in a clean python:3.12-slim image and imports
openshell.sandbox, and document the invariant in architecture/build.md.
Closes#1705
Signed-off-by: Max Dubrinsky <mdubrinsky@nvidia.com>
Switch the snapcraft build from 'source: .' (which copies the full
20 GB repo including 18 GB of target/ and build artifacts into LXD)
to 'source: ./snap/prebuilt' (~130 MB of only the binaries and
metadata that snapcraft needs).
The snap-package workflow now downloads the same cli, gateway, and
supervisor binaries that other packaging jobs (deb, rpm, tarballs)
use. A new 'Prepare snap build directory' step assembles snap/prebuilt/
with the 3 binaries, gateway wrapper script, LICENSE, README.md, and
a precomputed version string — everything snapcraft needs without
any source tree access.
This addresses CI/CD Improvements (issue #1361) by reducing data
transferred into the LXD sandbox by ~150x and eliminating the need
for snapcraft to traverse the entire repository tree.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
release-helm and tag-ghcr-release now depend on the release job.
This is to prevent a GHCR image or helm chart from being published when some
other aspect of the release fails.
Signed-off-by: Kris Hicks <khicks@nvidia.com>
* ci(helm): add OCI chart release workflow
Publishes the Helm chart to ghcr.io/nvidia/openshell/helm-chart via helm push on every tag (versioned + :latest) and main push (:0.0.0-dev overwrite + :0.0.0-dev.<sha> per-commit pin). Renames Chart.yaml name to helm-chart to match the target OCI path.
* ci(helm): use full sha in dev pinned chart version
The container images pushed by docker-build.yml are tagged with the
full $GITHUB_SHA, not a 7-char prefix. Match the chart's pinned
version (0.0.0-dev.<full-sha>) so the chart tag and the image tag
the chart resolves to are identical.
* docs(readme): add helm chart install instructions
Document the OCI chart at ghcr.io/nvidia/openshell/helm-chart with
examples for tagged, floating dev, and SHA-pinned dev installs, and
flag the Kubernetes deployment path as experimental.
* docs(helm): split chart details into chart README
Move the dev tag conventions and configuration pointers into a new
README under deploy/helm/openshell/ and shorten the top-level README
section to the install command (no --version, defaults to latest
tagged semver) plus a link to the chart README.
The trigger-wheel-publish job was downloading the wheel artifact onto a
persistent self-hosted runner just to glob the filenames. Since
download-artifact does not clean the destination directory, stale .whl
files from every previous run accumulated in release/ and were all sent
to GitLab as WHEEL_FILENAMES.
Confirmed on the runner: /home/ubuntu/actions-runner/_work/OpenShell/
OpenShell/release/ contained 120+ wheels spanning versions 0.0.5
through 0.0.10.
Fix: capture wheel filenames as a job output in build-python-wheels and
pass them directly to trigger-wheel-publish. The trigger job no longer
downloads the artifact at all — it only needs the filenames to construct
GitHub release asset URLs for GitLab/Kitmaker.
dependabot[bot]