Skip to main content

​
ankra pipeline

Manage Ankra Pipelines: in-cluster CI/CD runs, the pipeline definition of record, and its cron schedules. Every command addresses one pipeline with exactly one of: —application <name-or-id> the application the pipeline builds and deploys —repository <repository-id> the pipeline repository directly There is no lookup route yet for a repository by “owner/name” - only by-id and by-application addressing exist - so —repository takes the repository’s id (for example, the “repository.id” field ‘ankra pipeline definition get’ returns). Most invocations want —application instead. A run is addressed by its id (the RUN ID column, not the “run_id” field a JSON/YAML response also carries - that second field is the cross-lifecycle umbrella run this pipeline run belongs to, useful for correlating with ‘ankra cluster operations’, but not what these commands accept). ‘pipeline definitions get|approve’ are the one exception: they address a stored definition directly by its own id and take neither flag - see ‘ankra pipeline definitions —help’.

​
ankra pipeline artifacts

List a pipeline run’s stored step logs and declared artifacts, oldest first. Every step’s complete output is archived as a “step_log” artifact once the step concludes (‘ankra pipeline logs’ reads that one automatically for a concluded step); anything a stage’s own “artifacts:” block declared shows up as “artifact”. An empty first page means the run genuinely has nothing stored yet - no step has concluded, or the organisation has no ready backup vault to store into. STATUS is “pending” until the upload is confirmed, “uploaded” once “artifacts download” can fetch it, “failed” if it never arrived (see the row’s error), or “expired” once retention removed it. The listing is paged: it prints one server page (50 rows by default) and says when there is another, which —cursor reads. So a run with more artifacts than one page shows its oldest first, and the list is complete only once no further page is offered.
Flags

​
ankra pipeline artifacts download

Download a stored artifact, following the platform’s redirect to its presigned storage URL and streaming it to disk.
Flags

​
ankra pipeline cancel

Cancel a pipeline run that has not concluded
Flags

​
ankra pipeline definition

Manage the pipeline definition of record

​
ankra pipeline definition get

Show the pipeline definition of record
Flags

​
ankra pipeline definition put

Store a generated pipeline definition server-side, replacing the repository’s definition of record. Requires the pipelines.manage permission. This does not touch the repository’s committed .ankra/pipeline.yaml: a committed file still wins for logic per the DescriptorOfRecord contract, so ‘put’ is for a repository whose pipeline Ankra generates and stores rather than one you author and commit yourself.
Flags

​
ankra pipeline definitions

Read and grant an administrator’s approval of one stored pipeline definition’s protected sections: the authority-bearing parts of a pipeline - permissions, credentials, secrets scope, network tier, image policy, runs_on, environment gates and more - that a pull request may add logic around but never grant itself (“logic is open, authority is closed”). These two commands address one stored definition directly by its own id, unlike ‘pipeline definition get|put’ which read and write the definition of record for a repository or application. There is no lookup or listing route for a definition’s id: find one from a pull request’s status comment, or from the “authority_definition_id” field ‘ankra pipeline get’ prints on a run whose authority changed.

​
ankra pipeline definitions approve

Record an administrator’s approval of one stored pipeline definition’s protected sections. Requires the pipelines.manage permission and a human actor - a service-account or agent token is refused. Approving grants whatever permissions, credentials, secrets scope, network tier and other protected sections the definition declares - inspect them first with ‘ankra pipeline definitions get <id>’ if you have not, since this command prints only the protected-sections hash, not their content. Confirms before approving; —yes skips the prompt for scripted use. Only the repository’s CURRENT default-branch definition can be approved, and only once: approving a definition the default branch has since moved past, or one already approved, answers a 409 this command prints verbatim rather than treating as success. A definition recorded before its protected sections were ever hashed answers the same 409.
Flags

​
ankra pipeline definitions get

Show one pipeline definition’s protected-authority approval state
Flags

​
ankra pipeline findings

List a pipeline run’s persisted scan findings. Findings are recorded once a “scan” step has concluded for the run’s own commit; a run with no scan step, or one still running, answers an empty list rather than an error. The default table sorts worst severity first and groups by tool, so the findings most likely to block a “gate” step are always at the top; -o json/yaml prints every field the server carries, including each finding’s tool-specific detail.
Flags

​
ankra pipeline get

Show a pipeline run’s detail
Flags

​
ankra pipeline list

List a pipeline’s runs
Flags

​
ankra pipeline logs

