Artifacts and Marketplace

Two pages under Build & deploy deal with what your builds produce and the tools around them:

• Artifacts: files your pipeline builds archived, and container images in your registries.
• Marketplace: a vetted catalog of DevOps tools (and any Docker image) that you can deploy to Kubernetes or export for a Docker host.

#The Artifacts page

Artifacts has four tabs:

Tiles at the top count Registries, Repositories, Tags (with their total size) and Tags with critical CVEs.

#Build artifacts

A build artifact is a file a build kept: a test report, a security report, a package or any other output. Artifacts are archived after every build, including failed ones, because that is when reports matter most.

#Archive files from a build

Files come from three places:

• Pipeline file: a top-level artifacts: list of paths or globs.
• Freestyle project: Post-build → Archive artifacts, one path or glob per line.
• Plugins: some plugins archive their own report, for example trivy-scan, iac-security-scan, infracost-estimate, terraform-plan-report and pdf-report.

stages:
  - name: Build
    steps:
      - run: npm ci && npm test -- --reporters=jest-junit && npm run build
      - run: cd dist && zip -r ../web-${{ run.number }}.zip .
artifacts:
  - web-${{ run.number }}.zip
  - junit.xml
  - reports/**/*.json

Rules:

• Paths are relative to the workspace. No leading / and no ...
• Files under .onx/ are never archived.
• A file larger than ARTIFACT_MAX_MB (default 100 MB) is refused, and a build keeps at most ARTIFACT_MAX_FILES files (default 200). The console lists each file that was archived or refused.
• If nothing matches, the console says Artifacts: nothing matched ....

See Pipeline syntax.

#What OpsNexus recognises

If a security report cannot be imported, the file is still kept and marked Not imported into Security. See Security center.

#Find and open artifacts

• On a build's page, the Artifacts card lists the build's files with their total size.
• On Artifacts → Build artifacts, filter by Pipeline, Type and File name. The page shows how many files there are and how much storage they use.
• View shows JSON, XML, text, Markdown, CSV and YAML files in the browser (the first 400 KB). HTML is never shown in the browser; download it instead.
• Download saves the file.
• ✕ deletes one file from the server. Findings already imported into Security stay. Deleting needs full access to CI/CD pipelines.

Viewing build artifacts needs read access to CI/CD pipelines.

#Storage and retention

• Files are stored on the server in ARTIFACT_DIR (default /app/artifacts, the artifacts Docker volume).
• They are deleted with their build. A pipeline keeps the number of builds set in Keep builds (default 30), so older builds and their artifacts are removed automatically.
• Deleting a pipeline deletes all its artifacts.

See Environment variables for ARTIFACT_DIR, ARTIFACT_MAX_MB and ARTIFACT_MAX_FILES, and Backup and restore.

#Container registries

Registries & images connects OpsNexus to your container registries and lists their repositories and tags.

Supported registries:

To connect a registry:

1. Open Artifacts and select Connect registry.
2. Choose the registry type, give it a Display name and fill in the fields.
3. Turn on Allow deleting tags if you want cleanup policies or manual tag deletion. Off means read-only.
4. Select Connect and sync.

Secret fields are stored in the secret store. Registries sync every 30 minutes, and Sync now syncs at once.

For each repository you see its tags, size, pulls and last push. For each tag: digest, size, push time, platforms, the registry's own scan result and OpsNexus findings. A docker pull command is shown under the tags.

If a sync fails, the registry shows Can't read this registry with the error and a Fix settings button. Disconnecting a registry does not touch the images in it.

#Cleanup policies

A cleanup policy deletes old tags from a registry.

