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

Author: goller

content/cache/reference/maven.mdx

@@ -0,0 +1,82 @@
+---
+title: Maven
+ogTitle: Remote caching for Maven builds
+description: Learn how to use Depot remote caching for Maven builds
+---
+
+[**Maven**](https://maven.apache.org/) is a build automation and project management tool primarily used for Java projects that helps developers manage dependencies, build processes, and documentation in a centralized way. It follows a convention-over-configuration approach by providing a standard project structure and build lifecycle, allowing teams to quickly begin development without extensive configuration.
+
+[**Depot Cache**](/docs/cache/overview) provides a remote cache service that can be used with Maven, allowing you to incrementally cache and reuse parts of your builds. This cache is accessible from anywhere, both on your local machine and on CI/CD systems.
+
+## Configuring Maven to use Depot Cache
+
+Depot Cache can be used with Maven from Depot's managed GitHub Actions runners, your local machine, or any CI/CD system.
+
+### From Depot-managed Actions runners
+
+[Depot GitHub Actions runners](/docs/github-actions/overview) are pre-configured to use Depot Cache with Maven - each runner is launched with a `settings.xml` file that is pre-populated with the connection details for Depot Cache. You must verify that remote caching is enabled via the [Maven Build Cache extension](https://maven.apache.org/extensions/maven-build-cache-extension/index.html) in `.mvn/maven-build-cache-config.xml`:
+
+```xml
+<cache xmlns="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0"
+  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+  xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0 https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd">
+    <configuration>
+        <enabled>true</enabled>
+        <hashAlgorithm>SHA-256</hashAlgorithm>
+        <validateXml>true</validateXml>
+        <remote enabled="true" saveToRemote="true" id="depot-cache">
+            <url>https://cache.depot.dev</url>
+        </remote>
+        <projectVersioning adjustMetaInf="true" />
+    </configuration>
+</cache>
+```
+
+It is important to note that the `id` of your remote cache must be set to `depot-cache` for the Depot Cache service to work correctly in Depot GitHub Actions Runners. The cache will not be used if you use a different ID.
+
+You should also verify that you have registered the Build Cache extension in your `pom.xml` file:
+
+```xml
+<build>
+    <extensions>
+        <extension>
+            <groupId>org.apache.maven.extensions</groupId>
+            <artifactId>maven-build-cache-extension</artifactId>
+            <version>1.0.1</version>
+        </extension>
+    </extensions>
+</build>
+```
+
+If this automatic configuration is incompatible with your specific setup, you can disable automatic configuration in your organization settings page and manually configure Maven to use Depot Cache, as described below.
+
+### From your local machine or any CI/CD system
+
+To manually configure Maven to use Depot Cache, you will need to configure remote caching in your `~/.m2/settings.xml` file. Configure Maven to use the Depot Cache service endpoints and set your API token where there is the `DEPOT_TOKEN` below:
+
+`settings.xml`:
+
+```xml
+<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
+    <servers>
+        <server>
+            <id>depot-cache</id>
+                <configuration>
+                    <httpHeaders>
+                        <property>
+                            <name>Authorization</name>
+                            <value>Bearer DEPOT_TOKEN</value>
+                        </property>
+                    </httpHeaders>
+                </configuration>
+        </server>
+    </servers>
+</settings>
+```
+
+**Note: Maven support currently only supports Depot Organization API tokens, not user tokens.**
+
+## Using Depot Cache with Maven
+
+Once Maven is configured to use Depot Cache, you can run your builds as usual. Maven will automatically communicate with Depot Cache to fetch and reuse any stored build artifacts from your previous builds.

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

@@ -9,6 +9,7 @@ The Depot API is a collection of endpoints that grant access to our underlying a
 Our API is built with Connect, offering [multiprotocol support](https://connectrpc.com/docs/introduction#seamless-multi-protocol-support) for GRPC and HTTP JSON. We currently generate the following SDKs for interacting with Depot:
 
 - [Node](https://github.com/depot/sdk-node)
+- [Go](https://github.com/depot/depot-go)
 
 ## Authentication
 
@@ -274,13 +275,43 @@ 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)
 
 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.
 
-### List the images for a project
+#### List the images for a project
 
 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.
 
@@ -298,7 +329,7 @@ console.log(result.nextPageToken)
 
 The images returned will consist of an image tag, digest, a pushedAt timestamp, and the size of the image in bytes.
 
-### Delete images
+#### Delete images
 
 To delete images, you need to pass the ID of the project and the list of image tags you want to removed.
 

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/[email protected] 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**