Show a pipeline step’s output. A step that has already concluded prints its complete log in one shot - —follow does nothing extra for it, since there is nothing left to produce. Its archived log is read when the run has one; archiving needs a ready backup vault, and when there is none the command replays the step’s output from the platform’s retained log stream instead and stops when that runs out. A step that is still running is followed over the live log stream: without —follow, the command tails the step until it concludes and then stops; with —follow it keeps reconnecting through a dropped stream instead of giving up. A live connection starts from the moment it connects unless you pass —replay, which asks the platform for the output the step already produced first. A step that has not started yet has no log stream. With —follow the command waits for it - saying what it is blocked on - and attaches as soon as the step starts; a step that concludes without ever starting prints its outcome and whatever log it does have. One invocation spends at most 30 minutes waiting, in total across every time the step goes back to waiting. Without —follow the command says the step has not started and stops.
Flags

​
ankra pipeline repositories

Connect a bare Git repository to Ankra Pipelines, list what the organisation has connected, read one by id, and disconnect one. A connected repository is what a push, pull request or tag webhook resolves against to start a run. Connecting one here does not require an Ankra application - use it for a repository with no application (docs, website, values repos) or before one exists; an application already on Ankra links to its own repository automatically.

​
ankra pipeline repositories connect

Connect a bare Git repository to Ankra Pipelines: a push, pull request or tag webhook on it can then start a run. Connecting a repository that is already connected does not create a second row or refresh the first - the platform refuses with the existing repository’s id named in the error, so a setup script that runs this unconditionally can still learn the id it has either way. —application links the repository to an application already in this organisation (by id) without changing that application’s own pipeline source - it is refused (422) for an application outside the organisation. —cluster overrides the organisation’s declared CI cluster (‘ankra ci-settings’ / GET /org/ci-settings) for just this repository’s pipelines - it is refused (422) for a cluster outside the organisation, or one whose agent has not advertised it can run pipeline steps. For a GitHub repository, the committed .ankra/pipeline.yaml on the default branch (read through —credential) is recorded as the definition of record in the same call when it parses. A repository with no committed file, or on another provider, connects with no definition - store one with ‘ankra pipeline definition put —repository <id> <file>’. Running connect a second time will not pick up a file committed since, because an already- connected repository is refused rather than re-read (see above); disconnect the repository and connect it again to force a fresh read.
Flags

​
ankra pipeline repositories disconnect

Disconnect a connected repository: from then on a push, pull request or tag webhook against it starts no run, and it drops out of ‘ankra pipeline repositories list’/‘get’. This is reversible by construction - connecting the same provider/owner/name again revives this exact row, definitions, runs, artifacts and findings kept - so disconnecting is not a delete. A repository with a pipeline run still queued or running refuses to disconnect (409); cancel or wait for it to conclude, then disconnect again.
Flags

​
ankra pipeline repositories get

Show one connected repository by id. There is no lookup by owner/name yet, only by id - run ‘ankra pipeline repositories list’ to find it.
Flags

​
ankra pipeline repositories list

List the organisation’s connected pipeline repositories
Flags

​
ankra pipeline rerun

Open a new run from a run that already happened. The new run is a fresh run, not a retry of the old one: the old run’s outcome stays the record of what happened, and ‘rerun_of_run_id’ ties the two together. —failed-only restricts the new run to the steps that did not succeed and whatever depended on them.
Flags

​
ankra pipeline run

Dispatch a manual run of a pipeline’s stored definition. A run is always dispatched at one named commit: resolving a ref to a commit belongs to the trigger lane (push/PR/tag webhooks), so a dispatch never runs against whatever commit the platform happens to have stored last. Inside a Git checkout the commit is read from HEAD, and —application is read from the repository the checkout points at, so ‘ankra pipeline run’ on its own runs what you are looking at. Outside a checkout, name them with —sha and —application.
Flags

​
ankra pipeline schedules

Manage a pipeline’s cron schedules

​
ankra pipeline schedules create

Add a cron schedule
Flags

​
ankra pipeline schedules delete

Remove a cron schedule
Flags

​
ankra pipeline schedules list

List a pipeline’s cron schedules
Flags

​
ankra pipeline schedules update

Change a cron schedule. Every flag is optional and only what is given changes - an update that names only —enabled leaves the cron, timezone, ref, and inputs exactly as they were.
Flags

​
ankra pipeline validate

Dry-run a pipeline definition: parse it, validate it, and plan it for a synthetic push and a synthetic pull request, without writing anything. Defaults to .ankra/pipeline.yaml when no file is given; with neither that file nor a —application/—repository definition already stored, there is nothing to validate. Passing a file validates its content directly, which is what a ‘is my pipeline.yaml correct before I commit it’ check wants.
Flags