diff --git a/content/account.mdx b/content/account.mdx index 755b508..8b5a339 100644 --- a/content/account.mdx +++ b/content/account.mdx @@ -10,9 +10,7 @@ The [Depot dashboard](/orgs/) is where you manage your account and organizations ## Account settings -You can access your user account settings in the Depot dashboard. Click the organization name at the top of the page and select **User settings**. - -![Select User settings from the depot dashboard menu](/images/docs/dashboard-user-settings.png) +You can access your user account settings in the Depot dashboard. Click the organization name in the sidebar and select **Settings**, then **Personal settings** under **Account**. From the user [Settings](/settings) page you can do the following: @@ -27,7 +25,7 @@ You can't change the email address for your Depot account. To delete an account, Every action you take in Depot is within the context of an organization. An organization typically represents a single company or team. Depot bills at the organization level, consolidating all usage across products into a single invoice. -You can view all of your builds, runners, usage, and billing per organization in your Depot dashboard. Configure organization-level settings in the organization [Settings](/orgs/_/settings) page. +You can view all of your builds, runners, usage, and billing per organization in your Depot dashboard. Configure organization-level settings in the organization [Settings](/orgs/_/settings/general) page. ### Create an organization @@ -60,8 +58,8 @@ Organizations have role-based access. When you create an organization, you have If you have a Startup or Business plan, you can invite users to join an organization. 1. Log in to your [Depot dashboard](/orgs). -2. Under **Organization**, click [Settings](/orgs/_/settings). -3. From the **Members** section of the **Settings** page you can: +2. Open **Settings**. +3. Select [Members](/orgs/_/settings/members) under **Organization** to: - View members and change their role. - View or remove pending invites. - Invite new members using either their existing Depot account email or the email they'll use to sign up for Depot. @@ -80,8 +78,8 @@ To delete an organization, send a request to help@depot.dev. Include the name of ## Billing -Each Depot organization has its own [plan](/pricing) and billing. To view an organization's billing, payment, and plan details, go to the organization [Settings](/orgs/_/settings) page in your Depot dashboard. +Each Depot organization has its own [plan](/pricing) and billing. To view an organization's billing, payment, and plan details, go to the [Billing & usage](/orgs/_/settings/billing-and-usage) page in your Depot dashboard. -You can access invoices from Stripe that contain VAT information through the Billing Portal in your organization [Settings](/orgs/_/settings). +You can access invoices from Stripe that contain VAT information through the Billing Portal in [Billing & usage](/orgs/_/settings/billing-and-usage). For billing issues, see the [troubleshooting page](/docs/troubleshooting#billing). diff --git a/content/api/github-actions-api.mdx b/content/api/github-actions-api.mdx new file mode 100644 index 0000000..21e5a4c --- /dev/null +++ b/content/api/github-actions-api.mdx @@ -0,0 +1,147 @@ +--- +title: GitHub Actions API +ogTitle: Automate Depot GitHub Actions jobs and analytics +description: Use the Depot GitHub Actions API to inspect jobs and logs, analyze runner usage, manage connections, and retrieve recommendations. +--- + +The GitHub Actions API gives your tools and agents organization-scoped access to Depot job operations, logs, analytics, +runner recommendations, GitHub App connections, test-result summaries, and usage projections. + +Download the [OpenAPI specification](/openapi/depot-github-actions/v1.json) to generate a client or inspect every request +and response field. + +## Authenticate requests + +Create an organization token in your [organization settings](/orgs/_/settings), then send it as a bearer token. Depot +derives the organization from this token. A request can't select a different organization. + +```http +Authorization: Bearer +``` + +Responses don't include GitHub provider credentials. + +## List jobs + +Call Connect JSON methods at `https://api.depot.dev//`. This request lists the 50 newest jobs for one +repository: + +```bash +curl https://api.depot.dev/depot.core.v1.GithubActionsService/ListGithubActionsJobs \ + -H "Authorization: Bearer $DEPOT_TOKEN" \ + -H 'Connect-Protocol-Version: 1' \ + -H 'Content-Type: application/json' \ + --data '{"repositories":["acme/widgets"],"pageSize":50}' +``` + +Job and analytics queries default to the last 30 days and accept windows of up to 90 days. + +## Search logs + +Log queries default to the last hour and accept windows of up to 30 days. You can filter by repository, workflow, +runner label, action, or compute ID. + +```bash +curl https://api.depot.dev/depot.core.v1.GithubActionsService/SearchGithubActionsLogs \ + -H "Authorization: Bearer $DEPOT_TOKEN" \ + -H 'Connect-Protocol-Version: 1' \ + -H 'Content-Type: application/json' \ + --data '{ + "query":"timeout", + "timeRange":{"startAt":"2026-09-17T00:00:00Z","endAt":"2026-09-18T00:00:00Z"}, + "filters":{"repositories":["acme/widgets"]}, + "pageSize":100 + }' +``` + +Use `CountGithubActionsLogs` for a count, `ListGithubActionsLogFacets` to discover filter values, and +`GetGithubActionsLogContext` with a returned `lineId` to fetch surrounding lines. + +## Analyze runner usage + +`GetGithubActionsAnalytics` returns job counts, failure rates, elapsed time, and billable time in hourly or daily buckets. +`ListGithubActionsJobAnalytics` groups CPU, memory, duration, and failure metrics by job. + +```bash +curl https://api.depot.dev/depot.core.v1.GithubActionsService/ListGithubActionsJobAnalytics \ + -H "Authorization: Bearer $DEPOT_TOKEN" \ + -H 'Connect-Protocol-Version: 1' \ + -H 'Content-Type: application/json' \ + --data '{ + "timeRange":{"startAt":"2026-09-17T11:00:00Z","endAt":"2026-09-17T12:00:00Z"}, + "filters":{"repositories":["acme/widgets"]}, + "pageSize":100 + }' +``` + +`ListGithubActionsRecommendations` uses the same filters. It returns size-up recommendations when average CPU or memory +utilization reaches 90%. It returns size-down recommendations when both averages stay at or below 30% and both peaks stay +at or below 70%. These thresholds use rounded whole percentages, with no minimum job count. + +CPU and memory utilization for `ListGithubActionsJobAnalytics` and `ListGithubActionsRecommendations` is calculated per +UTC day, matching the dashboard. For example, a request for 11:00 to 12:00 UTC calculates utilization from metrics for that entire UTC day. +By default, both methods use metrics from the last 30 days. + +Job counts, durations, and failure rates use the exact requested time range. Recommendations use the daily utilization described +above, so metrics outside a sub-day window can affect the recommendation. + +Recommendations preserve the runner's architecture, OS, and storage family. Size-down recommendations require both CPU and memory data. +Workflow-path filters return duration and failure analytics, but no utilization or recommendations when telemetry cannot +be attributed to that path. + +To compare periods, request analytics for each time range and calculate the difference. To rank jobs by average +duration, page through `ListGithubActionsJobAnalytics` and sort by `averageDurationSeconds`. + +## Inspect job durations + +`GetGithubActionsDurationDistribution` returns the dashboard's duration buckets: `0-1m`, `1-5m`, `5-10m`, `10-20m`, +`20-30m`, `30-60m`, and `>60m`. Each upper bound is inclusive. Zero-duration jobs and empty buckets are omitted. +It accepts analytics filters, with `filters.jobs` matching job display names rather than workflow YAML keys. + +`ListGithubActionsJobRuns` returns completed runs for a repository and job display name, longest first. Use the `name` +from `ListGithubActionsJobs` for `jobName`. Unlike the job list, both duration methods filter by finish time. This request +retrieves runs that finished on one UTC day: + +```bash +curl https://api.depot.dev/depot.core.v1.GithubActionsService/ListGithubActionsJobRuns \ + -H "Authorization: Bearer $DEPOT_TOKEN" \ + -H 'Connect-Protocol-Version: 1' \ + -H 'Content-Type: application/json' \ + --data '{ + "repository":"acme/widgets", + "jobName":"Run tests", + "timeRange":{"startAt":"2026-09-17T00:00:00Z","endAt":"2026-09-18T00:00:00Z"}, + "pageSize":100 + }' +``` + +Historical runs return an empty `jobId` when the GitHub identifier is unavailable. Results can change between pages as +analytics are ingested. + +## Page through results + +When a response contains `nextPageToken`, pass it as `pageToken` with the same filters and time range. Page tokens are +opaque and bound to both the authenticated organization and the original request. + +The `dataThrough` field tells you how current the response is. Jobs come from Depot's transactional store. Logs, +analytics, recommendations, and test-result summaries can lag while telemetry is ingested. + +## Terminate a job + +`TerminateGithubActionsJob` requests termination of the Depot compute resource for a queued or running job. The method is +idempotent and reports whether termination was requested, already requested, already terminal, or no active compute was +found. It doesn't cancel the GitHub workflow run itself. + +## Manage GitHub connections + +Use `ListGithubActionsConnections` and `ListGithubActionsRepositories` to inspect the installations available to the +organization. `CreateGithubActionsInstallationUrl` returns a signed URL that expires after 10 minutes. Open it in a +browser to install the Depot GitHub App. `DeleteGithubActionsConnection` disconnects an installation. + +## Inspect tests and projected usage + +`GetGithubActionsTestResultsSummary` returns passed, failed, errored, skipped, and unknown test counts for a job. The +response also includes the owner values you can pass to the Test Results API. + +`GetGithubActionsUsageProjection` returns actual and projected billable seconds for a billing window. Its cost estimate +uses the published list rate and excludes discounts, credits, and custom pricing. diff --git a/content/api/overview.mdx b/content/api/overview.mdx index 83805b4..b22ebaa 100644 --- a/content/api/overview.mdx +++ b/content/api/overview.mdx @@ -12,6 +12,11 @@ The Depot APIs are collections of endpoints that grant access to the underlying [Depot CI](/docs/ci/overview) has its own API for working with workflows programmatically: dispatching and rerunning workflows, listing runs, checking status, fetching logs and metrics, retrying and cancelling jobs, and downloading artifacts. See the [Depot CI API reference](/docs/api/ci/reference) for all endpoints and examples. +## GitHub Actions API + +Inspect Depot-managed GitHub Actions jobs and logs, retrieve CPU and memory analytics, generate runner-size recommendations, +and manage GitHub App connections with the [GitHub Actions API](/docs/api/github-actions-api). + ## Container Builds API Organizations can manage projects, acquire BuildKit endpoints, and run image builds for their applications or services programmatically. Depot provides the following SDKs for interacting with the Container Builds API: @@ -28,8 +33,8 @@ If you're using the Container Builds API to build untrusted code, you need **one ## Sandbox API - The Sandbox SDK is in private beta. Methods might change before the SDK becomes generally available. Sandboxes are - billed per vCPU-second at the Depot CI compute rate. [Contact us](/help) to request access for your organization. + The Sandbox SDK is in public beta. Methods might change before the SDK becomes generally available. Sandboxes are + billed per vCPU-second at the Depot CI compute rate. Run untrusted or agent-generated code in isolated, ephemeral sandboxes: create a sandbox, run commands and stream their output, and work with the sandbox file system through a `node:fs/promises`-shaped interface. Depot provides the following SDK for interacting with the Sandbox API: diff --git a/content/api/sandbox-sdk-reference.mdx b/content/api/sandbox-sdk-reference.mdx index 1e232bb..d1450bd 100644 --- a/content/api/sandbox-sdk-reference.mdx +++ b/content/api/sandbox-sdk-reference.mdx @@ -7,8 +7,8 @@ description: Complete Node.js SDK reference for creating sandboxes, running comm import {NoteCallout} from '~/components/blog/NoteCallout' - The Sandbox SDK is in private beta. Methods might change before the SDK becomes generally available. Sandboxes are - billed per vCPU-second at the Depot CI compute rate. [Contact us](/help) to request access for your organization. + The Sandbox SDK is in public beta. Methods might change before the SDK becomes generally available. Sandboxes are + billed per vCPU-second at the Depot CI compute rate. The [`@depot/sandbox`](https://www.npmjs.com/package/@depot/sandbox) package is the Node.js SDK for Depot sandboxes. It wraps the `depot.sandbox.v1` API with ergonomic classes for creating sandboxes, running commands, streaming command output, and working with a sandbox's file system through a `node:fs/promises`-shaped interface. The source is on GitHub at [`depot/sandbox-sdk`](https://github.com/depot/sandbox-sdk). @@ -94,10 +94,10 @@ const sandbox = await Sandbox.create(client, { Options (`CreateSandboxOpts`): - **name**: an optional name for the sandbox, unique within your organization. -- **runtime**: the runtime to boot into. Custom runtimes aren't available in the beta. Sandboxes boot from Depot's pre-cached default base image. +- **runtime**: the image to boot, specified as `{imageRef: '…'}`. Omit this option to use Depot's default base image. Named runtimes aren't supported. - **resources**: the compute to request, as `{vcpus?, memoryMb?, diskGb?}`, each a positive integer. The server fills a default for any field you omit: 2 vCPUs, 4096 MB of memory, and 100 GB of disk. Sandboxes support 2 to 64 vCPUs. Disk must be large enough to hold the base image, so very small values fail to start. - **env**: environment variables for the sandbox. The server merges these into every command it runs. When a command sets the same variable, the command's value wins. -- **timeoutMinutes**: requested lifetime in minutes, measured from when the sandbox is created (including provisioning time). Defaults to 120 minutes. Our preview currently limits container lifetime to a maximum of 24 hours; please contact us to increase this limit. +- **timeoutMinutes**: requested lifetime in minutes, measured from when the sandbox is created (including provisioning time). Defaults to 120 minutes. The maximum sandbox lifetime is 24 hours. ### Get a sandbox diff --git a/content/cache/authentication.mdx b/content/cache/authentication.mdx index b91893d..a9d0282 100644 --- a/content/cache/authentication.mdx +++ b/content/cache/authentication.mdx @@ -23,6 +23,7 @@ For specific details on how to configure your build tools to authenticate with D - [Bazel](/docs/cache/integrations/bazel) - [Go](/docs/cache/integrations/gocache) - [Gradle](/docs/cache/integrations/gradle) +- [Nx](/docs/cache/integrations/nx) - [Pants](/docs/cache/integrations/pants) - [sccache](/docs/cache/integrations/sccache) - [Turborepo](/docs/cache/integrations/turbo) diff --git a/content/cache/integrations/nx.mdx b/content/cache/integrations/nx.mdx new file mode 100644 index 0000000..b4f0053 --- /dev/null +++ b/content/cache/integrations/nx.mdx @@ -0,0 +1,112 @@ +--- +title: Configure Nx to use Depot Cache +ogTitle: Configure Nx to use Depot Cache +description: Learn how to use Depot remote caching for Nx builds +--- + +[**Nx**](https://nx.dev/) is a build system for monorepos with first-class support for task caching. Nx can share its task cache across machines using a remote cache, so that a task computed once on your laptop or in CI never needs to be re-run anywhere else. + +[**Depot Cache**](/docs/cache/overview) implements Nx's [self-hosted remote cache protocol](https://nx.dev/docs/guides/tasks--caching/self-hosted-caching), so Nx can store and retrieve task outputs from Depot Cache. This cache is accessible from anywhere, both on your local machine and on CI/CD systems. + +**Note:** You need a [Depot API token](/docs/cli/authentication) to authenticate with the cache service. Nx uses the `NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN` environment variable for authentication, which you should set to your Depot API token. + +## Local workstation + +Set two environment variables representing the Depot Cache service endpoint and your API token: + +```shell +export NX_SELF_HOSTED_REMOTE_CACHE_SERVER=https://cache.depot.dev +export NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN= +``` + +After you configure Nx to use Depot Cache, run your tasks as you normally would. Nx automatically communicates with Depot Cache to fetch and reuse any stored task outputs from your previous runs. + +Nx doesn't support sending custom headers to the remote cache, so it can't select an organization for a user token that belongs to multiple organizations. If you're a member of multiple organizations, authenticate with an [organization token](/docs/cache/authentication) instead. + +## Local workstation with containerized builds + +When building Docker images that run Nx tasks locally, your build needs access to Nx's remote cache credentials to benefit from caching. Containerized builds execute in isolated environments that require explicit configuration. + +### Dockerfile configuration + +Update your Dockerfile to configure Depot Cache and mount the token as a secret: + +```dockerfile +# syntax=docker/dockerfile:1 + +# ... other Dockerfile instructions + +# Configure Depot Cache for Nx +ENV NX_SELF_HOSTED_REMOTE_CACHE_SERVER=https://cache.depot.dev + +# Mount the token secret and run build +RUN --mount=type=secret,id=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN,env=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN \ + npx nx run-many -t build +``` + +Adding `# syntax=docker/dockerfile:1` as the first line of your Dockerfile enables mounting secrets as environment variables. + +### Depot CLI + +Set `NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN` to your Depot API token, then run the build: + +```shell +depot build --secret id=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN,env=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN -t your-image:tag . +``` + +### Docker buildx + +```shell +docker buildx build --secret id=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN,env=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN -t your-image:tag . +``` + +## Depot GitHub Actions runners + +[Depot GitHub Actions runners](/docs/github-actions/overview) are pre-configured to use Depot Cache with Nx. Each runner launches with `NX_SELF_HOSTED_REMOTE_CACHE_SERVER` and `NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN` environment variables that include the connection details for Depot Cache. + +You don't need additional configuration. Run your Nx tasks as normal: + +```yaml +jobs: + build: + runs-on: depot-ubuntu-24.04 + steps: + - uses: actions/checkout@v4 + - run: npx nx run-many -t build +``` + +To disable automatic configuration, turn off **Allow Actions jobs to automatically connect to Depot Cache** in your organization settings page. You can then manually configure Nx as described in the Local workstation section. + +## Depot GitHub Actions runners with containerized builds + +When running containerized builds on Depot GitHub Actions runners, your build needs access to Nx's remote cache credentials. These credentials aren't automatically available inside your Docker build environment. + +### `depot/build-push-action` + +Store your Depot API token in a GitHub Secret named `NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN`, then configure your workflow: + +```yaml +- name: Build and push + uses: depot/build-push-action@v1 + with: + context: . + file: ./Dockerfile + push: true + tags: your-image:tag + secrets: | + "NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN=${{ secrets.NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN }}" +``` + +### Docker CLI + +Store your Depot API token in a GitHub Secret named `NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN`, then configure your workflow: + +```yaml +- name: Build + run: | + docker buildx build \ + --secret id=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN,env=NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN \ + -t your-image:tag . + env: + NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN: ${{ secrets.NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN }} +``` diff --git a/content/cache/overview.mdx b/content/cache/overview.mdx index 6b7cc8f..10a12a7 100644 --- a/content/cache/overview.mdx +++ b/content/cache/overview.mdx @@ -1,7 +1,7 @@ --- title: Depot Cache ogTitle: Overview of Depot remote caching -description: Learn how to use Depot remote cache for exponentially faster builds for tools like GitHub Actions, Bazel, Go, Turborepo, sccache, Pants, and Gradle. +description: Learn how to use Depot remote cache for exponentially faster builds for tools like GitHub Actions, Bazel, Go, Turborepo, Nx, sccache, Pants, and Gradle. --- **Depot Cache** is our remote caching service that speeds up your builds by providing incremental builds and accelerated tests, both locally and inside of your favorite CI provider. @@ -10,7 +10,7 @@ One of the biggest benefits of adopting advanced build tools like Bazel is the a ## Supported tools -Depot Cache integrates with build tools that support remote caching like GitHub Actions, Bazel, Go, Turborepo, sccache, Pants, and Gradle. For information about how to configure each tool to use Depot Cache, see the tool documentation: +Depot Cache integrates with build tools that support remote caching like GitHub Actions, Bazel, Go, Turborepo, Nx, sccache, Pants, and Gradle. For information about how to configure each tool to use Depot Cache, see the tool documentation: diff --git a/content/ci/compatibility.mdx b/content/ci/compatibility.mdx index d2e8ec3..3bf09ff 100644 --- a/content/ci/compatibility.mdx +++ b/content/ci/compatibility.mdx @@ -34,6 +34,7 @@ Depot CI executes GitHub Actions YAML workflows. The following tables list GitHu | `on.pull_request.branches` | PR branch filters | ✅ | | `on.pull_request_target` | Pull request triggers from the base branch context | ✅ | | `on.pull_request_review` | Pull request review triggers | ✅ | +| `on.issue_comment` | Comments on issues and pull requests | ✅ | | `on.deployment_status` | Deployment status triggers | ✅ | | `on.*.paths` | Path filters | ✅ | | `on.schedule` | Cron schedule triggers | ✅ | @@ -157,6 +158,22 @@ GitHub only delivers `repository_dispatch` events against your repository's defa | Composite | Composite actions | ✅ | | Docker | Container actions | ✅ | +JavaScript actions that declare `runs.using: node20`, `node16`, or `node12` run on Node.js 24, matching GitHub-hosted runners. Actions that declare `runs.using: node24` are unchanged. To run those actions on Node.js 20 temporarily, set `ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION` to `'true'` in the workflow, job, or step `env`. Depot will remove this opt-out to match GitHub and will announce the date in the [changelog](/changelog). + +This example applies the opt-out to one job: + +```yaml +jobs: + build: + runs-on: depot-ubuntu-24.04 + env: + ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: 'true' + steps: + - uses: actions/checkout@v4 +``` + +This runtime is separate from the `node` on `PATH` that `run:` steps use. + ## GitHub checks Depot CI automatically reports GitHub checks for each job in a workflow run. For more information, see [GitHub checks](/docs/ci/observability/github-checks). diff --git a/content/ci/how-to-guides/coding-agents.mdx b/content/ci/how-to-guides/coding-agents.mdx index 4c7d201..200d1bd 100644 --- a/content/ci/how-to-guides/coding-agents.mdx +++ b/content/ci/how-to-guides/coding-agents.mdx @@ -142,7 +142,7 @@ CI logs can be long. If your agent has a limited context window, truncate logs t ### Polling -`depot ci status` returns immediately. It doesn't block until the run finishes. Agents will naturally poll by calling the status command in a loop. This works fine in practice. +Use `depot ci status --wait` to poll until the run finishes, fails, or is cancelled. The command exits with code `0` for a successful run and code `1` for a failed or cancelled run. Omit `--wait` when the agent needs only the current status. ### Human approval gates diff --git a/content/ci/how-to-guides/manage-secrets-and-variables.mdx b/content/ci/how-to-guides/manage-secrets-and-variables.mdx index 1c62b35..30d046d 100644 --- a/content/ci/how-to-guides/manage-secrets-and-variables.mdx +++ b/content/ci/how-to-guides/manage-secrets-and-variables.mdx @@ -25,7 +25,9 @@ If you're migrating from GitHub Actions, you can import your existing GitHub sec depot ci migrate secrets-and-vars ``` -This creates a one-shot GitHub Actions workflow that reads secrets and variables from your GitHub repository and imports them into Depot CI. See [`depot ci migrate secrets-and-vars`](/docs/cli/reference/depot-ci#depot-ci-migrate-secrets-and-vars) in the CLI reference for details. +By default, the command detects names in `.github/workflows/` and `.depot/workflows/`. It skips secrets named `GITHUB_TOKEN` or `DEPOT_TOKEN`, and variables named `DEPOT_TOKEN`. + +The command creates a local temporary branch with a one-shot workflow and prints a `git push` command. Push the branch within five minutes. The workflow imports the values into Depot CI and removes the temporary remote branch. See [`depot ci migrate secrets-and-vars`](/docs/cli/reference/depot-ci#depot-ci-migrate-secrets-and-vars) in the CLI reference for details. ## Manage secrets diff --git a/content/ci/how-to-guides/manage-workflow-runs.mdx b/content/ci/how-to-guides/manage-workflow-runs.mdx index 4c81c50..3e95164 100644 --- a/content/ci/how-to-guides/manage-workflow-runs.mdx +++ b/content/ci/how-to-guides/manage-workflow-runs.mdx @@ -24,6 +24,8 @@ For usage, see the [`depot ci run` docs](/docs/cli/reference/depot-ci#depot-ci-r When you run `depot ci run` with local changes, the CLI automatically detects the changes and uploads a patch. For any job that has an `actions/checkout` step, the CLI injects a step into each job to apply that patch after checkout. The run reflects your local state without requiring a push. For branches that exist on the remote, the patch contains only unpushed changes. For local-only branches, the patch is relative to the default branch. +A job that calls a reusable workflow has no steps where the CLI can inject the patch. The job runs code from the merge-base commit without your local changes, and the CLI prints a warning. + Each time you run `depot ci run` locally, the CLI uploads a fresh patch, so you can keep iterating until the workflow passes. ## Manually trigger workflows @@ -109,13 +111,21 @@ To check a run's workflows, jobs, and attempt IDs, use `depot ci status`: depot ci status ``` +To wait for the run to complete, add `--wait`: + +```shell +depot ci status --wait +``` + +The command exits with code `0` when the run finishes successfully. It exits with code `1` when the run fails or is cancelled. + 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 -You can retry a failed or cancelled job, or every failed and cancelled job in a workflow, without rerunning the successful jobs. +You can retry a single failed or cancelled job, or retry all failed and cancelled jobs in a workflow. A workflow-level retry also reruns all downstream jobs. ### Retry a failed job from the CLI @@ -131,6 +141,8 @@ Retry every failed and cancelled job in the workflow: depot ci retry --failed ``` +If you retry every failed job, Depot also reruns any jobs downstream of them, including succeeded and skipped jobs. + Include the `--workflow ` flag for runs with multiple workflows. Each retry creates a new attempt. You can see previous attempts with `depot ci status`. @@ -146,7 +158,7 @@ Depot creates a new attempt for that job and queues it immediately. The rest of ## Rerun workflows -After a workflow finishes, you can rerun every job in the workflow from scratch, or retry only the failed and cancelled jobs. See [Retry failed jobs](#retry-failed-jobs)). +After a workflow finishes, you can rerun every job in the workflow from scratch, or retry the failed and cancelled jobs. See [Retry failed jobs](#retry-failed-jobs). ### Rerun a workflow from the CLI @@ -163,7 +175,7 @@ For usage, see the [`depot ci rerun` docs](/docs/cli/reference/depot-ci#depot-ci 1. Go to [Depot CI](https://depot.dev/orgs/_/workflows) and click on the workflow. 2. Do one of the following: - To reset every job to queued and run the entire workflow from scratch, click **Re-run workflow**. - - To retry only the failed and cancelled jobs, along with any skipped jobs that depend on them, click **Re-run failed**. Jobs that already succeeded aren't retried. + - To retry the failed and cancelled jobs plus all downstream jobs, click **Re-run failed**. ## Cancel runs, workflows, or jobs diff --git a/content/ci/how-to-guides/parallel-steps.mdx b/content/ci/how-to-guides/parallel-steps.mdx index bb929a7..0f676cb 100644 --- a/content/ci/how-to-guides/parallel-steps.mdx +++ b/content/ci/how-to-guides/parallel-steps.mdx @@ -10,9 +10,9 @@ Run multiple steps concurrently within a single job on Depot CI to cut job time Instead of running every step in a job sequentially, you can run steps concurrently, wait for all of them to finish, and then continue, all within your workflow configuration YAML. -You use `parallel:` blocks inside `steps:` in your job. Depot CI forks execution at the `parallel:` block, and runs each unit of work, either a single step or an ordered sequence of steps, at the same time. Each step or sequence receives an isolated snapshot of the job's state. Changes in one step or sequence don't affect its siblings. All steps or sequences start from the same job state at the start of the `parallel:` block. +You use `parallel:` blocks inside `steps:` in your job. Depot CI forks execution at the `parallel:` block, and runs each unit of work, either a single step or an ordered sequence of steps, at the same time. When all steps in a parallel group finish, Depot CI merges their state back into the job and moves on to the next step. -When all steps in a parallel group finish, Depot CI merges their state back into the job and moves on to the next step. Step outputs, environment variables, and `$GITHUB_PATH` modifications from all parallel steps and sequences become available from that point forward. Secret masking is the exception: `::add-mask::` in any step or sequence takes effect globally and immediately, including for sibling steps or sequences still running. +Each step or sequence receives an isolated snapshot of the job's step outputs, environment variables and `$GITHUB_PATH`. All steps or sequences start from the same job state at the start of the `parallel:` block. The filesystem is not isolated, so the workspace, `HOME` and the tool cache are all shared. Don't run steps or sequences in parallel if they write to the same files or directories. Secret masking (`::add-mask::`) in any step or sequence takes effect globally and immediately, including for sibling steps or sequences still running. ## Parallel step syntax diff --git a/content/ci/integrations/origin.mdx b/content/ci/integrations/origin.mdx index 300a2ef..6dea4e1 100644 --- a/content/ci/integrations/origin.mdx +++ b/content/ci/integrations/origin.mdx @@ -85,7 +85,10 @@ 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. +4. Copies selected workflows and all other non-symlink files under `.github/workflows/` to `.depot/workflows/`, and copies local actions to `.depot/actions/`. +5. Applies compatibility fixes and adds inline comments for any changes. + +Other files can include helper scripts, configuration files, and non-workflow YAML files. The command preserves their relative paths and permissions, but skips symlinks. `--forge` names the forge that hosts the repository and sends events to Depot CI. This value determines what the `depot ci migrate` command does. @@ -109,10 +112,10 @@ Run these steps from a checkout of the repository you connected. 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. For Origin-hosted repositories, the command also reports [compatibility findings](#origin-compatibility-findings). 4. Import secrets and variables with the command for your repository type: - - **Origin-hosted**: 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. - - **Mirrored from GitHub**: run `depot ci migrate secrets-and-vars --forge=github`. It creates a temporary GitHub Actions workflow and prints its run URL. + - **Origin-hosted**: run `depot ci migrate secrets-and-vars --forge=origin`. + - **Mirrored from GitHub**: run `depot ci migrate secrets-and-vars --forge=github`. - The workflow runs once and imports the values into Depot CI. + Both commands create a local temporary branch with a one-shot workflow and print a `git push` command. Push the branch within five minutes. The workflow imports the values into Depot CI and removes the temporary remote branch. 5. Commit `.depot/workflows/` and merge it into your default branch to activate the workflows. @@ -227,7 +230,7 @@ For a mirrored repository, status checks appear in GitHub rather than Origin. ### Secrets and variables import expires -For an Origin-hosted repository, push the temporary import branch within five minutes. If the window expires, rerun `depot ci migrate secrets-and-vars --forge=origin` to create a new import branch. +Push the temporary import branch within five minutes. If the window expires, rerun `depot ci migrate secrets-and-vars` with the appropriate `--forge` value to create a new import branch. ## Learn more diff --git a/content/ci/observability/depot-ci-test-results.mdx b/content/ci/observability/depot-ci-test-results.mdx index 1e3f344..6c85970 100644 --- a/content/ci/observability/depot-ci-test-results.mdx +++ b/content/ci/observability/depot-ci-test-results.mdx @@ -114,7 +114,7 @@ For trends across all your test runs, open the [Test Results Analytics page](/or Common reasons to open the analytics page: - A test is failing and you want to know if it's a one-off or a recurring problem. The **Most frequent test failures** card ranks tests by failure count, and the **Recent events** table links each failure back to its source run. -- You're hunting flaky tests. The **Possibly flaky tests** card surfaces tests that have both passed and failed on the same commit, picking up reruns triggered from Depot CI. +- You're hunting flaky tests. The **Possibly flaky tests** card surfaces tests that have both passed and failed on the same commit, picking up reruns triggered from Depot CI and retries inside a single job. - A run feels slow and you want to find the bottleneck. The **Test duration trends** chart and **Top 5 slowest tests** list rank by P95 duration so you can target the tests costing the most time. Filter by timeframe (past 7, 30, 60, or 90 days, or month to date), repository, branch, suite, file, class, or test name. Filter state is stored in the URL, so you can share a link to a specific view. For a full breakdown of every section on the page, see [Test results analytics by organization](/docs/observability#test-results-analytics-by-organization). diff --git a/content/ci/observability/github-checks.mdx b/content/ci/observability/github-checks.mdx index 73bead7..b67fb26 100644 --- a/content/ci/observability/github-checks.mdx +++ b/content/ci/observability/github-checks.mdx @@ -5,13 +5,19 @@ description: Depot CI automatically reports workflow job status as GitHub checks hideToc: true --- -GitHub checks are status indicators that show whether CI jobs passed or failed for a given commit. When Depot CI runs a workflow, it automatically reports a check for each job on the corresponding commit. These checks appear in several places in GitHub: +GitHub checks are status indicators that show whether CI jobs passed or failed for a given commit. When Depot CI runs a workflow, it automatically reports job status through checks on the corresponding commit. These checks appear in several places in GitHub: - **Pull requests**: at the bottom of the Conversation tab and in the Checks tab -- **Commits**: from the Commits page, click the status icon (green checkmark, red X, or yellow dot) for any commit see a list of checks +- **Commits**: from the Commits page, click the status icon (green checkmark, red X, or yellow dot) for any commit to see a list of checks -Each check is named after the workflow and job, for example `CI / build` or `Deploy / deploy-production`. You can identify Depot CI checks by the Depot icon in the checks list. As jobs progress, Depot updates the check status in real time. +You can identify Depot CI checks by the Depot icon in the checks list. As jobs progress, Depot updates the check status in real time. + +## Check names + +Depot CI follows GitHub Actions conventions for check names, including checks for reusable workflows and matrix jobs. + +## View and rerun checks To view the job in context of the full run in Depot, click **Details** on a check to open the Depot CI page for the corresponding job. -When you rerun a workflow or retry a failed job, Depot updates the existing check rather than creating a duplicate. +When you rerun a workflow or retry a failed job, Depot reports the new attempt under the same check name. diff --git a/content/ci/overview.mdx b/content/ci/overview.mdx index c7c93df..7efa889 100644 --- a/content/ci/overview.mdx +++ b/content/ci/overview.mdx @@ -91,8 +91,9 @@ Your original `.github/` workflows continue running on GitHub in parallel until
    -
  • Trigger runs, fetch logs, and monitor job status from the [CLI](/docs/cli/reference/depot-ci).
    • +
  • Trigger runs, fetch logs, diagnose failures, retry or cancel work, and monitor job status from the [CLI](/docs/cli/reference/depot-ci).
  • Works for engineers and agents: no GitHub event required to start a local run.
    • +
  • Use the [run-diagnose-fix loop](/docs/ci/how-to-guides/coding-agents) to let a coding agent validate uncommitted changes before it opens or updates a pull request.
