Containers

• Code projects — Containers are the images your CI pipelines build and publish to the registry. They appear automatically after a successful build, and the list is read-only.
• Upload projects — Each container-upload repository (created under Repositories) shows up here as a container. You bring images in by uploading them.

In both cases there is nothing to "associate" — adding a container means adding (or building from) a repository.

For a code project, the section lists "Images built by this project's CI pipelines and published to the registry." Images are discovered automatically from the project's repositories' recent pipeline runs — there is no manual add, edit, or remove.

Available controls:

• Search containers — Filter by image name.
• Sort — Recently Updated or A–Z.
• Updated (timestamp) — When the snapshot was last refreshed.
• Refresh — Re-pull the latest images from the pipeline snapshot.

If nothing has been built yet, the section shows: "No images in the registry yet — they appear here after a successful CI build."

For an upload project, "Each container is backed by a container-upload repository (created under Repositories)." When you create a container-upload repository under Repositories, IronSled automatically creates a matching container here — no separate association step.

If there are none yet, the section shows: "No containers yet. Add a container-upload repository under Repositories — each one shows up here as a container."

Uploading an Image

Each container card has an Upload button:

1. Click Upload on the container card.
2. In the Upload image drawer (titled for the container), drag and drop (or browse for) your image as a Docker .tar, .tar.gz, or .tgz — the file produced by docker save.
3. Enter a Tag (e.g., 1.0.0, 2.3.1, latest; letters, numbers, _, ., - only, max 128 characters) and an optional Note.
4. Click Upload.

The image is then scanned and published automatically — you do not trigger a pipeline yourself. Its status advances as the pipeline runs (see below).

Recovering Missing Versions

If versions are missing — for example, images published before they were tracked, or a pipeline that did not report back — a Rescan pipelines action (platform managers) backfills image versions from the project's GitLab pipeline history.

Expand a container to see its version history, newest first. The latest version is marked · current. Each version shows a status dot and label reflecting where the image is in its lifecycle:

Each version also shows its Published or Uploaded date and its scan results — either No issues or a severity breakdown (Critical / High / Medium / Low). Opening the scan report (Pipeline image scan) shows the full Trivy report: each CVE with its affected package, installed and fixed versions, and severity.

Container data is driven by the pipeline lifecycle, not a manual cache refresh:

• Uploaded images advance automatically through scanning → publish as their pipeline runs; the live pipeline phase is reflected in the status.
• A scheduled reconciliation job advances in-flight uploads to their final state and caches their scan summaries.
• For code projects, the pipeline-built image snapshot is cached and recomputed periodically; use Refresh to force an update.
• Rescan pipelines (platform managers) backfills any missing versions from GitLab pipeline history.

The previous per-container "Refresh Cache" button has been replaced by this automatic, pipeline-driven model.

Containers are created and removed through their backing repositories under Repositories, so there is no separate add or delete action in this section.