> ## Documentation Index > Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt > Use this file to discover all available pages before exploring further. # ankra pipeline > Manage Ankra Pipelines ## 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 \ the application the pipeline builds and deploys \--repository \ 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. ```bash theme={null} ankra pipeline artifacts [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ------------------------------------------------------------------------ | | `--application` | | Application name or id whose pipeline to act on | | `--cursor` | | Page cursor from a previous listing's next\_cursor | | `--limit` | `0` | Maximum number of artifacts to return (server default 50, max 100) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | ## ankra pipeline artifacts download Download a stored artifact, following the platform's redirect to its presigned storage URL and streaming it to disk. ```bash theme={null} ankra pipeline artifacts download [flags] ``` **Flags** | Flag | Default | Description | | --------------- | ------- | ---------------------------------------------------------------------------------------- | | `--application` | | Application name or id whose pipeline to act on | | `--out` | | Local file to write the artifact to (default: the artifact id, in the current directory) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | ## ankra pipeline cancel Cancel a pipeline run that has not concluded ```bash theme={null} ankra pipeline cancel [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ------------------------------------------------------------------------ | | `--application` | | Application name or id whose pipeline to act on | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | ## ankra pipeline definition Manage the pipeline definition of record ## ankra pipeline definition get Show the pipeline definition of record ```bash theme={null} ankra pipeline definition get [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ------------------------------------------------------------------------ | | `--application` | | Application name or id whose pipeline to act on | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | ## 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. ```bash theme={null} ankra pipeline definition put [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ------------------------------------------------------------------------ | | `--application` | | Application name or id whose pipeline to act on | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | ## 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 \' 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. ```bash theme={null} ankra pipeline definitions approve [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ----------------------------------------------------- | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--yes` | `false` | Skip the confirmation prompt | ## ankra pipeline definitions get Show one pipeline definition's protected-authority approval state ```bash theme={null} ankra pipeline definitions get [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ----------------------------------------------------- | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## 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. ```bash theme={null} ankra pipeline findings [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ------------------------------------------------------------------------ | | `--application` | | Application name or id whose pipeline to act on | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | ## ankra pipeline get Show a pipeline run's detail ```bash theme={null} ankra pipeline get [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ------------------------------------------------------------------------ | | `--application` | | Application name or id whose pipeline to act on | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | ## ankra pipeline list List a pipeline's runs ```bash theme={null} ankra pipeline list [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ----------------------------------------------------------------------------------- | | `--application` | | Application name or id whose pipeline to act on | | `--branch` | | Filter by trigger branch | | `--cursor` | | Page cursor from a previous listing's next\_cursor | | `--head-sha` | | Filter by the exact full commit sha | | `--limit` | `0` | Maximum number of runs to return (server default 50, max 100) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | | `--status` | | Filter by run status: queued, running, or concluded | | `--trigger` | | Filter by trigger: push, pull\_request, tag, schedule, manual, api, agent, or rerun | ## 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. ```bash theme={null} ankra pipeline logs [flags] ``` **Flags** | Flag | Default | Description | | --------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------- | | `--application` | | Application name or id whose pipeline to act on | | `--follow` | `false` | Wait for the step to start if it has not, then keep streaming, reconnecting through transient stream faults, until it concludes | | `--replay` | `false` | Also show the output a running step produced before this command connected (a concluded step's log is always shown whole) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | | `--step` | | Step key to follow (required when the run has more than one step) | ## 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 \ \'. 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. ```bash theme={null} ankra pipeline repositories connect [flags] ``` **Flags** | Flag | Default | Description | | ------------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------- | | `--application` | | Application id to link this repository to (optional; must belong to this organisation) | | `--cluster` | | Cluster id to run this repository's pipelines on, overriding the organisation default (optional; its agent must support pipeline steps) | | `--credential` | | Organisation Git credential used to read the repository; omit to connect without reading the committed pipeline file | | `--default-branch` | | Branch the pipeline file is read from (default: main) | | `--name` | | Repository name | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--owner` | | Repository owner or organisation | | `--provider` | | Repository provider: github, gitlab, or bitbucket | ## 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. ```bash theme={null} ankra pipeline repositories disconnect [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ----------------------------------------------------- | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--yes` | `false` | Skip the confirmation prompt | ## 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. ```bash theme={null} ankra pipeline repositories get [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ----------------------------------------------------- | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | ## ankra pipeline repositories list List the organisation's connected pipeline repositories ```bash theme={null} ankra pipeline repositories list [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | --------------------------------------------------------------------- | | `--cursor` | | Page cursor from a previous listing's next\_cursor | | `--limit` | `0` | Maximum number of repositories to return (server default 50, max 100) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--provider` | | Repository provider: github, gitlab, or bitbucket (filter) | ## 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. ```bash theme={null} ankra pipeline rerun [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ------------------------------------------------------------------------ | | `--application` | | Application name or id whose pipeline to act on | | `--failed-only` | `false` | Re-run only the steps that did not succeed, and whatever depends on them | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | | `--wait` | `false` | Wait for the new run to conclude before returning | ## 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. ```bash theme={null} ankra pipeline run [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ---------------------------------------------------------------------------------- | | `--application` | | Application name or id whose pipeline to act on | | `--input` | `[]` | Dispatch input as key=value (repeatable) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--reason` | | Human note recorded on the run | | `--ref` | | Git reference to run at (defaults to the repository's default branch) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | | `--sha` | | Full commit sha to run (defaults to the working directory's HEAD) | | `--spec-file` | | Run this pipeline definition instead of the stored one (requires pipelines.manage) | | `--wait` | `false` | Wait for the run to conclude before returning | ## ankra pipeline schedules Manage a pipeline's cron schedules ## ankra pipeline schedules create Add a cron schedule ```bash theme={null} ankra pipeline schedules create [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ---------------------------------------------------------------------------- | | `--application` | | Application name or id whose pipeline to act on | | `--cron` | | Cron expression (required) | | `--enabled` | `true` | Whether the schedule fires | | `--input` | `[]` | Dispatch input as key=value (repeatable) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--ref` | | Git reference the schedule runs at (default the repository's default branch) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | | `--timezone` | | IANA timezone the cron is evaluated in (default UTC) | ## ankra pipeline schedules delete Remove a cron schedule ```bash theme={null} ankra pipeline schedules delete [flags] ``` **Flags** | Flag | Default | Description | | --------------- | ------- | ------------------------------------------------------------------------ | | `--application` | | Application name or id whose pipeline to act on | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | | `--yes` | `false` | Skip the confirmation prompt | ## ankra pipeline schedules list List a pipeline's cron schedules ```bash theme={null} ankra pipeline schedules list [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ------------------------------------------------------------------------ | | `--application` | | Application name or id whose pipeline to act on | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | ## 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. ```bash theme={null} ankra pipeline schedules update [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ------------------------------------------------------------------------ | | `--application` | | Application name or id whose pipeline to act on | | `--cron` | | New cron expression | | `--disabled` | `false` | Disable the schedule | | `--enabled` | `false` | Enable the schedule | | `--input` | `[]` | Replace the dispatch inputs entirely, as key=value (repeatable) | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--ref` | | New git reference | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) | | `--timezone` | | New IANA timezone | ## 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. ```bash theme={null} ankra pipeline validate [file] [flags] ``` **Flags** | Flag | Default | Description | | ---------------- | ------- | ------------------------------------------------------------------------ | | `--application` | | Application name or id whose pipeline to act on | | `-o`, `--output` | | Output format: json or yaml (default: human-readable) | | `--repository` | | Pipeline repository id to act on (mutually exclusive with --application) |