Artifact CI

Artifact CI registers the build outputs your CI pipeline produces, container images and zip bundles, so Facets can deploy the right one to the right place. An artifact is a named pointer that can hold several image or zip URIs at once, each registered against an environment, a git ref, or a release stream. That registration is what decides which image deploys where. You drive it two ways: run the raptor CLI inside your CI system, or ask Praxis in chat.

Register from your CI pipeline

Run the raptor CLI inside any CI system, GitHub Actions, GitLab CI, Jenkins, or a plain shell script, to register each build as your pipeline produces it. The core step points an artifact at the URI you just built, keyed by environment, git ref, or release stream:

raptor set artifact-uri -p PROJECT -e ENV ARTIFACT_NAME --uri REGISTRY_URI/IMAGE:TAG
raptor set artifact-uri -p PROJECT --git-ref main ARTIFACT_NAME --uri REGISTRY_URI/IMAGE:TAG
raptor set artifact-uri -p PROJECT --release-stream stable ARTIFACT_NAME --uri REGISTRY_URI/IMAGE:TAG

Most services register a container image. For Lambda and other serverless bundles, register a zip with raptor set artifact-zip instead. One image can back several artifacts, so a single build registers once per service that runs it. Artifact names are global to the control plane, so prefix them with the project name (myproject-api, not api) to avoid collisions.

For the full pipeline setup, authenticating raptor, building and pushing the image, and triggering the release, see the Platform Guide: Integrating with CI pipelines.

Register from Praxis chat

When you would rather not script it, ask Praxis. Describe the outcome and it runs the same raptor steps for you: inspecting registries, fetching credentials, and registering URIs across environments. For example:

Register the image I just pushed as the api artifact for dev.

Praxis confirms the registry and project, sets the URI for the dev environment, and asks whether to deploy before it releases anything.

Inspect what is registered

To see what a release will actually deploy, list the artifacts and the URIs registered against one:

raptor get artifacts -p PROJECT
raptor get artifact-uris -p PROJECT ARTIFACT_NAME

Check artifact-uris when the wrong image ends up deployed. It shows every URI registered against the artifact and what each is keyed to.

Access and safety

How a change is gated depends on which surface you use.

In Praxis chat, every write, creating an artifact, setting a URI, uploading a bundle, goes through the plan-and-approve step. Praxis shows what it will do and waits for your go-ahead. See How Praxis works for that model.

From the CLI in CI, there is no chat-style approval. Commands run directly under whatever raptor login the CI job is authenticated as, so the token you store in CI secrets defines what the pipeline can do. The release step is the only one that deploys, and it stays opt-in and --target-scoped for exactly this reason: nothing you register goes live until a release command runs.

Related

• How Praxis works - The execution, credential, and approval model
• Debug a failed release - Investigate a deployment that failed
• Integrating with CI pipelines - Full pipeline setup for building and pushing artifacts