Publish community StackPacks individually on Quay

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @StackVista/dev-team

.gitignore

@@ -1 +1,4 @@
 .idea
+*.sts
+stackpacks/*/target/
+docker/rootfs/

CONTRIBUTING.md

@@ -0,0 +1,51 @@
+# Contribute a community StackPack
+
+Community StackPacks are not supported by SUSE. Contributors maintain their
+integrations: answer issues, update compatibility information and fix broken
+behavior. SUSE maintainers review pull requests for validity and safety, not for
+production readiness. This follows the
+[SUSE community-blueprints model](https://github.com/SUSE/community-blueprints/blob/main/CONTRIBUTING.md).
+
+## Add or update a StackPack
+
+1. Add your integration under `stackpacks/<name>/`. Use a lowercase name with
+   dash-separated words. The directory name must match `name` in
+   `stackpack.yaml`.
+2. Add a README with a `Maintainer: @github-handle` line. List prerequisites,
+   tested product versions, required permissions and parameters, installation
+   instructions, and how to remove the integration.
+3. Add the package definition, settings, resources and any icons or includes.
+   Use a `major.minor.patch` version, optionally followed by a prerelease suffix.
+   Image tags combine the StackPack name and this version, so build metadata
+   with `+` is not accepted.
+4. Increase the version when changing an existing StackPack. Published version
+   tags are immutable.
+5. Package and validate locally, then open a pull request. CI checks the
+   definition, mapping expressions, maintainer and version; packages the
+   integration; builds both image architectures; and scans secrets and
+   vulnerabilities.
+
+Use the [authoring skill](.agents/skills/create-stackpack/SKILL.md) for the CLI
+workflow and current schema documentation. The CI workflow pins the platform
+validator image used by `scripts/ci/validate_stackpack.sh`:
+
+```sh
+export VALIDATOR_IMAGE='<validator image and digest from the CI workflow>'
+bash scripts/ci/validate_stackpack.sh stackpacks/my-integration
+sts stackpack package --directory stackpacks/my-integration
+```
+
+Only modify integrations you maintain, unless you agree on the change with their
+maintainers. A change of maintainer must update the README. A SUSE maintainer
+merges a contribution after checks pass and reviews approve.
+
+## Keep the integration usable
+
+State any compatibility limits in the README. Respond to reported failures and
+update the integration when its dependencies change. If you stop maintaining it,
+open an issue to find a replacement maintainer.
+
+SUSE maintainers may mark an integration as unmaintained or remove it after
+contacting its maintainer about unresolved breakage. Record the status and
+replacement options in the issue before removal. Review and inclusion do not
+create a SUSE support or security-update commitment.

README.md

@@ -1,11 +1,92 @@
-# contrib-stackpacks
-SUSE Observability Community Stackpacks
+# Community StackPacks
 
-Use the [Create a StackPack agent skill](.agents/skills/create-stackpack/SKILL.md) to
-create or extend an integration with the latest StackPack documentation, the `sts`
-CLI, and MCP queries for runtime validation.
+This repository contains community integrations for SUSE Observability.
+Customers choose which integrations to add; these StackPacks do not ship with
+the product by default.
 
-Codex, Antigravity, and Gemini CLI load the skill from `.agents/skills/`.
-Claude Code loads it through the `.claude/skills/create-stackpack` symlink.
-For other projects, copy the `create-stackpack` directory into your assistant's
-supported skill directory.
+Community StackPacks are maintained by their contributors and are not supported
+by SUSE. SUSE maintainers review contributions for validity and safety. Approval
+does not provide a support commitment or a production-readiness guarantee.
+
+| Repository | Content and ownership |
+| --- | --- |
+| [core-stackpacks](https://github.com/StackVista/core-stackpacks) | Core integrations maintained by the SUSE Observability team and shipped with the product. |
+| [suse-stackpacks](https://github.com/StackVista/suse-stackpacks) | Internal integrations for SUSE products, maintained by their product teams. |
+| contrib-stackpacks | Integrations for other technologies, maintained by the community and installed by customers. |
+
+## Add a StackPack image
+
+Each StackPack has its own container image:
+`quay.io/stackstate/contrib-stackpacks:<name>-<version>`. The tag combines the
+StackPack name and version in its `stackpack.yaml`. Images contain one `.sts`
+package in `/stackpacks` and support AMD64 and ARM64.
+
+Add the image to your SUSE Observability Helm values. Replace the example name
+and version with a published StackPack:
+
+```yaml
+stackstate:
+  stackpacks:
+    extraImages:
+      - name: my-integration
+        registry: quay.io
+        repository: stackstate/contrib-stackpacks
+        tag: "my-integration-0.0.1"
+        pullPolicy: IfNotPresent
+```
+
+Apply the values through your normal Helm upgrade process. Keep this entry on
+later upgrades. The image makes the StackPack available in the catalog; install
+an instance through the UI or `sts stackpack install`.
+
+You can use an image from another registry by changing `registry`, `repository`
+and `tag`. For a private registry, configure `global.imagePullSecrets` with a
+Kubernetes image-pull secret in the SUSE Observability namespace. The image must
+contain readable `.sts` files in `/stackpacks` and `/bin/sh` for the chart's copy
+script. Use a unique image `name` for each entry.
+
+## Upload a package with the CLI
+
+Download the `sts-<name>` artifact from the StackPack's successful
+[CI run](https://github.com/StackVista/contrib-stackpacks/actions), or package a
+local checkout:
+
+```sh
+sts stackpack package --directory stackpacks/my-integration
+```
+
+Configure the `sts` CLI for your SUSE Observability instance, then upload the
+package:
+
+```sh
+sts stackpack upload --file ./my-integration-0.0.1.sts
+sts stackpack list-parameters --name my-integration
+sts stackpack install --name my-integration
+```
+
+Upload makes the version available; installation creates an instance. Supply the
+parameters described in the StackPack's README when installing. Pull-request
+artifacts use snapshot versions; published main images use the declared version.
+
+## Contribute
+
+Read [CONTRIBUTING.md](CONTRIBUTING.md). Every StackPack needs a named maintainer
+and instructions for prerequisites, installation, required parameters and removal.
+
+The [Create a StackPack agent skill](.agents/skills/create-stackpack/SKILL.md)
+helps create integrations with the StackPack documentation and CLI. Codex,
+Antigravity and Gemini CLI load it from `.agents/skills/`; Claude Code loads the
+`.claude/skills/create-stackpack` symlink.
+
+## Publish public images
+
+CI validates and packages contributions from forks without publication
+credentials. Main-branch pushes build, scan and sign one image per StackPack in
+the existing public Quay repository using its dedicated `QUAY_USER` and
+`QUAY_PASSWORD` credentials. Tags combine the StackPack name and package version
+and are never overwritten. The workflow checks image access without credentials
+after publication; a rerun reuses an existing version.
+
+The image's source label connects the image to this repository. Before
+announcing a StackPack, verify that both architecture images can be pulled
+without credentials.

docker/Dockerfile

@@ -1,4 +1,4 @@
-FROM registry.suse.com/bci/bci-minimal:15.7-26.76
+FROM registry.suse.com/bci/bci-minimal:15.7@sha256:207e6eab7c25f517e30c18e0479bbbb366d1bb3380f8d71a83064eb119edc71d
 
 COPY rootfs/stackpacks /stackpacks
 

scripts/ci/verify_versions_bumped.sh

@@ -11,7 +11,7 @@ set -euo pipefail
 stackpack="$1"
 : "${TARGET_BRANCH:?TARGET_BRANCH must be set (e.g. from github.base_ref)}"
 
-git fetch origin ${TARGET_BRANCH}
+git fetch origin -- "${TARGET_BRANCH}"
 
 # Gate: skip if THIS BRANCH didn't modify stackpacks/<stackpack>/. We use the merge-base
 # (not ${TARGET_BRANCH}'s tip) because if master moves forward after this