Repository navigation
docs(pipelines): a converted job with no container runs in a pinned runner image; an imageless run stage is fatal (ankra-efrnzf.36) - #591
Conversation
…unner image; an imageless run stage is fatal The GitHub Actions, GitLab CI, Bitbucket and CircleCI converters now place every run stage that names no image in an Ubuntu runner image chosen from the job's runs-on (buildpack-deps:noble or :jammy, pinned by digest), set as defaults.image, and ankra pipeline validate refuses a run stage that resolves no image under pipeline_image: (ankra-efrnzf.36, cluster PR). - migrate-from-github-actions: a "Jobs with no container" section with the runs-on to image table, what the image carries and what it does not, and the review step pointing at it. - pipeline-reference: the image row says the missing image is fatal. Bead: ankra-efrnzf.36 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
✅ Run #247 succeededRun #247 for commit
🔗 Details ↗ · Updated Oct 19, 2026, 2:22 PM UTC Ankra AI reviewVerdict: looks good. Docs-only change describing the converter's pinned runner image for containerless jobs and the fatal pipeline_image violation for imageless run stages. The two files agree with each other: the migration guide's claim that validate, the commit gate and the planner refuse an imageless run stage matches the reference's description of the fatal pipeline_image: key, and the new anchor link (#jobs-with-no-container) matches the added heading. No correctness or security concerns in the prose itself. Reviewed commit 355445d. This review is read-only and advisory. |
![ankra-platform[bot]](https://avatars.githubusercontent.com/in/1164800?s=60&v=4){kind=small}
| | Field | Type | Default | Meaning | | ||
| |-------|------|---------|---------| | ||
| | `image` | string | `defaults.image` | The container the stage runs in; required for `run`, `scan` and `verify`. Ignored for `build` (the builder is Ankra's) and `checkout` (the git client is Ankra's own, pinned by digest) - either may be declared for readability, but the platform's own image runs regardless. What a stage may name is held to the organisation's [image policy](/guides/ankra-pipelines#organisation-ci-settings), matched at a path boundary: a policy prefix ending in `/`, `:` or `@` admits only that boundary. | | ||
| | `image` | string | `defaults.image` | The container the stage runs in; required for `run`, `scan` and `verify`. A `run` stage that resolves no image, its own or `defaults.image`, is fatal under `pipeline_image:`: the definition is refused at validation and no run is planned from it, naming the stage. Ignored for `build` (the builder is Ankra's) and `checkout` (the git client is Ankra's own, pinned by digest) - either may be declared for readability, but the platform's own image runs regardless. What a stage may name is held to the organisation's [image policy](/guides/ankra-pipelines#organisation-ci-settings), matched at a path boundary: a policy prefix ending in `/`, `:` or `@` admits only that boundary. | |
There was a problem hiding this comment.
[low] Fatal-refusal wording covers only run, but scan and verify are also listed as requiring an image
The row still says an image is 'required for run, scan and verify', but the new sentence describes the pipeline_image: refusal only for a run stage that resolves no image. A reader cannot tell whether an imageless scan or verify stage is also fatal under the same code, or is handled some other way. Either extend the sentence to cover all three kinds or state explicitly how scan/verify without an image behave.
Ankra AI review. Read-only and advisory.
There was a problem hiding this comment.
Fixed in 346772c: the row now says run is the one kind that runs in the image its definition names, and that scan (like build and checkout) runs Ankra's own images, which is what pipelinespec.RunsInDefinitionImage and the renderer do. verify is not an executable kind on this build, so it is no longer listed.
|
|
||
| | `runs-on` | Image | | ||
| |---|---| | ||
| | `ubuntu-latest`, `ubuntu-24.04`, `ubuntu-24.04-arm` | `buildpack-deps:noble`, pinned by digest (Ubuntu 24.04) | |
There was a problem hiding this comment.
[low] Table shows mutable tags while claiming the image is pinned by digest
The table lists buildpack-deps:noble / buildpack-deps:jammy yet says each is 'pinned by digest'. If the converter really emits a digest-pinned reference, consider showing the form it actually writes (e.g. buildpack-deps:noble@sha256:...) so users copying from the table do not end up with the mutable tag; if the tag is just shorthand, say so.
Ankra AI review. Read-only and advisory.
There was a problem hiding this comment.
Fixed in 346772c: the table shows the full tag@sha256: references the converter writes, and the paragraph says the tag is written with its digest.
… only run reads the definition image Ankra AI review on #591. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
| | Field | Type | Default | Meaning | | ||
| |-------|------|---------|---------| | ||
| | `image` | string | `defaults.image` | The container the stage runs in; required for `run`, `scan` and `verify`. Ignored for `build` (the builder is Ankra's) and `checkout` (the git client is Ankra's own, pinned by digest) - either may be declared for readability, but the platform's own image runs regardless. What a stage may name is held to the organisation's [image policy](/guides/ankra-pipelines#organisation-ci-settings), matched at a path boundary: a policy prefix ending in `/`, `:` or `@` admits only that boundary. | | ||
| | `image` | string | `defaults.image` | The container the stage runs in. Required for `run`, the one kind that runs in the image its definition names: a `run` stage that resolves no image, its own or `defaults.image`, is a fatal violation with the key `pipeline_image:`, so the definition is refused at validation and no run is planned from it, naming the stage. Ignored for `build` (the builder is Ankra's), `checkout` (the git client is Ankra's own, pinned by digest) and `scan` (the scanners' images are Ankra's) - any of them may declare one for readability, but the platform's own image runs regardless. What a stage may name is held to the organisation's [image policy](/guides/ankra-pipelines#organisation-ci-settings), matched at a path boundary: a policy prefix ending in `/`, `:` or `@` admits only that boundary. | |
There was a problem hiding this comment.
[medium] verify stage's image requirement silently dropped
The previous text said image was required for run, scan and verify; the rewrite names run as the one kind that requires an image and lists build, checkout and scan as ignored, but never mentions verify. A reader cannot tell whether a verify stage with no image is fatal, ignored, or inherits defaults.image. State explicitly which rule verify follows (or restore it to the required list if that is still the behaviour).
Ankra AI review. Read-only and advisory.
There was a problem hiding this comment.
Fixed in the latest push: the row now says a verify stage has no runner on this build (warned at validation, skipped by the planner whatever its image says, per the Stages table) and that pipeline_image: does not apply to it. verify was dropped from "required" because nothing runs it in its image today; pipelinespec.RunsInDefinitionImage is run only.
Ankra AI review on #591. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 participant
Bead: ankra-efrnzf.36
Documents ankraio/cluster#5008:
container:runs inbuildpack-deps:noble(ubuntu-latest, 24.04) orbuildpack-deps:jammy(22.04), pinned by digest, set asdefaults.image; the same image covers GitLab/Bitbucket jobs with noimage:and CircleCI machine executors. What the image carries and what it does not, and why a stage cannot install the rest at run time. The setup-step paragraph and the review checklist point at it.imagerow says arunstage that resolves no image is fatal underpipeline_image:.Merge after cluster#5008 is deployed.
🤖 Generated with Claude Code