@@ -150,7 +151,7 @@ Plans also include [container build](/docs/container-builds/overview) minutes an ## Depot CI sandboxes -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. +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. The default `node` on `PATH` is Node.js 22, the same as GitHub's `ubuntu-24.04` image, and you can use `actions/setup-node` for another version. JavaScript actions run on their own Node.js runtime, described in [Action types](/docs/ci/compatibility#action-types). 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. @@ -220,3 +221,4 @@ Depot CI doesn't provide sandboxes for macOS or Windows. Labels for those runner - [Quickstart for Depot CI](/docs/ci/quickstart) - [Compatibility with GitHub Actions](/docs/ci/compatibility) - [Manage secrets and variables](/docs/ci/how-to-guides/manage-secrets-and-variables) +- [Test AI-generated pull requests in CI](/resources/guides/how-do-i-test-ai-generated-pull-requests-in-ci) diff --git a/content/ci/quickstart.mdx b/content/ci/quickstart.mdx index a4ef87b..0856a27 100644 --- a/content/ci/quickstart.mdx +++ b/content/ci/quickstart.mdx @@ -55,7 +55,10 @@ The command runs a preflight check, then copies and transforms your workflows: 1. Validates authentication and checks that the [Depot Code Access app](#connect-to-github) is installed with the correct permissions. 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. +4. Copies selected workflows and all other non-symlink files under `.github/workflows/` to `.depot/workflows/`, and copies local actions to `.depot/actions/`. +5. Applies compatibility fixes and adds inline comments for any changes. + +Other files can include helper scripts, configuration files, and non-workflow YAML files. The command preserves their relative paths and permissions, but skips symlinks. After migration, the command reports any secrets and variables referenced by the migrated workflows. To import them, see [Import secrets and variables](#import-secrets-and-variables) below. @@ -73,7 +76,9 @@ If your workflows reference GitHub secrets or variables, run `depot ci migrate s depot ci migrate secrets-and-vars ``` -This command creates a temporary GitHub Actions workflow that reads your existing GitHub secrets and variables and imports them into Depot CI. The workflow runs once and then you can delete it. The command prints a GitHub Actions run URL where you can monitor the workflow progress. +By default, the command detects names in `.github/workflows/` and `.depot/workflows/`. It skips secrets named `GITHUB_TOKEN` or `DEPOT_TOKEN`, and variables named `DEPOT_TOKEN`. + +The command creates a local temporary branch with a one-shot workflow and prints a `git push` command. Push the branch within five minutes. The workflow imports the values into Depot CI and removes the temporary remote branch. `depot ci migrate secrets-and-vars` is the fastest path if you have many secrets. You can also add secrets and variables manually using the CLI or dashboard. See [Manage secrets and variables](/docs/ci/how-to-guides/manage-secrets-and-variables) for details. diff --git a/content/cli/reference/depot-ci.mdx b/content/cli/reference/depot-ci.mdx index 1cb9e9a..b5f4027 100644 --- a/content/cli/reference/depot-ci.mdx +++ b/content/cli/reference/depot-ci.mdx @@ -80,7 +80,7 @@ depot ci migrate workflows 2. Analyzes each workflow for compatibility with Depot CI. 3. Prompts you to select which workflows to migrate. 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/`. +5. Copies selected workflows and all other non-symlink files under `.github/workflows/` to `.depot/workflows/`, and copies 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. @@ -90,8 +90,11 @@ depot ci migrate workflows | Source | Destination | | ---------------------------------- | --------------------------------- | | `.github/workflows/.yml` | `.depot/workflows/.yml` | +| `.github/workflows/` | `.depot/workflows/` | | `.github/actions/` | `.depot/actions/` | +Other files can include helper scripts, configuration files, and non-workflow YAML files. The command preserves their relative paths and permissions, but skips symlinks. + #### Flags | Flag | Description | @@ -125,7 +128,9 @@ Creates a one-shot GitHub Actions workflow that reads secrets and variables from depot ci migrate secrets-and-vars ``` -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. +By default, the command detects names in `.github/workflows/` and `.depot/workflows/`. It skips secrets named `GITHUB_TOKEN` or `DEPOT_TOKEN`, and variables named `DEPOT_TOKEN`. + +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, imports your existing secrets and variables into Depot CI, and removes the temporary remote branch. With `--forge=origin`, the command detects the Origin remote instead of a GitHub remote, and reads the values from that repository. @@ -151,7 +156,9 @@ Submits a workflow to Depot CI and starts a run against your local working tree, depot ci run --workflow .depot/workflows/ci.yml ``` -If you have local changes relative to your branch's remote state, the CLI automatically detects them, uploads a patch to Depot Cache, and injects a patch-application step after `actions/checkout` in each selected job. For branches that exist on the remote, the patch contains only unpushed changes. For local-only branches, the patch is relative to the default branch. +If you have local changes relative to your branch's remote state, the CLI automatically detects them and uploads a patch to Depot Cache. The CLI injects a patch-application step into each selected job that contains an `actions/checkout` step. For branches that exist on the remote, the patch contains only unpushed changes. For local-only branches, the patch is relative to the default branch. + +The CLI detects GitHub and Origin repositories from your git remotes. Use `--forge` when the remotes contain repositories from both forges. When you use `--repo` for an Origin repository without a detectable Origin remote, also pass `--forge=origin`. ### Flags @@ -162,7 +169,8 @@ If you have local changes relative to your branch's remote state, the CLI automa | `--ssh` | Start the run and connect to the job's sandbox via interactive terminal. Requires exactly one `--job`. | | `--ssh-after-step ` | Insert an SSH debug session (via tmate) after the nth step (1-based). Requires exactly one `--job`. | | `--follow`, `-f` | Stream the triggered run's logs once it starts. Cannot be combined with `--ssh` or `--ssh-after-step`. | -| `--repo ` | GitHub repository to use instead of detecting from git remotes | +| `--repo ` | Repository to use instead of detecting one from git remotes | +| `--forge ` | Repository forge, `github` or `origin` | | `--org ` | Organization ID (required when user is a member of multiple organizations) | | `--token ` | Depot API token | @@ -206,6 +214,8 @@ When you request a single `--job`, the command follows that job's logs. Otherwis When you run `depot ci run` with local changes, the CLI automatically detects the changes and uploads a patch. For any job that has an `actions/checkout` step, the CLI injects a step into each job to apply that patch after checkout. The run reflects your local state without requiring a push. For branches that exist on the remote, the patch contains only unpushed changes. For local-only branches, the patch is relative to the default branch. +A job that calls a reusable workflow has no steps where the CLI can inject the patch. The job runs code from the merge-base commit without your local changes, and the CLI prints a warning. + Each time you run `depot ci run` locally, the CLI uploads a fresh patch, so you can keep iterating until the workflow passes. --- @@ -469,7 +479,8 @@ The command prints: - Org, repo, run ID with status, workflow ID with status, name, path, ref, SHA, and trigger. - Each execution with its status, start time, finish time, and duration. -- Each job with its status and duration. For each job, the command shows the latest attempt's ID, status, sandbox ID, session ID, and a ready-to-run `depot ci logs` command. If the job has more than one attempt, all attempts are listed. +- Each job with its display name, status, and duration. The command shows the job key when the workflow doesn't define a display name. +- Each job's latest attempt with its ID, status, sandbox ID, session ID, and a ready-to-run `depot ci logs` command. If the job has more than one attempt, the command lists all attempts. ##### Show a workflow as JSON: @@ -509,6 +520,8 @@ JSON response: } ``` +Each object in `jobs` includes `job_display_name` and `job_key`. When the workflow doesn't define a display name, both fields contain the job key. + --- ## `depot ci dispatch` @@ -575,19 +588,34 @@ Replace `` with the run ID returned by `depot ci run` or visible in the - The organization and run ID with the overall run status. - Each workflow in the run, with its status and workflow file path. -- Each job within a workflow, with its job ID, key, and status. +- Each job within a workflow, with its job ID, display name, and status. The command shows the job key when the workflow doesn't define a display name. - Each attempt within a job, with its attempt ID, attempt number, and status. Plus a ready-to-run `depot ci logs` command, a link to the attempt in the Depot dashboard, and (when applicable) `depot ci ssh` and log download commands. +Pass `--wait` to poll every five seconds until the run finishes, fails, or is cancelled. Progress updates go to stderr, and the final status goes to stdout. The command exits with code `0` for a finished run and code `1` for a failed or cancelled run. + ### Flags | Flag | Description | | --------------------- | -------------------------------------------------------------------------- | +| `--wait` | Wait for the run to finish, fail, or be cancelled | | `--output json`, `-o` | Output as JSON instead of the hierarchical text view | | `--org ` | Organization ID (required when user is a member of multiple organizations) | | `--token ` | Depot API token | ### Examples +#### Wait for the run to complete + +```bash +depot ci status --wait +``` + +To wait for completion and print the final status as JSON, run: + +```bash +depot ci status --wait --output json +``` + #### Show the status as JSON ```bash @@ -609,6 +637,7 @@ JSON response: "name": "CI", "jobs": [ { + "job_display_name": "Test", "job_id": "", "job_key": "ci.yml:test", "status": "running", @@ -770,7 +799,7 @@ JSON response: ## `depot ci retry` -Retries a single failed or cancelled job, or every failed and cancelled job in a workflow. +Retries a single failed or cancelled job, or all failed and cancelled jobs in a workflow plus downstream jobs. ```bash depot ci retry --job @@ -780,20 +809,20 @@ depot ci retry --failed Requires exactly one of `--job` or `--failed`. - `--job ` retries a single job. The workflow containing the job is resolved automatically from the run's status. -- `--failed` retries every failed/cancelled job in the workflow. If the run contains multiple workflows, pass `--workflow `; otherwise the single workflow is resolved automatically. +- `--failed` retries all failed/cancelled jobs in the workflow, plus all downstream jobs. If the run contains multiple workflows, pass `--workflow `; otherwise the single workflow is resolved automatically. Each retry creates a new attempt for the selected job(s); the previous attempts are preserved and visible in `depot ci status`. ### Flags -| Flag | Description | -| --------------------- | ---------------------------------------------------------------------------------- | -| `--job ` | Job ID to retry (mutually exclusive with `--failed`) | -| `--failed` | Retry every failed/cancelled job in the workflow (mutually exclusive with `--job`) | -| `--workflow ` | Workflow ID; required with `--failed` when the run has multiple workflows | -| `--output json`, `-o` | Output the RPC response as JSON | -| `--org ` | Organization ID (required when user is a member of multiple organizations) | -| `--token ` | Depot API token | +| Flag | Description | +| --------------------- | -------------------------------------------------------------------------------------------------------------- | +| `--job ` | Job ID to retry (mutually exclusive with `--failed`) | +| `--failed` | Retry all failed or cancelled jobs in the workflow, plus all downstream jobs (mutually exclusive with `--job`) | +| `--workflow ` | Workflow ID; required with `--failed` when the run has multiple workflows | +| `--output json`, `-o` | Output the RPC response as JSON | +| `--org ` | Organization ID (required when user is a member of multiple organizations) | +| `--token ` | Depot API token | ### Examples diff --git a/content/code/overview.mdx b/content/code/overview.mdx index d3541fc..5f6fb69 100644 --- a/content/code/overview.mdx +++ b/content/code/overview.mdx @@ -94,7 +94,7 @@ Depot Code inverts the primitive. Git packfiles and their indexes become objects Depot Code repositories will initiate `push` triggers for Depot CI workflows defined in `.depot/workflows/`. Depot Code repositories currently do not initiate triggers of any other type. When you push to a Depot Code repository, Depot CI runs every workflow with an `on: push` trigger against the pushed commit. Each new commit included in a push starts its own set of runs. -Additionally, Depot CI triggers are currently disabled by default for standalone repos. Many workflow scripts contain subtle dependencies on GitHub and require workarounds. Please reach out to opt-in to Depot CI triggers for standalone repos. +Depot Code and Depot CI push triggers for standalone repositories are enabled by default for all organizations. Workflows that depend on GitHub-specific features may require changes; see the [Depot CI compatibility reference](/docs/ci/compatibility). ## Pricing diff --git a/content/code/quickstart.mdx b/content/code/quickstart.mdx index cded26a..cea44d8 100644 --- a/content/code/quickstart.mdx +++ b/content/code/quickstart.mdx @@ -15,7 +15,7 @@ Create a Git repository hosted on Depot's diskless Git server, then clone, push, ## Prerequisites -- A [Depot account](https://depot.dev/sign-up) with Depot Code enabled for your organization. +- A [Depot account](https://depot.dev/sign-up). - [Git](https://git-scm.com/) installed locally. - Optional: [Connect to GitHub](https://depot.dev/docs/ci/quickstart#connect-to-github) if you want to create a mirror repository in Depot Code. Check for an existing connection in your organization [**Settings**](/orgs/_/settings) under **GitHub Code Access**. @@ -71,6 +71,6 @@ Depot Code repositories work with [Depot CI](/docs/ci/overview). To run CI, add Depot Code workflows support the `push` trigger only. When you push, Depot CI runs every workflow with an `on: push` trigger against the pushed commit. -Note: Depot CI triggers are currently disabled by default for standalone repos. Many workflow scripts contain subtle dependencies on GitHub and require workarounds. Please reach out to opt-in to Depot CI triggers for standalone repos. +Depot Code and Depot CI push triggers for standalone repositories are enabled by default for all organizations. Workflows that depend on GitHub-specific features may require changes. For workflow syntax and supported features, see the [Depot CI quickstart](/docs/ci/quickstart) and [compatibility reference](/docs/ci/compatibility). diff --git a/content/environment-variables.mdx b/content/environment-variables.mdx index a60ff6f..6dc514c 100644 --- a/content/environment-variables.mdx +++ b/content/environment-variables.mdx @@ -49,17 +49,19 @@ It does not include Depot service-internal variables or CI provider runtime vari These variables are useful when configuring build tools to use Depot Cache. Some are set by users for specific tools, and others are injected automatically in Depot CI jobs and Depot GitHub Actions runner jobs. -| Variable | Products | Description | -| ------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | -| `GOCACHEPROG` | Depot Cache, Depot CI, GitHub Actions runners | Go cache program hook. Set it to `depot gocache` to use Depot Cache for Go builds. | -| `SCCACHE_WEBDAV_ENDPOINT` | Depot Cache, Depot CI, GitHub Actions runners | WebDAV endpoint used by `sccache` to read and write cache entries in Depot Cache. | -| `SCCACHE_WEBDAV_TOKEN` | Depot Cache, Depot CI, GitHub Actions runners | Bearer-style token used by `sccache` with `SCCACHE_WEBDAV_ENDPOINT`. | -| `SCCACHE_WEBDAV_USERNAME` | Depot Cache | Username-style `sccache` auth value. Use the Depot organization ID when configuring this manually. | -| `SCCACHE_WEBDAV_PASSWORD` | Depot Cache | Password-style `sccache` auth value. Use a Depot user or organization token when configuring this manually. | -| `TURBO_API` | Depot Cache, Depot CI, GitHub Actions runners | Turborepo remote cache endpoint. | -| `TURBO_TEAM` | Depot Cache, Depot CI, GitHub Actions runners | Turborepo team value. In Depot CI jobs and Depot GitHub Actions runner jobs, this is set to the Depot organization ID. | -| `TURBO_TEAMID` | Depot Cache, Depot CI, GitHub Actions runners | Turborepo team ID alias. In Depot CI jobs and Depot GitHub Actions runner jobs, this is set to the Depot organization ID. | -| `TURBO_TOKEN` | Depot Cache, Depot CI, GitHub Actions runners | Turborepo remote cache auth token. | +| Variable | Products | Description | +| ------------------------------------------ | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | +| `GOCACHEPROG` | Depot Cache, Depot CI, GitHub Actions runners | Go cache program hook. Set it to `depot gocache` to use Depot Cache for Go builds. | +| `SCCACHE_WEBDAV_ENDPOINT` | Depot Cache, Depot CI, GitHub Actions runners | WebDAV endpoint used by `sccache` to read and write cache entries in Depot Cache. | +| `SCCACHE_WEBDAV_TOKEN` | Depot Cache, Depot CI, GitHub Actions runners | Bearer-style token used by `sccache` with `SCCACHE_WEBDAV_ENDPOINT`. | +| `SCCACHE_WEBDAV_USERNAME` | Depot Cache | Username-style `sccache` auth value. Use the Depot organization ID when configuring this manually. | +| `SCCACHE_WEBDAV_PASSWORD` | Depot Cache | Password-style `sccache` auth value. Use a Depot user or organization token when configuring this manually. | +| `NX_SELF_HOSTED_REMOTE_CACHE_SERVER` | Depot Cache, Depot CI, GitHub Actions runners | Nx self-hosted remote cache endpoint. | +| `NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN` | Depot Cache, Depot CI, GitHub Actions runners | Nx self-hosted remote cache auth token. | +| `TURBO_API` | Depot Cache, Depot CI, GitHub Actions runners | Turborepo remote cache endpoint. | +| `TURBO_TEAM` | Depot Cache, Depot CI, GitHub Actions runners | Turborepo team value. In Depot CI jobs and Depot GitHub Actions runner jobs, this is set to the Depot organization ID. | +| `TURBO_TEAMID` | Depot Cache, Depot CI, GitHub Actions runners | Turborepo team ID alias. In Depot CI jobs and Depot GitHub Actions runner jobs, this is set to the Depot organization ID. | +| `TURBO_TOKEN` | Depot Cache, Depot CI, GitHub Actions runners | Turborepo remote cache auth token. | ## Depot CI diff --git a/content/github-actions/observability/github-actions-metrics.mdx b/content/github-actions/observability/github-actions-metrics.mdx index 1d4c2fd..7b59665 100644 --- a/content/github-actions/observability/github-actions-metrics.mdx +++ b/content/github-actions/observability/github-actions-metrics.mdx @@ -75,3 +75,16 @@ Once you've identified problematic jobs or patterns in the metrics, investigate - Use the [Logs page](/docs/github-actions/observability/github-actions-logs) to search for error messages and keywords across failed job runs. The logs page supports filtering by repository, workflow, and time range to help you find relevant failures. - Refer to the [Troubleshooting guide](/docs/github-actions/troubleshooting) for solutions to common errors like disk space issues, connectivity problems, memory exhaustion, and runner allocation failures. + +## Export analytics + +Export GitHub Actions analytics as CSV or JSON to share reports with your team or analyze the data in your own tools. + +1. Open your organization's [GitHub Actions Analytics page](/orgs/_/github-actions/analytics). +2. Select the timeframe and filters you want to include in the export. +3. Click **Export** next to **Insights** in the upper right. +4. Choose **Export CSV files (.zip)** for spreadsheets or **Export JSON files (.zip)** for scripts and other tools. + +The download is a ZIP containing a separate file for each analytics table. It includes overview comparisons, job duration and failure summaries and trends, daily activity, and CPU and memory metrics. The **Report details** file records the reporting periods and active filters, so you can identify which data the export covers. + +Exports reflect the current dashboard view. Daily successful and failed minute breakdowns are labeled as estimates, calculated from each day's total elapsed time and job counts. diff --git a/content/github-actions/overview.mdx b/content/github-actions/overview.mdx index 41cda58..8c4520c 100644 --- a/content/github-actions/overview.mdx +++ b/content/github-actions/overview.mdx @@ -1,14 +1,14 @@ --- title: Depot GitHub Actions runners ogTitle: Overview of Depot GitHub Action runners -description: Overview of Depot GitHub Actions runners, a drop-in replacement for your existing runners in any GitHub Actions job. Depot runners are up to 3x faster with 10x faster caching at half the cost of GitHub hosted runners per minute. We have runners for Linux, Windows, and macOS. +description: Overview of Depot GitHub Actions runners, a drop-in replacement for your existing runners in any GitHub Actions job. Depot runners are up to 3x faster with 10x faster caching. We have runners for Linux, Windows, and macOS. --- import {CTA} from '~/components/marketing/post/common/PostCTA' Depot GitHub Actions runners are a drop-in replacement for your existing runners in any GitHub Actions job. Our [runners](/docs/github-actions/runner-types) are up to 3x faster than a GitHub-hosted runner. Depot runners are integrated into our cache orchestration system, so you also get 10x faster caching without having to change anything in your jobs. -To use Depot runners, your repository must be owned by a GitHub organization (not a personal account). +Due to a GitHub limitation, Depot GitHub Actions runners only support repositories owned by GitHub organizations. [Depot CI](/docs/ci/overview) supports repositories owned by both GitHub organizations and personal accounts. ## Switching to Depot @@ -231,7 +231,6 @@ For per-minute pricing, see [GitHub Actions runner types](/docs/github-actions/r - Faster compute: Up to 3x faster than standard GitHub-hosted runners. - Up to 10x faster caching: Integrated with Depot's cache orchestration system. -- Cost-effective: Half the cost of GitHub-hosted runners, billed by the second. - Variety of runner types: Support for Intel (x86), ARM, macOS, Windows, and GPU-enabled runners (Business plan only). - No concurrency limits: Run as many jobs as you want in parallel. @@ -274,7 +273,7 @@ See [GitHub Actions runner types](/docs/github-actions/runner-types). - Depot runners are half the cost of GitHub-hosted runners. Each plan comes with a set of included minutes as follows: + Each plan comes with a set of included minutes as follows: - Developer plan: 2,000 minutes included, $0.006/minute after - Startup plan: 20,000 minutes included, $0.006/minute after diff --git a/content/observability.mdx b/content/observability.mdx index c4c160f..d6bf61a 100644 --- a/content/observability.mdx +++ b/content/observability.mdx @@ -75,7 +75,7 @@ Every section on the page reflects the current timeframe and filters. The timefr | Failure rates by suite | Top 5 suites by combined failure and error rate | | Most frequent test failures | Top 5 recurring failures by failure count, grouped by test and failure signature | | New failures | Failures whose signature didn't appear in the 90 days before the timeframe, with the date each was first seen | -| Possibly flaky tests | Tests that both passed and failed across reruns of the same commit SHA, ranked by rerun count | +| Possibly flaky tests | Tests that both passed and failed on the same commit SHA, from reruns or retries within a job | | Recent events | The 10 most recent failed or errored test events, newest first, with links back to the originating job | | Test duration distribution | Timed test results bucketed by duration, from under 1 second to over 5 minutes | | Top 5 slowest tests | Individual tests ranked by P95 duration |