From 0324ea045b518d6ab2d9348d181c3b2dd7c823db Mon Sep 17 00:00:00 2001 From: PedroGuerraPT <5890852+PedroGuerraPT@users.noreply.github.com> Date: Tue, 25 Aug 2026 17:40:13 +0000 Subject: [PATCH] Update docs content from https://github.com/depot/app --- content/ci/how-to-guides/coding-agents.mdx | 18 +- content/ci/how-to-guides/custom-images.mdx | 4 + .../ci/how-to-guides/manage-workflow-runs.mdx | 10 +- content/ci/integrations/origin.mdx | 191 ++++++++++++++++++ .../observability/datadog-ci-visibility.mdx | 2 +- content/ci/observability/depot-ci-metrics.mdx | 8 + content/ci/oidc.mdx | 34 +++- content/ci/overview.mdx | 19 +- content/cli/reference/container-builds.mdx | 66 ++++++ content/cli/reference/depot-ci.mdx | 83 ++++---- .../how-to-guides/autoscaling.mdx | 36 ++-- .../how-to-guides/egress-filtering.mdx | 2 +- content/managed/on-aws.mdx | 2 +- content/registry/overview.mdx | 49 +++-- content/registry/pull-through-cache.mdx | 5 +- 15 files changed, 438 insertions(+), 91 deletions(-) create mode 100644 content/ci/integrations/origin.mdx diff --git a/content/ci/how-to-guides/coding-agents.mdx b/content/ci/how-to-guides/coding-agents.mdx index 915a8f4..163d257 100644 --- a/content/ci/how-to-guides/coding-agents.mdx +++ b/content/ci/how-to-guides/coding-agents.mdx @@ -15,11 +15,11 @@ You're working with an agent on a task, and you want to make sure CI passes befo No human needs to approve each step. You tell the agent to fix CI, and the agent iterates until it's done. ![Agent fix-CI loop: tell agent to fix CI, agent triggers run scoped to - smallest job, checks status, reads logs from failed jobs, SSHs into runner if - logs aren't enough, fixes code, reruns until CI + smallest job, checks status, reads diagnosis and logs from failed jobs, SSHs + into runner if logs aren't enough, fixes code, reruns until CI passes](/images/docs/agent-loop.png) -For a raw narrative version of this pattern, see the blog post [The End of push-wait-guess CI](/blog/the-end-of-push-wait-guess-ci). +For a raw narrative version of this pattern, see the blog post [The End of push-wait-guess CI](/blog/the-end-of-push-wait-guess-ci). The guide you're reading right now includes updates to the available commands for agents that the linked post doesn't mention. ## Why the CLI works well for agents @@ -28,6 +28,7 @@ Most coding agents already have a shell. The Depot CLI gives them CI without any - `depot ci run` starts a run against your local working tree. Use `--job` to scope to specific jobs for faster iteration. The CLI resolves job dependencies automatically. - `depot ci status` shows the full run hierarchy, workflows, jobs, and attempts with their statuses. - `depot ci logs` fetches the log output for a failed job so the agent can read the error and fix it. +- `depot ci diagnose` groups the failures for a run, workflow, job, or attempt and returns a diagnosis, a possible fix, and the evidence lines behind them. With `--output json`, the agent gets a bounded payload plus `next_commands` for drilling into a narrower target, instead of parsing raw logs. The diagnosis is AI-generated, so always verify suggested fixes. - `depot ci ssh` connects directly to a running sandbox via the Depot API, giving you (or the agent) an interactive shell on the sandbox. To keep a sandbox alive at the right moment, use `depot ci run --ssh-after-step ` to inject a tmate debug pause after a specific step, then connect with `depot ci ssh` or the tmate connection string from the logs. If your agent or tooling integrates over HTTP instead of a shell, the [Depot CI API](/docs/api/ci/reference) exposes the same operations: dispatching workflows, checking run status, fetching logs and metrics, and retrying jobs. @@ -75,10 +76,11 @@ If the request is ambiguous, ask for the narrowest useful target. ### The Loop 1. **Run** the workflow against local changes, scoped to the smallest useful job. -2. **Check status** and **read logs** for failed jobs. -3. If logs aren't enough, connect to the running sandbox with **`depot ci ssh`**, or **rerun with `--ssh-after-step`** to pause at a specific step first. -4. **Fix locally** based on what you found. -5. **Rerun.** Repeat until green. +2. **Check status**, then **read the diagnosis** for any failed jobs using `depot ci diagnose` pointed at a failed job or attempt. The command groups similar failures and returns each group's error message, a possible fix, and the evidence lines behind them. It reports "No CI failures found for this target" when there's no stored failure evidence. Verify anything it suggests against the logs before acting on it. +3. **Read logs** for the failed jobs when the diagnosis isn't specific enough. +4. If logs aren't enough, connect to the running sandbox with **`depot ci ssh`**, or **rerun with `--ssh-after-step`** to pause at a specific step first. +5. **Fix locally** based on what you found. +6. **Rerun.** Repeat until green. ### Autonomy @@ -136,7 +138,7 @@ Cap the number of CI attempts so the agent doesn't loop forever on a fundamental ### Log truncation -CI logs can be long. If your agent has a limited context window, truncate logs to the last N lines or extract just the error output. Most failures surface near the end of the log. +CI logs can be long. If your agent has a limited context window, truncate logs to the last N lines or extract just the error output. Most failures surface near the end of the log. You can also start with `depot ci diagnose --output json`, which returns bounded failure context (capped groups, representative attempts, and evidence lines) rather than the full log, and use `depot ci logs` only when the agent needs more. ### Polling diff --git a/content/ci/how-to-guides/custom-images.mdx b/content/ci/how-to-guides/custom-images.mdx index b7c9ded..2642134 100644 --- a/content/ci/how-to-guides/custom-images.mdx +++ b/content/ci/how-to-guides/custom-images.mdx @@ -185,6 +185,10 @@ jobs: ## Best practices +**Snapshot slow-to-install software**: Include software that is slow to install, such as system packages, browser binaries, and language toolchains, in your snapshot. Installing Chrome for Playwright tests and MySQL from apt are good candidates. A package directory can easily be cached, but the system changes an installer makes cannot. + +**Pre-pull container images**: Run `docker pull` in the `snapshot` job to include those layers in the custom image, so jobs using service containers or `docker compose` start without pulling from a registry. Containers still need to start and pass their health checks, as normal. + **Set `clean: false` when pre-cloning a repository**: If your custom image includes a pre-cloned copy of your repository, set `clean: false` on `actions/checkout` so it skips running `git clean -ffdx` before fetching. Without `clean: false`, checkout removes untracked files from the pre-cloned repo (like installed dependencies or build artifacts), negating the benefit of pre-cloning. ```yaml diff --git a/content/ci/how-to-guides/manage-workflow-runs.mdx b/content/ci/how-to-guides/manage-workflow-runs.mdx index df1bbe5..4c81c50 100644 --- a/content/ci/how-to-guides/manage-workflow-runs.mdx +++ b/content/ci/how-to-guides/manage-workflow-runs.mdx @@ -97,13 +97,21 @@ The `--status` flag is repeatable and accepts `queued`, `running`, `finished`, ` You can also filter by `--repo`, `--sha`, `--trigger`, and `--pr` (requires `--repo`), limit results with `-n` (default 50), and get structured output with `--output json`. +To list workflows rather than runs, use `depot ci workflow list`. It takes the same filters plus `--name`: + +```shell +depot ci workflow list --name deploy --status failed +``` + To check a run's workflows, jobs, and attempt IDs, use `depot ci status`: ```shell depot ci status ``` -For usage, see the [`depot ci run list`](/docs/cli/reference/depot-ci#depot-ci-run-list) and [`depot ci status`](/docs/cli/reference/depot-ci#depot-ci-status) docs, or run `depot ci run list --help` and `depot ci status --help`. +For a single run's metadata, use `depot ci run show `. For one workflow's jobs and per-job attempts, use `depot ci workflow show `. + +For usage, see the [`depot ci run list`](/docs/cli/reference/depot-ci#depot-ci-run-list), [`depot ci workflow list`](/docs/cli/reference/depot-ci#depot-ci-workflow-list), and [`depot ci status`](/docs/cli/reference/depot-ci#depot-ci-status) docs, or run `depot ci run list --help` and `depot ci status --help`. ## Retry failed jobs diff --git a/content/ci/integrations/origin.mdx b/content/ci/integrations/origin.mdx new file mode 100644 index 0000000..9ddd039 --- /dev/null +++ b/content/ci/integrations/origin.mdx @@ -0,0 +1,191 @@ +--- +title: Origin +ogTitle: Run Depot CI on Origin repositories +description: Connect Depot CI to an Origin namespace to run your existing GitHub Actions workflows on Depot compute, triggered by Origin pushes and pull requests. +--- + +import {NoteCallout} from '~/components/blog/NoteCallout' + + + [Origin](https://cursor.com/docs/origin) and the Depot integration are in early beta. Functionality and documentation + might change. If you have suggestions to make this integration better, [reach out](/help) and let us know. + + +Connect Depot to an [Origin](https://cursor.com/docs/origin) namespace to run CI on Depot instead of GitHub. Your existing GitHub Actions workflows keep working: [Depot CI](/docs/ci/overview) reads GitHub Actions workflow syntax, and Depot supplies the orchestrator, the compute, and the cache. + +## Which repositories trigger from Origin + +Depot CI starts a run when a forge sends it an event, such as a push or a pull request. Origin sends events for native Origin repositories only. When a repository still syncs with GitHub, Origin treats GitHub as the source of truth and doesn't send events for it. Synced repositories trigger Depot CI from GitHub instead. See [Repositories that sync with GitHub](#repositories-that-sync-with-github). + +One Depot organization can hold an Origin connection and a GitHub connection at the same time. Your native Origin repositories trigger from Origin, and your synced repositories trigger from GitHub. + +## How Origin and Depot CI work together + +- **Runs triggered by Origin events**: pushes and pull requests in native Origin repositories start Depot CI runs. Depot receives the events from Origin directly, so there's no webhook to configure. +- **Status checks on the pull request**: job results appear in Origin, inline with your pull requests. Add branch protection rules to require passing CI before a merge. +- **Automatic workflow migration**: `depot ci migrate workflows` converts `.github/workflows/` into `.depot/workflows/` and applies Depot CI compatibility fixes. +- **Origin compatibility analysis**: with `--forge=origin`, migration reports actions that fail or degrade because Origin doesn't expose a GitHub API they need. See [Origin compatibility findings](#origin-compatibility-findings). +- **Secrets and variables import**: `depot ci migrate secrets-and-vars` imports the secrets and variables your workflows reference, so you don't re-enter them by hand. +- **Everything else Depot CI does**: logs, CPU and memory [metrics](/docs/ci/observability/depot-ci-metrics), [SSH into a job](/docs/ci/how-to-guides/debug-with-ssh), [step retries](/docs/ci/how-to-guides/retry-steps), [custom runner images](/docs/ci/how-to-guides/custom-images), and an [API](/docs/api/ci/reference) and [CLI](/docs/cli/reference/depot-ci) so agents can start runs and read results without a git event. + +## Requirements + +- A Cursor Pro, Teams, or Enterprise plan with Origin access. +- A native Origin repository (if you want to trigger runs from Origin). The Depot app in Origin can't see a repository that still syncs with GitHub. To run CI on a synced repository, see [Repositories that sync with GitHub](#repositories-that-sync-with-github). +- Ownership of the Depot organization you connect. +- An authenticated Depot CLI session. + +## Create an Origin repository + +From [cursor.com/codebase](https://cursor.com/codebase), click **New repo** or **+ New**, then follow the steps. + +## Connect Depot from Origin + +1. In Origin, open the [Depot app](https://cursor.com/codebase/settings/apps/depot). +2. Review the requested permissions and install the app. +3. Origin redirects you to Depot. Create a Depot account, or sign in. +4. Choose the Depot organization to connect, or create a new one. + +Depot then opens the Depot CI page in your dashboard, ready for your first run. + +Organization owners can also start from the Depot side. In your [organization settings](/orgs/_/settings), under **Origin**, click **Connect to Origin**. Depot redirects you to Origin to confirm the installation. + +## Repositories that sync with GitHub + +A repository that still syncs with GitHub doesn't send Origin events, so an Origin connection alone can't start its runs. You can connect to GitHub from Depot to trigger those runs from GitHub. + +You still push and pull through Origin. Origin syncs the ref to GitHub, GitHub sends the event, and Depot CI starts the run. Job results appear in GitHub. + +For Origin repositories that sync with GitHub, follow the [Depot CI quickstart](/docs/ci/quickstart). For native Origin repositories, follow the steps in this guide. + +## Migrate your workflows + +### What the migrate command does + +The `depot ci migrate` command: + +1. Validates authentication and checks the repo connections according on the specified `--forge` flag. +2. Discovers all workflow files in `.github/workflows/`. +3. Prompts you to select which workflows to migrate. +4. Copies selected workflows to `.depot/workflows/` and any local actions to `.depot/actions/`, applies compatibility fixes, and adds inline comments for any changes. + +`--forge` names the forge that hosts the repository and sends events to Depot CI. This value determines what the `depot ci migrate` command does. + +| Repository | Flag | CLI behavior | +| ----------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Native Origin | `--forge=origin` | Looks for an `origin.cursor.com` remote, confirms Origin exposes the repository to your Depot organization, and runs the Origin compatibility analysis. | +| Syncs with GitHub | `--forge=github` (default) | Looks for a `github.com` remote and confirms the Depot Code Access app is installed. | + +For the full command reference, see [`depot ci migrate`](/docs/cli/reference/depot-ci#depot-ci-migrate). + +### Run the migration + +Run these steps from a checkout of the repository you connected. + +1. Install the [Depot CLI](/docs/cli/installation). +2. Run `depot login` and select the organization you connected to Origin. +3. From the repository root, run `depot ci migrate --forge=origin`. + + The command output lists the workflows with triggers Depot CI supports, asks whether to migrate the rest, and writes converted copies into `.depot/workflows/`. Anything it can't translate cleanly becomes a disabled job for you to review. The command also reports [compatibility findings](#origin-compatibility-findings). + +4. Run `depot ci migrate secrets-and-vars --forge=origin`. It commits a one-shot import workflow to a temporary branch and prints a `git push` command. Push the branch within five minutes. The workflow runs once and imports the values into Depot CI. +5. Commit `.depot/workflows/` and merge it into your default branch to activate the workflows. + +## Origin compatibility findings + +Compatibility findings apply to native Origin repositories. A repository that triggers from GitHub reaches the GitHub APIs as usual, so its migration reports no findings. + +Some GitHub Actions workflows use actions that depend on something Origin has no equivalent for. When you specify `origin` as the forge during migration, Depot checks the workflows you selected and reports on Origin compatibility. + +The check reads your local `.github/workflows/*.yml` and `*.yaml` files before Depot copies them, so findings cover the files you're about to migrate, including uncommitted edits. You don't need to push anything first. + +Regardless of findings, Depot writes the selected workflows to `.depot/workflows/`. A finding tells you what to change, but doesn't block the migration. + +Compatible actions produce no findings. If all of your workflows are compatible, then the CLI omits the compatibility output. + +### Severities + +| Label | Meaning | +| --------------------------- | ------------------------------------------------------------------------------------------------------------------- | +| `FAILS` | The affected mode needs a capability Origin doesn't provide, so that operation fails. | +| `SILENT DEGRADATION` | The workflow continues and can look successful, but the intended result is never published or completed. | +| `CONDITIONALLY UNSUPPORTED` | Runtime inputs, events, or configuration decide whether the unsupported operation runs, so not every run will fail. | + +A label describes the action mode, not the migration command. + +### Reading the output + +A single workflow step can produce more than one finding. Depot reports each unsupported behavior in a separate finding block. Findings are advisory only. A `FAILS` finding doesn't stop the migration. The following example shows what the findings output looks like: + +```text +Origin compatibility findings: + + FAILS — .depot/workflows/ci.yml (from .github/workflows/ci.yml) + Job: release + Step: Publish release + Action: softprops/action-gh-release + Mode: publish-release + Missing capability: github-releases + Explanation: Origin does not provide GitHub release or release-asset APIs. + Workaround: Publish releases from a GitHub workflow or use another release destination. + + SILENT DEGRADATION — .depot/workflows/ci.yml (from .github/workflows/ci.yml) + Job: scan + Step: Publish dependency snapshot + Action: aquasecurity/trivy-action + Mode: dependency-snapshot + Missing capability: dependency-snapshots + Explanation: Trivy GitHub format sends the Origin token to the public GitHub dependency snapshot API and does not fail when publication is rejected. + Workaround: Use another Trivy output format or publish the dependency snapshot from a GitHub workflow. + + CONDITIONALLY UNSUPPORTED — .depot/workflows/ci.yml (from .github/workflows/ci.yml) + Job: codeql + Step: Analyze + Action: github/codeql-action/analyze + Mode: upload-analysis + Missing capability: code-scanning-sarif + Explanation: Origin does not provide GitHub code-scanning or SARIF upload APIs. + Workaround: Set upload to never or run CodeQL analysis on GitHub. +``` + +#### Findings fields + +| Field | Description | +| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Workflow heading | The migrated destination and the original source. | +| `Job` | The job that contains the affected step. | +| `Step` | The step name, when the workflow gives one. | +| `Action` | The affected action. | +| `Mode` | The behavior or configuration being reported. An action can work in one mode and fail in another, which is why a finding names a mode and not just an action. | +| `Missing capability` | The forge capability that mode requires. | +| `Explanation` | Why the behavior is affected on Origin. | +| `Workaround` | An alternative, when one exists. When no workaround exists, the output omits this field. | + +## See your first run + +Open the [Depot CI page](/orgs/_/workflows) in your dashboard, or list runs from the CLI: + +```bash +depot ci run list +depot ci status +``` + +## Troubleshooting + +**Authentication fails.** You need an authenticated session with a Depot user token or organization token. Run `depot login`, set `DEPOT_TOKEN`, or pass `--token`. + +**No organization is selected.** A user token needs an active organization. Select one with `depot org switch`, or pass `--org`. + +**Depot can't find the repository.** You see: + +```text +could not detect an Origin repository from git remotes — configure a remote pointing to origin.cursor.com/namespace/repo +``` + +Run `depot ci migrate` and its subcommands from inside the repository, and add a remote that points at the Origin repository. `depot ci migrate secrets-and-vars` pushes a branch, so it needs a remote it can push to. + +## Learn more + +- [Depot CI overview](/docs/ci/overview) +- [Depot CI quickstart](/docs/ci/quickstart) +- [Manage secrets and variables](/docs/ci/how-to-guides/manage-secrets-and-variables) diff --git a/content/ci/observability/datadog-ci-visibility.mdx b/content/ci/observability/datadog-ci-visibility.mdx index dff9cab..718c1f6 100644 --- a/content/ci/observability/datadog-ci-visibility.mdx +++ b/content/ci/observability/datadog-ci-visibility.mdx @@ -14,7 +14,7 @@ Depot CI can send your CI runs to [Datadog CI Visibility](https://docs.datadoghq ## Set up Datadog CI Visibility for Depot CI -1. In the Depot dashboard, go to [Depot CI settings](/orgs/_/workflows/settings/general) and turn on the **Datadog CI Visibility** toggle. +1. In the Depot dashboard, go to [organization settings](/orgs/_/settings). Under **Datadog CI Visibility**, turn on the **Send CI runs to Datadog** toggle. 2. Add a CI secret named `DD_API_KEY` with your Datadog API key: diff --git a/content/ci/observability/depot-ci-metrics.mdx b/content/ci/observability/depot-ci-metrics.mdx index 4de5236..4f005c1 100644 --- a/content/ci/observability/depot-ci-metrics.mdx +++ b/content/ci/observability/depot-ci-metrics.mdx @@ -31,6 +31,14 @@ When a job fails, Depot analyzes the failure and displays a **Failure Diagnosis* ![Depot CI failure diagnosis](/images/docs/depot-ci-failure-diagnosis.png) +You can fetch the same diagnosis from the CLI with `depot ci diagnose`, pointed at a run, workflow, job, or attempt: + +```bash +depot ci diagnose --run +``` + +The command groups similar failures across attempts, shows the diagnosis and possible fix for each group, and prints ready-to-run commands for drilling into a narrower target. For usage, see the [`depot ci diagnose` docs](/docs/cli/reference/depot-ci#depot-ci-diagnose) or run `depot ci diagnose --help`. + For deeper investigation, you can [debug a failing job with SSH](/docs/ci/how-to-guides/debug-with-ssh) to connect directly to the sandbox environment. For viewing and navigating job logs, see [Depot CI logs](/docs/ci/observability/depot-ci-logs). You can also fetch job and run metrics programmatically with the [Depot CI API](/docs/api/ci/reference). diff --git a/content/ci/oidc.mdx b/content/ci/oidc.mdx index de2a2dc..139ee35 100644 --- a/content/ci/oidc.mdx +++ b/content/ci/oidc.mdx @@ -51,6 +51,38 @@ The following is an example token: } ``` +## Restrict trust policies with the subject claim + +The sub claim is how you restrict a trust policy to a specific org, repository, or branch. It reads left to right, from the most stable identifier to the most ephemeral. The full claim has the following format: + +``` +spiffe://identity.depot.dev/org//ci/github///ref//sandbox/ +``` + +Match the segments you want to restrict, and use a wildcard for the rest. Do not include the final segment in the match, because Depot generates a new sandbox ID for each job, and a policy that pins it stops matching on the next run. + +| Segment | Example | Stability | Safe to pin? | +| ----------------------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | +| `spiffe://identity.depot.dev` | — | Fixed. The trust domain and issuer. | Yes. | +| `org/` | `org/org_1a2b3c4d` | Stable for the life of your Depot organization. | Yes — recommended on every policy. | +| `ci/github//` | `ci/github/my-org/my-repo` | Stable per repository. `/` is the GitHub slug. | Yes. | +| `ref/` | `ref/refs/heads/main` | The full Git ref, including the `refs/heads/` prefix. Stable per branch or tag; changes when the branch does. | Yes, to lock a role to one branch. The ref contains slashes, so it spans more than one path segment. | +| `sandbox/` | `sandbox/snd_9x8y7z` | **Per run.** A fresh sandbox ID is minted for every job. | **No.** Pinning this segment breaks every subsequent run. | + +Common patterns: + +- Everything in your GitHub organization: `spiffe://identity.depot.dev/org//ci/github//*` +- A specific repository: `spiffe://identity.depot.dev/org//ci/github///*` +- A specific branch: `spiffe://identity.depot.dev/org//ci/github///ref/refs/heads/main/sandbox/*` + +### Matching precisely on your cloud provider + +How you pin the identity beyond the `sub` prefix depends on which claims your cloud provider exposes as trust-policy condition keys. + +On AWS, a self-managed OIDC provider surfaces only the standard claims as IAM condition keys: `aud` and `sub` (along with `amr`, `email`, and `oaud`). The GitHub-compatible and Depot-specific claims (`repository`, `repository_owner`, `ref`, and the rest) travel inside the token but are not available as `identity.depot.dev:` condition keys, so a trust policy that references them never matches. On AWS, match the `sub` claim with `StringLike` as shown in [Example: Configure OIDC with AWS](#example-configure-oidc-with-aws). The `sub` value already encodes the org, owner, repo, and ref, so a single sub condition is enough to restrict access to a repository or branch. + +On providers that map arbitrary token claims into their trust conditions, such as GCP workload identity federation, you can match the flat claims directly (`repository`, `repository_owner`, `ref`, and the rest of the [claim reference](#token-claim-reference) below). These are exact-match values that carry the same meaning as their GitHub Actions equivalents, so on those platforms you can pin them exactly instead of wildcarding the `sub` path. + ## Configure OIDC with your cloud provider The general steps are the same for any OIDC-compatible provider: @@ -122,7 +154,7 @@ The following needs to change on the cloud provider side when moving from GitHub | ------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Issuer (`iss`) | `https://token.actions.githubusercontent.com` | `https://identity.depot.dev` | | Subject (`sub`) | `repo:owner/repo:ref:refs/heads/main` | `spiffe://identity.depot.dev/org//ci/github///ref//sandbox/` | -| Repo/branch scoping | `sub` (encoded in the subject) | `sub` or `repository` + `ref` claims (separate conditions) | +| Repo/branch scoping | `sub` (encoded in the subject) | `sub` (new format — see above) | | JWKS endpoint | `https://token.actions.githubusercontent.com/.well-known/jwks.json` | `https://identity.depot.dev/keys` | To use Depot CI with OIDC, follow these steps: diff --git a/content/ci/overview.mdx b/content/ci/overview.mdx index b4cfed4..7e40c49 100644 --- a/content/ci/overview.mdx +++ b/content/ci/overview.mdx @@ -174,11 +174,15 @@ Plans also include [container build](/docs/container-builds/overview) minutes an ## Depot CI sandboxes -Depot CI runs your workflows in x86_64 sandboxes. Sandboxes can use from 2 CPUs/8 GB of memory up to 64 CPUs/256 GB of memory. The default sandbox image is based on Ubuntu 24.04. +Depot CI runs your workflows in x86_64 and Arm64 sandboxes. Sandboxes can use from 2 CPUs/8 GB of memory up to 64 CPUs/256 GB of memory. The default sandbox image is based on Ubuntu 24.04. Larger sandboxes consume the Depot CI minutes included in your plan faster and cost more per second for extra usage. For example, a 4-CPU sandbox uses 2 minutes for every 1 minute of running time. -Use a _Label_ from the following table in the `runs-on` key of your workflow. For [custom images](/docs/ci/how-to-guides/custom-images), use a _Sandbox size_ paired with a Depot Registry custom image URL in the `runs-on` key. +Use a _Label_ from the tables below in the `runs-on` key of your workflow. For [custom images](/docs/ci/how-to-guides/custom-images), use a _Sandbox size_ paired with a Depot Registry custom image URL in the `runs-on` key. + +Depot CI doesn't provide sandboxes for macOS or Windows. Labels for those runner types (as listed in [Depot GitHub Actions runner types](/docs/github-actions/runner-types)) aren't compatible with Depot CI. + +### x86_64 sandboxes | Label | Sandbox size | CPUs | Memory | Per-second price | Plan minutes multiplier | | :---------------------- | :----------- | :--- | :----- | :--------------- | :---------------------- | @@ -189,7 +193,16 @@ Use a _Label_ from the following table in the `runs-on` key of your workflow. Fo | `depot-ubuntu-24.04-32` | `32x128` | 32 | 128 GB | $0.0016 | 16x | | `depot-ubuntu-24.04-64` | `64x256` | 64 | 256 GB | $0.0032 | 32x | -Depot CI doesn't provide sandboxes for Arm, macOS, or Windows. Labels for these runner types (as listed in [Depot GitHub Actions runner types](/docs/github-actions/runner-types)) aren't compatible with Depot CI. +### Arm64 sandboxes + +| Label | Sandbox size | CPUs | Memory | Per-second price | Plan minutes multiplier | +| :-------------------------- | :----------- | :--- | :----- | :--------------- | :---------------------- | +| `depot-ubuntu-24.04-arm` | `2x8` | 2 | 8 GB | $0.0001 | 1x | +| `depot-ubuntu-24.04-arm-4` | `4x16` | 4 | 16 GB | $0.0002 | 2x | +| `depot-ubuntu-24.04-arm-8` | `8x32` | 8 | 32 GB | $0.0004 | 4x | +| `depot-ubuntu-24.04-arm-16` | `16x64` | 16 | 64 GB | $0.0008 | 8x | +| `depot-ubuntu-24.04-arm-32` | `32x128` | 32 | 128 GB | $0.0016 | 16x | +| `depot-ubuntu-24.04-arm-64` | `64x256` | 64 | 256 GB | $0.0032 | 32x | ## FAQ diff --git a/content/cli/reference/container-builds.mdx b/content/cli/reference/container-builds.mdx index 8159d8d..bb4b5b3 100644 --- a/content/cli/reference/container-builds.mdx +++ b/content/cli/reference/container-builds.mdx @@ -437,6 +437,37 @@ Additional flags that can be used with this command. | `token` | Depot token | {/* */} +## `depot projects get` + +Display the details and configuration of a Depot project. + +If no project ID is provided, the command uses `DEPOT_PROJECT_ID` or the project configured in `depot.json` in the current +directory. + +**Example** + +```shell +depot projects get +``` + +You can pass a project ID as an argument, and use `--output json` for machine-readable output: + +```shell +depot projects get --output json +``` + +### Flags for `get` + +Additional flags that can be used with this command. + +{/* */} +| Name | Description | +| ---- | ----------- | +| `project-id` | Depot project ID | +| `output` | Output format (`json`) | +| `token` | Depot token | +{/* */} + ## `depot projects list` Display an interactive listing of current Depot projects. Selecting a specific project will display the latest builds. @@ -450,6 +481,41 @@ To exit type `q` or `ctrl+c` depot list projects ``` +## `depot projects update` + +Update the name, region, or cache storage policy of a Depot project. Only the values you pass as flags are changed, and at +least one of `--name`, `--region`, or `--cache-storage-policy` is required. + +If no project ID is provided, the command uses `DEPOT_PROJECT_ID` or the project configured in `depot.json` in the current +directory. + +**Example** + +```shell +depot projects update --name "New project name" +``` + +You can pass a project ID as an argument, and use `--output json` for machine-readable output: + +```shell +depot projects update --region eu-central-1 --output json +``` + +### Flags for `update` + +Additional flags that can be used with this command. + +{/* */} +| Name | Description | +| ---- | ----------- | +| `project-id` | Depot project ID | +| `name` | Project name | +| `region` | Build data storage region | +| `cache-storage-policy` | Build cache to keep per architecture in GB | +| `output` | Output format (`json`) | +| `token` | Depot token | +{/* */} + ## `depot pull` Pull an image from the Depot Registry by build ID in a project. diff --git a/content/cli/reference/depot-ci.mdx b/content/cli/reference/depot-ci.mdx index f4cb1f4..1cb9e9a 100644 --- a/content/cli/reference/depot-ci.mdx +++ b/content/cli/reference/depot-ci.mdx @@ -24,37 +24,45 @@ After migration, the command reports any secrets and variables referenced by the Each phase is also available as a standalone subcommand: -- [`depot ci migrate preflight`](#depot-ci-migrate-preflight) — validate authentication and GitHub app access -- [`depot ci migrate workflows`](#depot-ci-migrate-workflows) — copy and transform workflows -- [`depot ci migrate secrets-and-vars`](#depot-ci-migrate-secrets-and-vars) — import GitHub secrets and variables into Depot CI +- [`depot ci migrate preflight`](#depot-ci-migrate-preflight): validate authentication and repository access for the selected forge +- [`depot ci migrate workflows`](#depot-ci-migrate-workflows): copy and transform workflows +- [`depot ci migrate secrets-and-vars`](#depot-ci-migrate-secrets-and-vars): import secrets and variables into Depot CI ### Flags -| Flag | Description | -| ----------------- | -------------------------------------------------------------------------------------- | -| `--yes` | Run in non-interactive mode, migrating all discovered workflows automatically | -| `--overwrite` | Overwrite an existing `.depot/` directory without prompting | -| `--org ` | Specify a Depot organization ID (required if you belong to more than one organization) | -| `--token ` | Depot API token | +| Flag | Description | +| ----------------- | -------------------------------------------------------------------------------------------- | +| `--yes`, `-y` | Run in non-interactive mode, migrating all discovered workflows automatically | +| `--overwrite` | Overwrite an existing `.depot/` directory without prompting | +| `--forge ` | Forge that hosts the repository and sends CI events, `github` or `origin`. Default `github`. | +| `--org ` | Specify a Depot organization ID (required if you belong to more than one organization) | +| `--token ` | Depot API token | + +Every `depot ci migrate` subcommand accepts `--forge` and `--yes`. Use `--forge=origin` for a native [Origin](/docs/ci/integrations/origin) repository. A repository that syncs with GitHub uses the default `github`. `--forge=origin` needs Depot CLI v2.102.7 or newer. --- ### `depot ci migrate preflight` -Validates that you are authenticated, detects the GitHub repository from your git remote, and checks that the Depot Code Access GitHub App is installed with the correct permissions and repository access. +Validates that you are authenticated, detects the repository for the selected forge from your git remote, and checks the access required to migrate it. ```bash depot ci migrate preflight +depot ci migrate preflight --forge=origin ``` -If the app is not installed or needs updated permissions, the command prints a link to configure it. +With `--forge=github`, the command checks that the Depot Code Access GitHub App is installed with the correct permissions and repository access. If the app is not installed or needs updated permissions, the command prints a link to configure it. + +With `--forge=origin`, the command checks that the Origin repository is available to your Depot organization, then prints the detected repository. #### Flags -| Flag | Description | -| ----------------- | -------------------------------------------------------------------------------------- | -| `--org ` | Specify a Depot organization ID (required if you belong to more than one organization) | -| `--token ` | Depot API token | +| Flag | Description | +| ----------------- | -------------------------------------------------------------------------------------------- | +| `--forge ` | Forge that hosts the repository and sends CI events, `github` or `origin`. Default `github`. | +| `--yes`, `-y` | Run in non-interactive mode | +| `--org ` | Specify a Depot organization ID (required if you belong to more than one organization) | +| `--token ` | Depot API token | --- @@ -71,10 +79,11 @@ depot ci migrate workflows 1. Discovers all workflow files in `.github/workflows/`. 2. Analyzes each workflow for compatibility with Depot CI. 3. Prompts you to select which workflows to migrate. -4. Copies selected workflows to `.depot/workflows/` and any local actions from `.github/actions/` to `.depot/actions/`. -5. Applies compatibility fixes (for example, mapping `ubuntu-latest` to `depot-ubuntu-latest`). -6. Disables jobs that use unsupported features and adds inline comments explaining what changed. -7. Reports any secrets and variables detected in the migrated workflows. +4. With `--forge=origin`, sends the selected workflow contents to Depot for Origin compatibility analysis. +5. Copies selected workflows to `.depot/workflows/` and any local actions from `.github/actions/` to `.depot/actions/`. +6. Applies compatibility fixes (for example, mapping `ubuntu-latest` to `depot-ubuntu-latest`). +7. Disables jobs that use unsupported features and adds inline comments explaining what changed. +8. Reports any secrets and variables detected in the migrated workflows. #### What gets copied @@ -85,12 +94,15 @@ depot ci migrate workflows #### Flags -| Flag | Description | -| ----------------- | -------------------------------------------------------------------------------------- | -| `--yes` | Run in non-interactive mode, migrating all discovered workflows automatically | -| `--overwrite` | Overwrite an existing `.depot/` directory without prompting | -| `--org ` | Specify a Depot organization ID (required if you belong to more than one organization) | -| `--token ` | Depot API token | +| Flag | Description | +| ----------------- | -------------------------------------------------------------------------------------------- | +| `--yes`, `-y` | Run in non-interactive mode, migrating all discovered workflows automatically | +| `--overwrite` | Overwrite an existing `.depot/` directory without prompting | +| `--forge ` | Forge that hosts the repository and sends CI events, `github` or `origin`. Default `github`. | +| `--org ` | Specify a Depot organization ID (required if you belong to more than one organization) | +| `--token ` | Depot API token | + +With `--forge=origin`, the command also prints Origin compatibility findings for actions that Origin cannot support in the mode your workflow uses. Findings don't block the migration: Depot still writes the selected workflows. See [Origin compatibility findings](/docs/ci/integrations/origin#origin-compatibility-findings). #### What gets transformed @@ -113,20 +125,21 @@ Creates a one-shot GitHub Actions workflow that reads secrets and variables from depot ci migrate secrets-and-vars ``` -The command pushes a temporary branch to your GitHub repository containing a workflow that runs on GitHub Actions. The workflow reads your existing GitHub secrets and variables and imports them into Depot CI using the Depot CLI. +The command commits a temporary branch containing a one-shot workflow, without touching your worktree, then prints the `git push` command for it. You push the branch yourself, and you have five minutes before the migration intent expires. Once pushed, the workflow runs, reads your existing secrets and variables, and imports them into Depot CI using the Depot CLI. -In interactive mode, you can preview the generated workflow before it is created. After the workflow is triggered, the command prints a URL where you can monitor the import. +With `--forge=origin`, the command detects the Origin remote instead of a GitHub remote, and reads the values from that repository. #### Flags -| Flag | Description | -| ------------------ | -------------------------------------------------------------------------------------- | -| `--yes` | Skip preview and confirmation prompts | -| `--branch ` | Override the branch name used for the migration workflow | -| `--secrets ` | Secret name to include; can be repeated to select multiple. Omit to include all. | -| `--vars ` | Variable name to include; can be repeated to select multiple. Omit to include all. | -| `--org ` | Specify a Depot organization ID (required if you belong to more than one organization) | -| `--token ` | Depot API token | +| Flag | Description | +| -------------------------- | ------------------------------------------------------------------------------------------------------- | +| `--yes`, `-y` | Run in non-interactive mode | +| `--forge ` | Forge that hosts the repository and sends CI events, `github` or `origin`. Default `github`. | +| `--branch-prefix ` | Prefix for the temporary migration branch. The intent ID is appended. Default `depot-migrate-secrets-`. | +| `--secrets ` | Secret name to include; can be repeated to select multiple. Omit to include all. | +| `--vars ` | Variable name to include; can be repeated to select multiple. Omit to include all. | +| `--org ` | Specify a Depot organization ID (required if you belong to more than one organization) | +| `--token ` | Depot API token | --- diff --git a/content/container-builds/how-to-guides/autoscaling.mdx b/content/container-builds/how-to-guides/autoscaling.mdx index 0b1c370..5f084a5 100644 --- a/content/container-builds/how-to-guides/autoscaling.mdx +++ b/content/container-builds/how-to-guides/autoscaling.mdx @@ -9,7 +9,7 @@ Container build autoscaling allows you to automatically scale out your builds to ## How build autoscaling works -By default, all builds for a project are routed to a single BuildKit host per architecture you're building. Each BuildKit builder can process multiple jobs concurrently on the same host, which enables deduplication of work across builds that share similar steps and layers. +By default, all builds for a project are routed to a single BuildKit host per architecture you're building. Each BuildKit builder can process multiple jobs concurrently on the same host, which enables deduplication of work across builds that share similar steps and layers. Autoscaling is disabled by default, so there's no cap on concurrent builds per builder until you enable it. With build autoscaling enabled, Depot will automatically spin up additional BuildKit builders when the concurrent build limit is reached. Here's how the process works: @@ -49,12 +49,11 @@ Consider these tradeoffs before enabling autoscaling: To enable container build autoscaling: -1. Navigate to your Depot project settings -2. Go to the **Settings** tab -3. Find the **Build autoscaling** section -4. Toggle **Enable horizontal autoscaling** -5. Set the **Maximum concurrent builds per builder** (default is 1) -6. Click **Save changes** +1. Log in to your [Depot dashboard](/orgs). +2. Click **Projects**, select a project, and click **Settings**. +3. In the **Autoscaling** section, toggle on **Enable horizontal autoscaling**. +4. Set **Builds per instance** (prefilled with `2`). +5. Click **Save changes**. -The concurrent builds setting determines how many builds can run on a single builder before triggering a scale-out event. For example: +**Builds per instance** determines how many builds can run on a single builder before triggering a scale-out event. For example: - Setting it to `1` means each build gets its own dedicated builder +- Setting it to `2`, the prefilled value, means two builds can share a builder before a new one is launched - Setting it to `3` means up to 3 builds can share a builder before a new one is launched ## Cache behavior with autoscaling -Understanding cache behavior is crucial when using autoscaling: +Understanding cache behavior is crucial when using autoscaling. ### Cache cloning When additional builders are launched due to autoscaling: -1. They receive a **read-only clone** of the main builder's layer cache -2. New layers built on scaled builders are stored locally but **not persisted** back to the main cache -3. When the scaled builder terminates, its local cache changes are lost +- They receive a **read-only clone** of the main builder's layer cache +- New layers built on scaled builders are stored locally but **not persisted** back to the main cache +- When the scaled builder terminates, its local cache changes are lost ### Cache implications @@ -91,7 +91,7 @@ This means: ## Billing and costs -Build autoscaling is available on **all Depot plans** at no additional cost: +Build autoscaling is available on all Depot plans at no additional cost. - **No extra charges**: Autoscaling itself doesn't incur additional fees - **Standard compute rates**: You pay the same per-minute rate for scaled builders as regular builders @@ -123,7 +123,7 @@ Here's an example of when autoscaling might be beneficial: - Build times increase dramatically when multiple builds run concurrently - Builds may fail due to out-of-memory errors when too many run simultaneously -**With autoscaling** (max 1 concurrent build per builder): +**With autoscaling** (and Builds per instance set to 1): - Each resource-intensive build gets its own dedicated builder with full access to 16 CPUs and 32GB RAM - No resource contention between builds @@ -152,10 +152,8 @@ A `depot bake` command is submitted as a single build request to BuildKit, regar ## Troubleshooting -If you're experiencing issues with autoscaling: - -1. **Builds still queueing**: Verify autoscaling is enabled and check your concurrent build limit -2. **Increased cache misses**: This is expected behavior with cache clones - consider if the speed benefit outweighs cache efficiency -3. **Costs increasing**: Monitor your usage in the Depot dashboard and adjust concurrent limits if needed +- **Builds still queueing**: Verify autoscaling is enabled and check your concurrent build limit +- **Increased cache misses**: This is expected behavior with cache clones - consider if the speed benefit outweighs cache efficiency +- **Costs increasing**: Monitor your usage in the Depot dashboard and adjust concurrent limits if needed For additional help, reach out on [Discord](https://depot.dev/discord) or contact support. diff --git a/content/github-actions/how-to-guides/egress-filtering.mdx b/content/github-actions/how-to-guides/egress-filtering.mdx index c9fee8f..886938a 100644 --- a/content/github-actions/how-to-guides/egress-filtering.mdx +++ b/content/github-actions/how-to-guides/egress-filtering.mdx @@ -14,7 +14,7 @@ By default, Depot runners allow outbound connections to any external service. Yo The following example shows a set of rules to get a Docker build with Golang working: -[![A screenshot of the egress filter rules settings in use](/images/egress-filter-rules.webp)](/images/egress-filter-rules.webp) +![A screenshot of the egress filter rules settings in use](/images/egress-filter-rules.webp) This example first applies a blanket deny rule, which blocks all outbound connections by default. Then, it allows connections to the following: diff --git a/content/managed/on-aws.mdx b/content/managed/on-aws.mdx index 35fd8a5..d29eb83 100644 --- a/content/managed/on-aws.mdx +++ b/content/managed/on-aws.mdx @@ -8,7 +8,7 @@ With Depot Managed on Amazon Web Services (AWS), the Depot data plane is deploye ## Architecture -[![self-hosted architecture diagram](/images/self-hosted-architecture.png)](/images/self-hosted-architecture.png) +![self-hosted architecture diagram](/images/self-hosted-architecture.png) ## Setup and Usage diff --git a/content/registry/overview.mdx b/content/registry/overview.mdx index a5ae5c8..416727d 100644 --- a/content/registry/overview.mdx +++ b/content/registry/overview.mdx @@ -30,11 +30,24 @@ If you want to distribute images across multiple registries, use [`depot push`]( You can also use [`depot pull`](/docs/cli/reference/container-builds#depot-pull) to download any image from Depot Registry into your local, CI, or production environment. -## Registry Explorer +## CDN speed -The [Registry Explorer](/orgs/_/registry/explorer) in the Depot dashboard lets you browse all your repositories by name. From there you can explore manifests by tag or digest, view artifact metadata and platforms, inspect attestations, and see linked build details for project-scoped images. +The registry can serve image layers at one of two speeds: -[![Screenshot showing the Depot Registry Explorer with searchable repositories and tag browsing](/images/docs/registry-page.webp)](/images/docs/registry-page.webp) +- **Standard**: The default. You pay nothing for transfer, in or out. +- **Fast**: Serves layer blobs through Depot's accelerated CDN. You pay **$0.10/GB** for transfer out. + +CDN speed is organization-wide and only organization owners can change it. + +To change the speed, switch **CDN speed** on your [Registry settings](/orgs/_/registry/settings) page. + +To see how much data you're transferring, find **Registry CDN Data Transfer** under **Storage & Transfer** on the [organization usage page](/orgs/_/usage). + +## Browsing repositories + +The [Registry](/orgs/_/registry/repositories) page in the Depot dashboard lets you browse all your repositories by name. From there you can explore manifests by tag or digest, view artifact metadata and platforms, inspect attestations, and see linked build details for project-scoped images. + +![Screenshot of the Depot Registry page showing storage usage and a searchable list of repositories with tag counts and sizes](/images/docs/registry-page.webp) ## Use cases @@ -80,31 +93,29 @@ docker login {orgId}.registry.depot.dev -u x-token -p ## Pricing -Depot Registry is included in all plans. Registry storage counts toward the same included storage amount as your container build cache and [Depot Cache](/docs/cache/overview), which is 25 GB on Developer and 250 GB on Startup. Storage above the included amount is billed at **$0.20/GB/month**. There are no charges for data transfer into or out of the registry. +Depot Registry is included in all plans. Registry storage counts toward the same included storage amount as your container build cache and [Depot Cache](/docs/cache/overview), which is 25 GB on Developer and 250 GB on Startup. Storage above the included amount is billed at **$0.20/GB/month**. + +Data transfer, both in and out, is free on the default **Standard** [CDN speed](#cdn-speed). On **Fast** CDN speed, data served out of the registry is billed at **$0.10/GB** from the first GB, with no included allowance. See the [pricing page](/pricing) for plan details. ## Image retention -By default, images pushed to the Depot Registry are retained for **7 days**, after which they are deleted. You can configure retention on a per-repository basis from the repository's settings in the [Explorer](/orgs/_/registry/explorer). +Retention limits are opt-in for tagged images. You can add a retention rule when you create a repository or at any time afterwards from the repository's settings in the [Registry](/orgs/_/registry/repositories). + +Each repository can have up to two rules, one for tagged manifests and one for untagged manifests. Under **Retention Policy**, click **Add rule** and choose: -You can choose to retain images by age or by tag count: +- **Tagged manifests**: set **Keep days** to retain images for 1 to 30 days, or **Keep count** to retain the most recent 1 to 1000 images. Keeping by count is useful for reducing storage costs when you care more about keeping the most recent versions than keeping images for a fixed duration. +- **Untagged manifests**: set **Keep days** to retain them for 1 to 30 days, or leave **Use default**, which keeps them for **3 days**. -By age: +**Keep days** is measured from the time a manifest was pushed, not from the last time it was pulled. Pulling an image doesn't extend its lifetime, so a manifest you pulled an hour ago is still deleted once it's older than the **Keep days** value. -- 1 day -- 7 days (default) -- 14 days -- 30 days +For images saved from a build with `depot build --save`, set retention on the project instead of the repository. In the project's **Settings** tab, **Image Retention Policy** accepts 1, 7, 14, or 30 days, and defaults to **Unlimited**. -By tag count: +You can also individually delete manifests from a repository in the [Registry](/orgs/_/registry/repositories). -- 5 tags -- 10 tags -- 25 tags -- 50 tags -- 100 tags +### Storage usage drops about a day after a deletion -Retaining by tag count is useful for reducing storage costs when you care more about keeping the most recent versions than keeping images for a fixed duration. +Deleting a manifest, either yourself or through a retention rule, removes it from the repository right away. It might take a full day or a bit longer for the deletion to reflect in your storage usage. The layers the manifest referenced are reclaimed by a background process that, depending on when the layers were last accessed, can take up to 31 hours to delete them. -You can also individually delete images from the Registry Explorer. +Layers shared with a manifest you still have are never reclaimed, so deleting one tag of a set of similar images may free very little. diff --git a/content/registry/pull-through-cache.mdx b/content/registry/pull-through-cache.mdx index a2470e7..114026d 100644 --- a/content/registry/pull-through-cache.mdx +++ b/content/registry/pull-through-cache.mdx @@ -11,7 +11,7 @@ Configuration happens in two steps: - **Upstream registry**: The external registry connection, including the URL and credentials. You configure upstream registries at the organization level and they can be reused across multiple Depot repositories. - **Upstream repository**: The image path within an upstream registry that a Depot repository mirrors. You choose this path when creating a Depot repository. -You can create and update upstream registries from [Registry Settings](/orgs/_/registry/settings). Pull-through cache for an individual repository can only be configured when you cerate the repository. +You can create and update upstream registries from [Registry Settings](/orgs/_/registry/settings). Pull-through cache for an individual repository can only be configured when you create the repository. ## Use cases @@ -37,7 +37,7 @@ Once saved, the upstream registry appears in the list and is available when crea After creating an upstream registry, create a Depot repository and configure pull-through cache during repository creation. -1. Open [Repositories](/orgs/_/registry/repositories) in the Depot dashboard. +1. Open the [Registry](/orgs/_/registry/repositories) page in the Depot dashboard. 2. Click **Create repository**. 3. Enter the Depot repository name. 4. Under **Pull-through cache**, click **Configure**. @@ -63,6 +63,7 @@ To pull images through Depot Registry, use a [pull token](/docs/cli/authenticati | Quay.io | `https://quay.io` | Basic auth: Quay.io username + password or robot token | | AWS ECR | Your ECR registry URL | IAM role ARN | | Google Artifact Registry | `https://us-docker.pkg.dev` (or your region) | Basic auth: `_json_key` + service account JSON key | +| Google Container Registry | `https://gcr.io` | Basic auth: `_json_key` + service account JSON key | | Azure Container Registry | Your ACR URL | Basic auth: service principal client ID + secret | | Custom registry | Your registry URL | Basic auth: username + password |