Skip to content

Commit

Permalink
Update docs content from https://github.com/depot/app
Browse files Browse the repository at this point in the history
  • Loading branch information
KyleTryon authored and github-actions[bot] committed Jan 13, 2025
1 parent a86342f commit ca75c4a
Show file tree
Hide file tree
Showing 6 changed files with 58 additions and 4 deletions.
2 changes: 1 addition & 1 deletion content/container-builds/how-to-guides/arm-containers.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ Depot removes emulation altogether.

Depot is a remote Docker container build service that orchestrates optimized BuildKit builders on native CPUs for Intel (x86) and Arm (arm64).

When a Docker image build is routed to Depot either via [`depot build`](/docs/cli/reference#depot-build) or [`docker build`](/docs/container-builds/how-to-guides/docker-build#how-to-use-depot-with-docker), we launch optimized builders for each architecture requested with a persistent layer cache attached to them. Each builder has 16 CPUs, 32GB of memory, and at least 50GB of fast NVMe cache SSDs.
When a Docker image build is routed to Depot either via [`depot build`](/docs/cli/reference#depot-build) or [`docker build`](/docs/container-builds/how-to-guides/docker-build#how-to-use-depot-with-docker), we launch optimized builders for each architecture requested with a persistent layer cache attached to them. Each image builder, by default, has 16 CPUs and 32GB of memory. If you're on a startup or business plan, you can configure your builders to be larger, with up to 64 CPUs and 128 GB of memory. Each builder also has a fast NVMe SSD with at least 50GB for layer caching.

## How to build Docker images for Arm CPUs like M1/M2 MacBooks or AWS Graviton

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ Depot provides a remote Docker build service that makes the image build process

By routing the image build step of your CI to Depot, you can complete the image build up to 40x faster than you could in your generic CI provider. Saving you build minutes in your existing CI provider and, more importantly, saving you developer time waiting for the build to finish.

The `depot build` command is a drop-in replacement for `docker build` and `docker buildx build`. Alternatively, you can [configure your local Docker CLI to use Depot as the default builder](/docs/container-builds/how-to-guides/docker-build). Depot launches remote builders for both native Intel & Arm CPUs with 16 CPUs, 32 GB of memory, and a 50 GB persistent NVMe cache SSD.
The `depot build` command is a drop-in replacement for `docker build` and `docker buildx build`. Alternatively, you can [configure your local Docker CLI to use Depot as the default builder](/docs/container-builds/how-to-guides/docker-build). Depot launches remote builders for both native Intel & Arm CPUs with, by default, 16 CPUs, 32 GB of memory, and a 50 GB persistent NVMe cache SSD. On a startup or business plan, in your project settings, you can configure your builders to be larger, with up to 64 CPUs and 128 GB of memory.

Running `depot` in a continuous integration environment is a great way to get fast and consistent builds with any CI provider. See below for documentation on integrating Depot with your CI provider.

Expand Down
4 changes: 2 additions & 2 deletions content/container-builds/overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ Take a look at the [quickstart](/docs/container-builds/quickstart) to get starte

A remote container build runs on an ephemeral EC2 instance running an optimized version of BuildKit. We launch a builder on-demand in response to your `depot build` command and terminate it when the build is complete. You only pay for the compute you use, and builders are never shared across Depot customers or projects.

Each image builder has 16 CPUs, 32GB of memory, and a fast NVMe SSD for layer caching. The SSD is 50GB by default but can be expanded up to 500GB.
Each image builder, by default, has 16 CPUs, 32GB of memory. If you're on a startup or business plan, you can configure your builders to be larger, up to 64 CPUs and 128 GB of memory. Each builder also has a fast NVMe SSD for layer caching. The SSD is 50GB by default but can be expanded up to 500GB.

### Native Intel & Arm builds

Expand Down Expand Up @@ -78,7 +78,7 @@ We offer a built-in ephemeral registry that you can use to save the images from

Container builds must be associated with a project in your organization. Projects usually represent a single application, repository, or Dockerfile. Once you've made your project, you can leverage Depot builders from your local machine or an existing CI workflow by swapping `docker` for `depot`.

Builder instances come with 16 CPUs, 32GB of memory, and an SSD disk for layer caching (the default size is 50GB, but you can expand this up to 500GB). A builder instance runs an optimized version of [BuildKit](https://github.com/moby/buildkit), the advanced build engine that backs Docker.
By default, builder instances come with 16 CPUs and 32GB of memory. If you're on a startup or business plan, you can configure your builders to be larger in project settings, with up to 64 CPUs and 128 GB of memory. Each builder also comes with an SSD disk for layer caching (the default size is 50GB, but you can expand this up to 500GB). A builder instance runs an optimized version of [BuildKit](https://github.com/moby/buildkit), the advanced build engine that backs Docker.

We offer native Intel and Arm builder instances for all projects. Hence, both architectures build with zero emulation, and you don't have to run your own build runners to get native multi-platform images.

Expand Down
1 change: 1 addition & 0 deletions content/container-builds/reference/api-overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -90,6 +90,7 @@ const result = await depot.core.v1.ProjectService.updateProject(
name: 'my-project',
regionId: 'us-east-1',
cachePolicy: {keepBytes: 50 * 1024 * 1024 * 1024, keepDays: 14},
hardware: Hardware.HARDWARE_32X64,
},
{headers},
)
Expand Down
4 changes: 4 additions & 0 deletions content/github-actions/overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,10 @@ We can run our optimized runners in our cloud or your AWS account for additional

If you use Depot for faster Docker image builds via our [remote container builds](/docs/container-builds/overview), your BuildKit builder runs right next to your managed GitHub Action runner, allowing for faster CI builds by mimizing network latency and data transfer.

### Integrates with Dagger Cloud

[Connect with Dagger Cloud](/docs/github-actions/reference/dagger) and run your Dagger Engine builds on Depot's [Ultra Runners for GitHub Actions](/products/github-actions) with our accelerated cache enabled.

## Pricing

#### Runners
Expand Down
49 changes: 49 additions & 0 deletions content/github-actions/reference/dagger.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
title: Dagger
ogTitle: Run your Dagger Engine builds with Depot Runners for GitHub Actions.
description: Accelerate your Dagger Engine builds with Depot Runners
---

Connect with Dagger Cloud and run your Dagger Engine builds on Depot's [Ultra Runners for GitHub Actions](/products/github-actions) with our accelerated cache enabled.

## Authentication

Accessing Dagger Engines in Depot requires that you connect Depot to your Dagger Cloud account and access the Engine via Depot GitHub Actions Runners.

### Connect to Dagger Cloud

From the [Dagger Cloud](https://dagger.cloud/) UI, generate a [Dagger Cloud token](https://docs.dagger.io/configuration/cloud) and copy it to your clipboard.

<img class="mx-auto h-auto max-w-[500px]" src="/images/integrations/dagger-cloud-token-setup.webp" />

From your [Depot Dashboard](/orgs), you will see "Dagger" listed in the left-hand navigation under "CI Runners". Click on "Dagger" and in the top right corner you will see the "Add Token" button. Add your token, and you should see a message that you have successfully connected.

<img class="mx-auto" src="/images/integrations/connect-to-dagger-cloud.webp" />

### Connect to GitHub

Finally, ensure you are connected to GitHub. Under the "CI Runners" section, click on "GitHub Actions" and connect your GitHub account. You will be prompted to connect with your GitHub organization and specify all or specific repositories to enable access to Depot Runners.

## Configuration

In your GitHub Actions workflow, you can specify both the [**Depot Runner** label](/docs/github-actions/runner-types) and the **Dagger Engine** version directly in the `runs-on` key using a comma-separated format. `<depot-runner-label>,dagger=<dagger-version>`.

```yaml {6}
name: dagger
on: push

jobs:
build:
runs-on: depot-ubuntu-22.04,dagger=0.15.1
steps:
- uses: actions/checkout@v4
- run: dagger -m github.com/kpenfound/dagger-modules/[email protected] call \
build --source=https://github.com/dagger/dagger --args=./cmd/dagger \
export --path=./build
```
You can locate the latest Dagger Engine release version and all potentially breaking changes in the [Dagger Engine Changelog](https://github.com/dagger/dagger/blob/main/CHANGELOG.md).
The Dagger CLI will be available and pre-authenticated with your Dagger Cloud token. Once a Dagger request is made, Depot initializes a new Dagger project for that repository without additional configuration.
With these steps, your workflow is now ready to run on Depot’s accelerated infrastructure using Dagger and GitHub Actions.

0 comments on commit ca75c4a

Please sign in to comment.