ankra application
Connect application source repositories to Ankra for analysis, packaging, and deployment.ankra application add
Add an application by reading a local Git checkout. The command detects the GitHub repository from the selected remote, uses the remote’s default branch when available, and falls back to the current branch. It selects an available GitHub credential automatically when the choice is unambiguous. Without--registry-url the application publishes to the organisation’s own
Ankra registry project, and the command says so on success. Pass it to publish
to a container image registry you already operate instead. Declare it here
rather than afterwards: the setup job generates the build workflow from the
declaration the application is created with, so a registry added later leaves
a workflow that logs in with the wrong one - which is also why, when other
applications in the organisation publish somewhere else, this command names
those registries before the analysis finishes.
ankra application ai-config
Read, set, or reset which AI lanes run on this application’s repository (pull request review, demo URL, and the rest), on which model, and within what limits. An application follows the organisation’s defaults until an override is set here.ankra application ai-config clear
Reset the application to the organisation’s AI defaultsankra application ai-config get
Show the application’s effective AI lane configurationankra application ai-config set
Replace the application’s AI lane configuration with a JSON document. Start from the current one: ‘ankra application ai-config get <id> -o json’, edit it, and pass the file back with--file (or ’-’ to read stdin).
ankra application auto-deploy
Inspect and set whether pushes to the tracked branch deploy themselves. With auto-deploy on, a build Ankra observes on the application’s tracked branch is rolled out to its deployments unattended. With it off, a push still builds - it just waits for an explicit ‘ankra application deploy’.ankra application auto-deploy get
Show whether auto-deploy is on, and the newest build seen on the tracked branch. The newest observed build comes back with the switch so you can tell an auto-deploy that is off from one that is on but has had nothing to pick up.ankra application auto-deploy set
Turn auto-deploy on or off.--enabled is required and must be given explicitly: turning unattended
deployment on and turning it off are both deliberate acts, and neither is a
safe default to infer from a bare ‘set’.
ankra application backup
Back up one of an application’s deployments now. The capture is dispatched by the platform, so the command answers with the restore point in ‘creating’ and the run that will seal it. With--wait it
follows that run to completion.
The deployment is named by the cluster it runs on; Ankra resolves which stack
that is, and the restore point it takes is the same artifact
‘ankra cluster stacks restore-points list’ shows for that stack.
ankra application backups
Show an application’s backup protection, deployment by deployment. One row per cluster the application is deployed to: whether that deployment carries a database, whether its data is protected, when it was last backed up and when it is next scheduled. The verdict has three values and none of them is a boolean: ‘unknown’ means Ankra could not establish whether this deployment is protected, which is not the same answer as ‘unprotected’.ankra application branch-files
List the tracked files on the setup branchankra application branches
List the application repository branchesankra application build
Build an application’s image on Ankra’s builders. Ankra clones the commit, resolves a recipe for it (the repository’s own Dockerfile, else a generated one, else buildpacks), builds it, and pushes the image to the registry the application publishes to - without the repository’s CI running at all. The routes answer 404 for organisations without the platform_builds feature flag, which is off by default while the lane rolls out. Ask Ankra support to enable it for your organisation.ankra application build get
Show one platform build. A failed build carries an error_class saying whose failure it was. build_failed is the repository’s - the recipe did not build - and is the one worth reading the error_message for. clone_auth and recipe_missing are the application’s configuration. push_failed, timeout and capacity are Ankra’s, and are already visible to Ankra without anyone reporting them. build_unknown is Ankra’s too, but not visible the same way: the build ran and failed in a way the builder could not classify, and its error_message - the end of the build’s output - is the only copy of that output, so include it when reporting the failure.ankra application build list
List the application’s platform builds, newest firstankra application build request
Show a queued build request and the build it became. ‘start’ answers with a request id before there is a build to read: the build row is created when the scheduler claims the request. This is how a caller follows the gap - status is pending until it is claimed, and build_id names the build from that point on.ankra application build start
Queue a build of the application’s image.--commit is required and must be a full 40- or 64-character commit sha. An
abbreviation is refused rather than resolved: the queue deduplicates on the
string it is given, so a full sha and its own prefix would be two keys for one
commit and build it twice.
The queue converges on the commit while a request is live. Asking twice joins
one build, and the answer’s already_requested reports that it did.
With --wait the command follows the request through to the finished build and
exits non-zero if the build failed, so a pipeline step can be exactly “build
this commit, and fail if it does not build”.
ankra application chart-versions
List an application’s published chart versionsankra application code-security
Show source code security findingsankra application container-security
Show container image vulnerability findingsankra application credential
Inspect and re-bind the GitHub credential an application’s repository calls ride on. An application is bound to one GitHub credential of the organisation; its App installation must reach the repository for builds, deploys and Actions secrets to work. Move an application onto another credential when its installation lost - or never had - access to the repository.ankra application credential get
Show the GitHub credential an application is bound toankra application credential set
Re-bind an application to another GitHub credential of the organisation. The credential must exist. Whether its App installation reaches the repository is reported in the answer (resolved / message) rather than refused, since a re-bind is usually how an application gets off an installation that cannot.ankra application delete
Delete an applicationankra application demo
Deploy, inspect, and stop short-lived demo workspaces for a branch or pull request of an application.ankra application demo build
Check whether a branch has a demo-ready container imageankra application demo config
Read or update the application’s saved demo defaultsankra application demo config get
Show the saved demo defaults (env, database, migration command, extensions)ankra application demo config rotate-password
Mint a new shared password for every demo of the application that launches behind Ankra’s edge password guard. The password is printed exactly once: Ankra keeps only its bcrypt hash and never shows it again. Running demos keep the previous password until their next redeploy (a pull request push redeploys its preview). Turn protection on first with ‘demo config set--protected’.
ankra application demo config set
Update the application’s saved demo defaults. The command fetches the current configuration first and applies only the flags you set:--env
entries override by name, everything else is carried forward.
ankra application demo deploy
Deploy a short-lived demo workspace for a branch or pull request. All flags are optional; only the flags you set are sent, so the backend applies its own defaults for the rest. A monorepo demo runs every recorded component as its own pod by default.--component narrows that to the components you name, and the per-component
override flags (--component-tag, --component-port, --component-path) tune
one component each. Because selection and overrides ride the same request
field, an override may only name a component that --component selects: to
tune one component of a full launch, list them all.
ankra application demo detail
Show a demo workspace’s record, its components, provisioning steps, and failure detail. The default rendering summarises the demo; -o json or -o yaml emit the full payload, including the resource inventory and the Kubernetes events behind a stalled step.ankra application demo fix
Dispatch the AI pre-setup mission for a failed demoankra application demo fix-build
Fix a branch that has no demo-ready container image. This is what to run when ‘demo build’ reports that no image exists for a branch. Ankra applies its own deterministic fixes first (publish-readiness auto-fix, failed-run rerun, failed-setup retry) and, when those cannot produce an image, dispatches a one-shot mission agent that investigates the repository and opens a pull request with the fix. The answer points at the dispatched mission rather than carrying its result, so follow the agent run it names.ankra application demo list
List the application’s active demo workspaces, one row each, with the components every demo runs. -o json or -o yaml emit the full payload, including the TTL policy and the staging cluster’s status.ankra application demo logs
Fetch a bounded tail of the demo container’s logs. One-shot: the command returns after the fetch instead of following the stream. A multi-component demo runs one pod per component, and without a selector the backend reads whichever pod it finds first.--component picks the pod
belonging to that component; --pod addresses one by name (from
ankra application demo detail) when a component has more than one.
ankra application demo stop
Stop and tear down a demo workspaceankra application deploy
Deploy a packaged application to a target cluster. The cluster is identified by ID. Use--set key=value (repeatable) to pass
deploy inputs declared by the application’s chart.
ankra application deployments
List an application’s cluster deploymentsankra application env-secrets
Manage the environment secrets an application’s manifests read. The keys come from the application’s generated manifests. Setting a value stores it; it is sealed into a running deployment only when you apply it, so a set followed by no apply changes nothing about the workload. Values never travel outbound: ‘list’ reports which keys exist and whether each has a value, never the value itself.ankra application env-secrets apply
Seal the stored environment secrets into the running deployments. Re-seals the values Ankra already holds into every deployment of the application and rolls the workloads that read them. It sends nothing: the values applied are the ones already stored. The endpoint answers 409 when the request does not apply to this application’s state - nothing set, not deployed yet, tearing down, or a deployment that cannot be sealed - and the reason is reported as the error message.ankra application env-secrets delete
Clear the stored value of one environment secret. The key stays declared by the application’s manifests; only the value Ankra holds for it is removed. Deployments already running keep the value that was sealed into them until the next apply.ankra application env-secrets list
List the environment secret keys an application needs, and their state. Reports the keys the application’s generated manifests declare and whether each one has a stored value. The values themselves are never returned.ankra application env-secrets set
Store the value of one environment secret. Pass the value with--value, pipe it on stdin, or omit both to be prompted for
it without echo. Prefer stdin or the prompt: a --value on the command line is
recorded in your shell history and, on a shared host, in the process table.
Storing a value does not reach a running workload. Run ‘env-secrets apply’ to
seal the stored values into the application’s deployments and roll them.
ankra application files
Commit changes to the application’s setup pull request. Each--file maps a repository path to a local file whose contents are
uploaded. Use --delete to remove a tracked path.
ankra application get
Show an application’s detailankra application import
Import an application from a source that has no Git repository of its own. Ankra converts what you give it, creates a GitHub repository for it, commits the result and registers the application, so the same setup pull request, build and deploy lane that follows every registration takes over.ankra application import claude-design
Turn a Claude Design export into a deployable application. <path> is what you exported from claude.ai/design: a directory holding the artboards (<Name>.dc.html), canvas.json and images, a zip of them, a single artboard, or a saved canvas page (.html). Ankra converts the artboards into a static site, creates a GitHub repository under the credential’s account (or--owner), commits the site with a Dockerfile, and registers the application.
Artboards that depend on the Claude Design runtime - template holes, sc-for,
sc-if, dc-import or a data-dc-script - are kept as authored and reported as
warnings; they may not render as they did on the canvas.
Running the same import again is safe: the repository keeps a provenance
record, and an unchanged export registers without a second commit.
The lane ships behind the claude_design_import organisation feature flag,
which is off by default while it rolls out: the platform answers 404 for
organisations without it, and this command says so. Ask Ankra support to
enable it for your organisation.
ankra application installations
List an application’s installation intentsankra application jobs
List an application’s platform jobsankra application list
List applicationsankra application manifest-addon
Inspect, install and withdraw add-ons published from an application’s manifests. Publish one with ‘ankra application publish-addon <application-id>’ and find its id with ‘ankra application published-addon <application-id>’. These commands take that add-on id, not an application id.ankra application manifest-addon delete
Delete a manifest add-on and undeploy every installation of it. This is the most consequential of the three and the least reversible: it does not only withdraw the catalog entry, it undeploys the workloads installed from it on every cluster. Use ‘unpublish’ to withdraw the entry and leave those running.ankra application manifest-addon diff
Compare two published versions of a manifest add-on.--to names the version to compare; --from names what to compare it against,
defaulting to the version published before it. --path narrows the comparison to
the named manifests and may be repeated.
ankra application manifest-addon get
Show a published manifest add-on: its catalog entry, published versions, and what it declares.ankra application manifest-addon install
Install a published manifest add-on onto a cluster.--cluster-id is required. --namespace and --version default from the add-on’s
own descriptor. --input answers an input the published manifests declare and
may be repeated as --input key=value.
ankra application manifest-addon unpublish
Withdraw a manifest add-on from the catalog, leaving installations running. Nobody can install it again afterwards. What is already installed from it keeps running - use ‘delete’ if you want those undeployed too.ankra application pipeline
Manage the application’s pipelineankra application pipeline artifacts
List a pipeline run’s stored artifactsankra application pipeline artifacts download
Download a stored artifactankra application pipeline cancel
Cancel a pipeline run that has not concluded. A run that had started stops its main and on_failure stages, then runs its finally stages before it concludes cancelled. While they run the run reads “running” and “cancelling”. A run that never started concludes at once.--force skips the finally stages: the run concludes cancelled at once. On a
run that is already cancelling it stops the finally stages still running.
Cancelling such a run again without --force is refused.
ankra application pipeline convert
Convert an application that still builds from a GitHub Actions workflow onto Ankra Pipelines, with one call. Ankra reads the workflow, converts it to a .ankra/pipeline.yaml, stores that as the application’s pipeline definition of record and builds the next push through it. It switches the generated workflow off on GitHub so the two never build the same commit twice, and opens a pull request that commits the pipeline file and removes Ankra’s generated workflow file. A workflow the repository wrote itself is never touched. Nothing about building waits on the pull request merging.--keep-workflows leaves the generated workflow file in the repository (it stays
switched off). Calling again while the pull request is still open answers the
same conversion; an application already on Ankra Pipelines is refused with
nothing to convert.
ankra application pipeline definition
Manage the application pipeline’s definition of recordankra application pipeline definition get
Show the pipeline definition of recordankra application pipeline definition put
Store a pipeline definition as the definition of recordankra application pipeline get
Show a pipeline run’s detail - or wait for it to conclude, or watch it. Name the run by its id, or select it by what you know about it. Push and pull request runs are started by the webhook, so a CI job or an agent usually knows the commit rather than the run id:--head-sha, --branch and --trigger narrow
the pipeline’s runs the way ‘pipeline list’ filters them. Exactly one match is
that run; when several match, --latest takes the newest, and without it the
command lists them instead of guessing. --latest on its own is the pipeline’s
newest run.
--wait blocks until the run concludes, then prints its final detail. --watch
prints every state change of the run and of each of its steps as it is seen,
until the run concludes; with -o json each change is one JSON object on its
own line, carrying the run or step as the platform answered it. --timeout
bounds either one; without it they wait as long as the run takes. When a
selection matches no run yet, --wait and --watch wait for one to appear - the
webhook that creates it can land a moment after you ask - for up to
--timeout, or ten minutes when no --timeout is set.
Exit codes: 0 when the run succeeded; 1 when it concluded any other way, or
the platform could not be read; 2 when a selection matches several runs and
--latest was not given; 3 when nothing matches; 5 when --timeout ran out or,
with --exit-code, when the run has not concluded yet. Without --wait, --watch
or --exit-code the command exits 0 whatever the run’s outcome, as it always
has.
Status and outcome (-o json): ‘status’ is the lifecycle, never the verdict.
A run’s status is queued, running or concluded; a step’s is blocked (waiting
on its dependencies), pending (ready, not yet claimed), running or concluded.
How the work ended is the separate ‘outcome’ field, which is null until the
status is concluded and then always one of: success, failure (the work
itself failed), cancelled, timed_out, skipped (it never ran - a dependency
did not succeed, a condition or the trigger filter excluded it) or
infra_error (Ankra failed, not the work). The same two fields with the same
vocabulary sit on the run and on each step, mirroring GitHub Actions’
status/conclusion split - so a monitor that filters on status finds every
finished run under concluded, and must read outcome for whether it passed.
The human-readable Status line and STATUS column print the outcome once
there is one and the status until then, with a glyph that says which:
✓ success, ✗ failure / timed_out / infra_error, ⊘ cancelled, ○ skipped, and
⟳ only for a run or step that has not concluded (○ for a blocked step).
Superseded runs: a run cancelled because a NEWER run took its concurrency
group reads ‘superseded’ rather than ‘cancelled’ - on the Status line, in
the STATUS column, on the last line of --watch and in the conclusion --wait
reports - and ‘pipeline get’ names the run that took its place. Nobody
stopped that run, and the run worth looking at is the newer one. Only the
word differs: --wait, --watch and --exit-code exit 1 for a superseded run as
for any cancelled one. In -o json the fields are ‘error_class’
(“superseded”), ‘superseded_by_run_id’ and ‘superseded_by_run_number’;
‘outcome’ stays “cancelled”, so a script filtering on outcome alone still
finds these runs and must read the class to tell them from a run somebody
cancelled.
Cancelled runs (-o json ‘cancelled_by’, ‘cancel_reason’, ‘cancelled_at’;
the Cancelled line): who stopped a run, why and when. ‘cancelled_by’ is the actor
in the same form ‘requested_by’ uses - “user:<id>” for a cancel pressed in
the portal, the CLI or the API, “github:<login>” for the Cancel action on a
pull request’s check run, “concurrency:<run id>” for a supersession,
“merge_train:<entry id>” for the merge train - and ‘cancel_reason’ is one of:
ankra application pipeline list
List the application’s pipeline runsankra application pipeline logs
Show a pipeline step’s outputankra application 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. The new run is recorded with trigger ‘rerun’, and ‘rerun_of_run_id’ ties the two together. A re-run repeats the original event. A re-run of a push run is planned as a push, so its push-only stages run. A re-run of a pull request run (or of a merge train car) is planned as a pull request, and a re-run of a schedule run as that schedule. A re-run of a tag run or of a manual or API dispatch is planned as a plain re-run, so stages limited to other events are skipped. A re-run’s publish pushes the sha- image, but that image does not become the push-to-deploy candidate, so a re-run does not roll the deployment.--failed-only restricts the new run to the steps that failed, the steps that
were skipped because of a failure, whatever depends on them, and the steps
they build on. The new run starts from an empty workspace, so the checkout and
every upstream step whose output a repeated step reads run again with it;
steps that succeeded and that nothing repeated needs do not. A failed-only
re-run that would still skip one of those steps (for example a tag-only
release behind a failed build, on a re-run of a tag run) is refused with the
reason rather than passing without it.
--full sets the pipeline’s path filters aside for the new run, so every stage
whose filters left it out runs, and the run records that you asked. A re-run
of a run that was already a full run is one again without the flag.
ankra application pipeline run
Dispatch a manual run of the application’s pipelineankra application pipeline schedules
Manage the application pipeline’s cron schedulesankra application pipeline schedules create
Add a cron scheduleankra application pipeline schedules delete
Remove a cron scheduleankra application pipeline schedules list
List the pipeline’s cron schedulesankra application pipeline schedules update
Change a cron scheduleankra application pipeline validate
Dry-run a pipeline definition without writing anythingankra application platform
Detect platform operators already present on a target clusterankra application protect
Protecting a deployment writes its whole backup policy: the vault, the schedule, the retention and which volumes are carried. Running it again replaces the policy that is there, so restate--schedule, --retention and
--include-pvc when they must survive; anything omitted takes the default,
not the previous value.
Turn scheduled backups on for one of an application’s deployments.
The deployment is named by the cluster it runs on; Ankra resolves which stack
that is. Without --vault the organisation’s single verified backup vault is
used, and an organisation with more than one is refused rather than chosen
for - where a restore point lives is not a decision to make on somebody’s
behalf.
ankra application publish-addon
Publish the application’s generated manifests to the organisation catalogue as a manifest add-on. Publishing again with a new--version adds
a version; other clusters install the add-on from the catalogue.
ankra application publish-readiness
Report whether the repository can publish to the private Ankra registryankra application published-addon
Show the add-on this application published to the catalogueankra application pull-request-reviews
Show the AI reviews of the application’s pull requestsankra application reconcile
Request an application refreshankra application registry
Inspect and set the container image registry an application publishes to. An application with no declaration publishes into the organisation’s own Ankra registry project. Declare a registry you already operate to have Ankra read image tags, verify builds, and pull demo images from there instead.ankra application registry clear
Return an application to the organisation’s own Ankra registry. Clears the declaration, so the application publishes into - and is read back from - the organisation’s provisioned registry project again.ankra application registry get
Show the image registry an application publishes to. Reports the stored declaration, whether it is one at all, the host and project it resolves to, and the image repository each component is expected to publish to - so you can compare them against where your builds actually push.ankra application registry robot
Manage the registry robot account minted for an application. Ankra mints one push robot per application on the registry it publishes to, stores it as a managed registry credential, and writes it into the repository’s Actions secrets as the login the build workflow uses. On the organisation’s own Ankra registry that happens automatically; on a registry you operate it needs the declaration to name a credential with project administrator rights (ankra application registry set--admin-credential).
ankra application registry robot ensure
Mint the application’s registry robot if it has none, and store its login in the repository’s Actions secrets. An application that already has a robot keeps it; only its login is re-written into the repository. A registry Ankra may not administer answers with provisioned false and a message naming what would let it.ankra application registry robot get
Show the registry robot account minted for an application. Reports whether a robot backs the application’s registry login, its name, the registry it lives on, when it was created and last rotated - and when none does, why, and what would let Ankra mint one. Never contacts the registry.ankra application registry robot revoke
Delete the application’s registry robot from the registry and drop the credential holding its login. The repository’s Actions secrets are left holding a login that no longer works, which is the point of a revoke; run ‘ensure’ afterwards to mint a fresh robot and store it. Prefer ‘rotate’ when the application should keep working.ankra application registry robot rotate
Rotate the application’s registry robot secret and store the new login in the repository’s Actions secrets. The previous secret stops working the moment the registry answers, which makes this the response to a leaked repository secret. A build that starts before the new login is stored fails at the registry login; re-run it afterwards. An application with no robot yet gets one minted.ankra application registry set
Point an application at a container image registry you operate.--url is the registry project, as oci://<host>/<project> (the scheme is
optional). --credential names an existing registry credential of this
organisation; without one Ankra can describe where the images live but cannot
read or pull them, so builds keep reporting as never published.
Ankra never mints robots for a registry it was not handed the keys to. Name a
credential with project administrator rights as --admin-credential to have
Ankra mint, rotate and revoke a push robot for the application there and
store it in the repository’s Actions secrets; without one it leaves the
secrets to you unless you ask it to write the declared credential with
--manage-actions-secrets.
With --admin-credential Ankra also checks that the project exists before it
accepts the declaration. A project the registry does not have is created with
that credential - private, or public with --project-public - when the
credential may create projects; otherwise the declaration is refused with the
project and host named, instead of being accepted for every later build to
fail against. Without --admin-credential the project is not checked.
ankra application remove
Remove an application from one cluster, leaving the application and its other deployments in place. Ankra uninstalls the application’s workloads in that cluster and namespace - and with them any data in that deployment’s database and volumes - and deletes the installation once the cluster has it. The application, its settings, secrets, images and release history, and its deployments on other clusters stay, so you can deploy it there again. An application deployed with the deploy wizard has no installation: it runs as a stack. Name that stack with--stack and Ankra removes it from the cluster.
The other stacks that deploy created stay, and the command lists them.
The removal runs in the background: ‘ankra application installations’ shows the
deployment as “removing” until it is gone, or “failed” with the reason. A
stack’s removal is a platform job: ‘ankra application jobs’ shows its
undeploy_application job, “success” once the stack is gone or “failed” with
the reason.
To stop it for a while without losing anything, park it instead. To delete the
application everywhere, use ‘ankra application delete’.
ankra application rerun-workflow
Re-trigger a failed workflow runankra application retry
Re-trigger a failed application’s setupankra application security-versions
List the tags the application has published, joined to the bill of materials and vulnerability findings the platform holds for each, and the clusters running it now. A tag with no report reads “not scanned”, which is not the same as clean, and a registry the platform could not list reads unavailable rather than empty. The licence verdict at the end says whether a private repository links a component whose licence obliges publishing the source (AGPL, SSPL and the other network copyleft licences) or a commercial licence to host as a service.--component narrows a monorepo to one image.
ankra application settings
Inspect and set the organisation’s application CI settings. These apply to every application in the organisation, not to one of them. The CI runner label decides which GitHub Actions runner the pipelines Ankra generates request - change it when GitHub-hosted runners are unavailable to you and your builds run on self-hosted ones.ankra application settings get
Show the organisation’s application CI settings. Readable by any member: a member who cannot explain why a build never started is the reason this setting exists.ankra application settings set
Set or clear the GitHub Actions runner label generated pipelines run on. Pass--ci-runner-label to choose the label, or --clear to drop the
organisation’s choice and put every future generation back on the default.
Existing pipelines are not rewritten by either.
Only organisation admins may change this.
ankra application ship
Take a local checkout to a live deployment in one command. Ship composes the existing application lanes: it registers the repository as an application when the organisation does not have it yet (with exactly the ‘application add’ flags), waits for the setup analysis, waits for a green image build of the tracked branch, deploys to the target cluster, and follows the installation until the workload is running - then prints the published URL when one exists. The URL is printed as Live only once the Ingress that carries it is shown to route: every backend Service it names exists, exposes the port asked for and has a ready endpoint. A backend that does not resolve fails ship with what is wrong (state “unroutable” in -o json, with url_problem); a route ship cannot read is reported and left unverified. An existing application is reused only when it is registered for the same repository AND tracks the requested branch (--branch, else the checkout’s
branch); ship never builds or deploys a branch other than the one requested.
When the repository’s applications all track other branches, ship stops and
names them: pass --name <app> --branch <its branch> to ship one of them, or
--name <new-name> to register a separate application for the branch. --name
selects among several applications on the same branch.
The build it waits for is the one that actually builds the application:
- Ankra Pipelines (the default for new applications): the pipeline run for the tracked branch’s head commit, until its publish steps succeed. When no run for that commit appears within a minute - nothing has been pushed since the application was registered - ship starts the branch’s push run for it, the run a push would have started, which publishes the image. That needs the applications.deploy permission. A push during the wait moves ship on to the new head commit. A run whose publish step is skipped stops ship and asks for a push. A run the pipeline skipped outright - no trigger it declares accepts the push, typically because the setup pull request that adds .ankra/pipeline.yaml is not merged yet - stops ship with the pull request to merge, or the trigger the branch needs.
- The repository’s own GitHub Actions workflow: its latest run on the tracked branch.
- The workflow Ankra generated: its latest run on the tracked branch, once you have merged the setup pull request that adds it. Only this lane waits on the merge.
--ankra-build the first image is built on Ankra’s builders from the head
commit of the tracked branch, so ship does not wait for the setup pull
request to merge or for the repository’s own CI. The platform-build routes
answer 404 for organisations without the platform_builds feature flag.
The image tag and ingress publication are the platform’s defaults: the latest
green build is deployed, and ingress is derived server-side. Pass --set only
for deploy inputs you want to pin.