Update docs content from https://github.com/depot/app

Author: jacobwgillespie

content/cli/installation.mdx

@@ -25,7 +25,7 @@ Either install with [our installation script](https://depot.dev/install-cli.sh):
 curl -L https://depot.dev/install-cli.sh | sh
 
 # Install a specific version
-curl -L https://depot.dev/install-cli.sh | sh -s 1.6.0
+curl -L https://depot.dev/install-cli.sh | sh -s x.y.z
 ```
 
 Or download the latest version from [GitHub releases](https://github.com/depot/cli/releases).

content/container-builds/reference/api-overview.mdx

@@ -274,6 +274,36 @@ const headers = {Authorization: `Bearer ${process.env.DEPOT_TOKEN}`}
 await depot.build.v1.BuildService.finishBuild({buildId: 'build-id', result: {error: 'error message'}}, {headers})
 ```
 
+#### List the steps for a build
+
+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.
+
+```typescript
+const headers = {Authorization: `Bearer ${process.env.DEPOT_TOKEN}`}
+const result = await depot.build.v1.BuildService.getBuildSteps(
+  {buildId: 'build-id', projectId: 'project-id', pageSize: 100, pageToken: 'page-token'},
+  {headers},
+)
+```
+
+#### Get the logs for a build step
+
+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.
+
+```typescript
+const headers = {Authorization: `Bearer ${process.env.DEPOT_TOKEN}`}
+const result = await depot.build.v1.BuildService.getBuildStepLogs(
+  {
+    buildId: 'build-id',
+    projectId: 'project-id',
+    buildStepDigest: 'step-digest',
+    pageSize: 100,
+    pageToken: 'page-token',
+  },
+  {headers},
+)
+```
+
 ### Registry Service
 
 Docs: [`depot.build.v1.RegistryService`](https://buf.build/depot/api/docs/main:depot.build.v1#depot.build.v1.RegistryService)

content/github-actions/reference/dagger.mdx

@@ -34,7 +34,7 @@ on: push
 
 jobs:
   build:
-    runs-on: depot-ubuntu-22.04,dagger=0.15.2
+    runs-on: depot-ubuntu-latest,dagger=0.18.4
   steps:
     - uses: actions/checkout@v4
     - run: dagger -m github.com/kpenfound/dagger-modules/golang@v0.2.0 call \
@@ -48,6 +48,21 @@ The Dagger CLI will be available and pre-authenticated with your Dagger Cloud to
 
 With these steps, your workflow is now ready to run on Depot’s accelerated infrastructure using Dagger and GitHub Actions.
 
+## How does it work?
+
+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.
+
+### Architecture
+
+![Depot GitHub Actions Runners with Dagger architecture](/images/dagger-arch-diagram.png)
+
+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:
+
+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.
+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.
+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.
+4. The GitHub Actions runner completes the job and returns the results to GitHub.
+
 ## Pricing
 
 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.

content/github-actions/runner-types.mdx

@@ -116,3 +116,14 @@ Note that on your Billing summary, costs are broken down by `Billed minutes` and
 - `Billed minutes` multiples the `Minutes multiplier` (from the table above) by the `Elapsed minutes`.
 - The rate at which `Billed minutes` accumulates is based on the size of the `Minutes multiplier`.
 - What you pay is the total `Billed minutes` minus the included minutes of your plan.
+
+## What software and tools are included?
+
+If you'd like to see what tools and software are installed in each runner image, please see the links to the `README` in GitHub's repository:
+
+- [`depot-ubuntu-24.04`](https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md) and `depot-ubuntu-latest`
+- [`depot-ubuntu-22.04`](https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md)
+- [`depot-macos-14`](https://github.com/actions/runner-images/blob/main/images/macos/macos-14-Readme.md) and `depot-macos-latest`
+- [`depot-windows-2022`](https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md)
+
+_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._

content/registry/overview.mdx

@@ -50,6 +50,7 @@ By default, builds saved in the Depot Registry persist for **7 days** from when
 
 Possible values for the retention policy are:
 
+- **1 day**
 - **7 days** (default)
 - **14 days**
 - **30 days**