You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To list the steps for a build, you need to pass the build ID, the project ID, the number of steps to page, and an optional page token returned from a previous API call.
To get the logs for a build step, you need to pass the build ID, the project ID, and the build step's digest. You can also pass the number of lines to page and an optional page token returned from a previous API call.
The Registry service provides access to the underlying registry that stores the images built by Depot. You can use this service to list and delete images.
282
312
283
-
### List the images for a project
313
+
####List the images for a project
284
314
285
315
To list the images for a project, you need to pass the ID of the project you want to list the images for. When listing more than 100 images, you can use the `pageSize` and `pageToken` fields to paginate the results.
@@ -48,6 +48,21 @@ The Dagger CLI will be available and pre-authenticated with your Dagger Cloud to
48
48
49
49
With these steps, your workflow is now ready to run on Depot’s accelerated infrastructure using Dagger and GitHub Actions.
50
50
51
+
## How does it work?
52
+
53
+
Using Dagger engines via Depot GitHub Actions Runners allows you to execute your Dagger pipelines and functions inside of a dedicated VM with a persistent NVMe device for cache storage that lives next to the GitHub Actions runners without having to do any additional configuration outside of the above.
54
+
55
+
### Architecture
56
+
57
+

58
+
59
+
The general architecture allows for fast persistent cache for your Dagger projects automatically across builds. Here is the flow of information and what happens at each step when you specify `runs-on: depot-ubuntu-latest,dagger=<version>` in your GitHub Actions workflow:
60
+
61
+
1. The Depot control plane receives the request for your GitHub Actions job and takes note of your request for a Dagger engine as well. We launch the Dagger Engine VM at the specified version next to your GitHub Actions runner, attaching your cache volume from previous builds to that VM. We then tell the GitHub Actions runner to pre-configure the GitHub Actions environment, installing the specific `dagger` CLI version for you and point it at the Dagger Engine running next door, and automatically authenticate to your Dagger Cloud account for logs and telemetry.
62
+
2. The GitHub Actions runner starts up and runs the job, which includes the Dagger CLI. The Dagger CLI is pre-configured to use the Dagger Engine running next door, the `dagger` step is thus kicked off on the separate Dagger Engine VM with it's persistent cache. The Dagger execution runs to completion and logs + telemetry are shipped to your Dagger Cloud account.
63
+
3. The Dagger Engine VM is automatically shut down after the job completes, and the cache volume is detached from the VM and returned to Depot's control plane for future use.
64
+
4. The GitHub Actions runner completes the job and returns the results to GitHub.
65
+
51
66
## Pricing
52
67
53
68
Dagger engines accessed via our GitHub Actions Runners are charged by the build minute at $0.04/minute, in addition to the GitHub Actions Runner build time.
_Note: We do our best to keep our images in sync with GitHub's, but there may be a slight delay between when GitHub updates their images and when we update ours. If you need a specific version of a tool or software, please check the links above to see if it's available in the image you're using._
0 commit comments