1. Open Artifacts → Cleanup policies.
2. Under New cleanup policy, choose the Registry and set:
   • Repositories (glob), for example * or team/*.
   • Keep newest: how many tags to keep per repository.
   • Delete older than (days): optional age limit.
   • Never delete tags: protected tags, for example latest,main,prod*,v*.
3. Select Save policy.

Policies run daily on registries that have delete access. Preview shows which tags a policy would delete and how much space that frees, and Delete these tags now applies it at once.

#Docker Hub catalog

Docker Hub catalog searches public Docker Hub images (type at least two letters). Turn on Official images only to hide community images. Select an image to see its tags, sizes, update times and platforms.

#The Marketplace

Marketplace (the DevOps tools marketplace page) deploys DevOps tools to a Kubernetes cluster, or generates a docker-compose.yml for a Docker host. It has three tabs: Catalog, Deployments and Clusters.

#Safety rules

These rules always apply:

• Catalog tools use their verified publisher's image. Other images must be Docker Official Images, come from one of your connected registries, or you confirm that you trust the publisher.
• The tag you choose is resolved to an immutable digest, and the deployment pins image@sha256:....
• The latest tag is refused. CPU and memory limits are required.
• Containers run as non-root where the image supports it, with no privilege escalation and all capabilities dropped.
• Secret environment values go to the secret store and into a Kubernetes Secret, never into the OpsNexus database.

#Catalog

Catalog has three sources: Verified catalog, Docker Hub and Your registries.

The verified catalog includes:

Some entries are not deployed as a service. For those, the card shows Install steps, CI setup (for tools you run in a pipeline, such as Checkov and Gitleaks) or How to connect (for hosted services) instead of Deploy.

Docker Hub searches every public image. Your registries lists images from registries connected on the Artifacts page, including private Docker Hub repositories; private images get a Kubernetes image-pull secret.

#Deploy a tool

You need a cluster on the Clusters tab first (for Kubernetes), and modify access to Tools marketplace.

1. On Catalog, select Deploy on a tool or image.
2. Choose Kubernetes or Docker host.
3. For Kubernetes, choose the Cluster, a Name (lowercase, numbers, dashes) and a Namespace.
4. Pick the Version (pinned to digest). latest is not allowed.
5. Set CPU limit (for example 500m or 2) and Memory limit (for example 512Mi or 2Gi).
6. For Kubernetes, set Persistent storage (GB) and, for tools with a web port, Domain (optional, creates an Ingress).
7. For a custom image, set Container port (optional), Run as user ID (optional) and Data folder in the container if needed.
8. Add environment variables and secret values.
9. Select Run checks. OpsNexus runs the pre-deploy checks and shows the result.
10. Select Deploy (Kubernetes) or Download docker-compose.yml (Docker host).

The compose file uses the same digest pinning and resource limits.

#Deployments

Deployments lists deployed tools with namespace, version, status, revision and last update. Statuses refresh every 2 minutes. Open a deployment to:

• Upgrade to another version,
• Show logs,
• Roll back to an earlier revision from History,
• Uninstall (keeps the data volume, so a reinstall picks up where it left off), or Uninstall + delete data (you type the name to confirm).

#Clusters

Clusters holds the Kubernetes clusters the Marketplace deploys to. Adding one needs full access to Tools marketplace.

1. Create a service account in the cluster. The page shows the commands:

kubectl create namespace devops-tools
kubectl -n devops-tools create serviceaccount opsnexus
kubectl -n devops-tools create rolebinding opsnexus-admin --clusterrole=admin --serviceaccount=devops-tools:opsnexus
kubectl create clusterrole opsnexus-ns --verb=get,create,patch --resource=namespaces
kubectl create clusterrolebinding opsnexus-ns --clusterrole=opsnexus-ns --serviceaccount=devops-tools:opsnexus
kubectl -n devops-tools create token opsnexus --duration=8760h   # paste this as the token

2. Select Add Kubernetes cluster and enter the Name, API server URL, Service-account token, Default namespace, optional Ingress class and Storage class, and Cluster CA certificate (PEM, optional).
3. Select Add and test.

Test checks a cluster again. Remove removes it from OpsNexus without touching the cluster. Clusters you manage and monitor are covered in Kubernetes.