kjuulh/dagger
Archived
1
0
Fork 0
Code Issues 1 Pull Requests 1 Projects Releases Wiki Activity

Merge branch 'main' into cloudrun-support

Browse Source
This commit is contained in:
Tihomir Jovicic
2021-07-01 08:54:44 +02:00
parent a24595da20 9c0210d485
commit 650caa8d4a
267 changed files with 2667 additions and 1463 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/learn/101-use.md
View File

@@ -5,20 +5,20 @@ slug: /learn/101-basics
# Dagger 101: basic usage
In this guide, you will learn the basics of Dagger by interacting with a pre-configured environment.
Then you will move on to creating your own environment from scratch.
Then you will move on to creating your environment from scratch.
Our pre-configured environment deploys a simple [React](https://reactjs.org/)
application to a special hosting environment created and managed by us, the Dagger team, for the purpose of this tutorial.
This will allow you to deploy something "real" right away, without having to configure your own infrastructure first.
application to a unique hosting environment created and managed by us, the Dagger team, for this tutorial.
This will allow you to deploy something "real" right away without configuring your infrastructure first.
In later guides, you will learn how to configure Dagger to deploy to your own infrastructure. And, for advanced users,
how to share access to your infrastructure in the same way that we are sharing access to ours now.
In later guides, you will learn how to configure Dagger to deploy to your infrastructure. And, for advanced users,
how to share access to your infrastructure in the same way that we share access to ours now.
## Initial setup
### Install Dagger
First, make sure [you have installed dagger on your local machine](/install).
First, make sure [you have installed Dagger on your local machine](/install).
### Setup example app
@@ -38,15 +38,15 @@ cd examples/todoapp
### Import the tutorial key
Dagger natively supports encrypted secrets: when a user inputs a value marked as secret
(for example a password, API token or ssh key) it is automatically encrypted with that user's key,
(for example, a password, API token, or ssh key) it is automatically encrypted with that user's key,
and no other user can access that value unless they are explicitly given access.
In the interest of security, Dagger has no way _not_ to encrypt a secret value.
But this causes a dilemma for this tutorial: how do we give unrestricted public access to our
(carefully sandboxed) infrastructure, so that anyone can deploy to it?
But this causes a dilemma for this tutorial: how do we give unrestricted, public access to our
(carefully sandboxed) infrastructure so that anyone can deploy to it?
To solve this dilemma, we included the private key used to encrypt the tutorial's secret inputs.
Simply import the key to your Dagger installation, and you're good to go:
Import the key to your Dagger installation, and you're good to go:
```shell
./import-tutorial-key.sh
@@ -54,7 +54,7 @@ Simply import the key to your Dagger installation, and you're good to go:
## First deployment
Now that your environment is setup, you are ready to deploy:
Now that your environment is set up, you are ready to deploy:
```shell
dagger up
@@ -75,7 +75,7 @@ NOTE: you don't have to commit your changes to the git repository before deployi
## Under the hood
This example showed you how to deploy and develop on an application that is already configured with dagger. Now, let's learn a few concepts to help you understand how this was put together.
This example showed you how to deploy and develop an application that is already configured with Dagger. Now, let's learn a few concepts to help you understand how this was put together.
### The Environment
@@ -87,13 +87,13 @@ You can list existing environment from the `./todoapp` directory:
dagger list
```
You should see an environment named `s3`. You can have many environments within your app. For instance one for `staging`, one for `dev`, etc...
You should see an environment named `s3`. You can have many environments within your app. For instance, one for `staging`, one for `dev`, etc...
Each environment can have different kind of deployment code. For example, a `dev` environment can deploy locally, a `staging` environment can deploy to a remote infrastructure, and so on.
Each environment can have a different kind of deployment code. For example, a `dev` environment can deploy locally; a `staging` environment can deploy to a remote infrastructure, and so on.
### The plan
The plan is the deployment code, that includes the logic to deploy the local application to an AWS S3 bucket. From the `todoapp` directory, you can list the code of the plan:
The plan is the deployment code that includes the logic to deploy the local application to an AWS S3 bucket. From the `todoapp` directory, you can list the code of the plan:
```shell
ls -l .dagger/env/s3/plan/
@@ -103,7 +103,7 @@ Any code change to the plan will be applied during the next `dagger up`.
### The inputs
The plan can define one or several `inputs` in order to take some information from the user. Here is how to list the current inputs:
The plan can define one or several `inputs`. Inputs may be configuration values, artifacts, or encrypted secrets provided by the user. Here is how to list the current inputs:
```shell
dagger input list
@@ -113,7 +113,7 @@ The inputs are persisted inside the `.dagger` directory and pushed to your git r
### The outputs
The plan defines one or several `outputs`. They can show useful information at the end of the deployment. That's how we read the deploy `url` at the end of the deployment. Here is the command to list all inputs:
The plan defines one or several `outputs`. They can show helpful information at the end of the deployment. That's how we read the deploy `url` at the end of the deployment. Here is the command to list all inputs:
```shell
dagger output list
@@ -121,4 +121,4 @@ dagger output list
## What's next?
At this point, you have deployed your first application using dagger and learned some dagger commands. You are now ready to [learn more about how to program dagger](/learn/102-dev).
At this point, you have deployed your first application using Dagger and learned some dagger commands. You are now ready to [learn more about how to program Dagger](/learn/102-dev).

163
docs/learn/102-dev.md
View File

@@ -6,47 +6,46 @@ slug: /learn/102-dev
## Overview
In this guide you will create your first Dagger environment from scratch,
and use it to deploy a React application to 2 locations in parallel:
In this guide, you will create your first Dagger environment from scratch,
and use it to deploy a React application to two locations in parallel:
a dedicated [Amazon S3](https://wikipedia.org/wiki/Amazon_S3) bucket, and a
[Netlify](https://en.wikipedia.org/wiki/Netlify) site.
### Anatomy of a Dagger environment
A Dagger environment contains all the code and data necessary to deliver a particular application in a particular way.
For example the same application might be delivered to a production and staging environment, each with their own
configuration.
A Dagger environment contains all the code and data necessary to deliver a particular application in a specific way.
For example, the same application might be delivered to a production and staging environment, each with its own configuration.
An environment is made of 3 parts:
* A *plan*, authored by the environment's *developer*, using the [Cue](https://cuelang.org) language.
- A _plan_, authored by the environment's _developer_, using the [Cue](https://cuelang.org) language.
* *Inputs*, supplied by the environment's *user* via the `dagger input` command, and written to a special file. Inputs may be configuration values, artifacts, or encrypted secrets.
- _Inputs_, supplied by the environment's _user_ via the `dagger input` command and written to a particular file. Inputs may be configuration values, artifacts, or encrypted secrets.
* *Outputs*, computed by the Dagger engine via the `dagger up` command, and recorded to a special directory.
- _Outputs_, computed by the Dagger engine via the `dagger up` command and recorded to a particular directory.
We will first develop our environment's *plan*, then configure its initial inputs, then finally run it to verify that it works.
We will first develop our environment's _plan_, configure its initial inputs, then finally run it to verify that it works.
### Anatomy of a plan
A _plan_ specifies, in code, how to deliver a particular application in a particular way.
A _plan_ specifies, in code, how to deliver a particular application in a specific way.
It is your environment's source code.
Unlike regular imperative programs which specify a sequence of instructions to execute,
Unlike regular imperative programs, which specify a sequence of instructions to execute,
a Dagger plan is _declarative_: it lays out your application's supply chain as a graph
of interconnected nodes.
Each node in the graph represents a component of the supply chain, for example:
* Development tools: source control, CI, build systems, testing systems
* Hosting infrastructure: compute, storage, networking, databases, CDNs
* Software dependencies: operating systems, languages, libraries, frameworks, etc.
- Development tools: source control, CI, build systems, testing systems
- Hosting infrastructure: compute, storage, networking, databases, CDNs
- Software dependencies: operating systems, languages, libraries, frameworks, etc.
Each link in the graph represents a flow of data between nodes. For example:
* source code flows from a git repository to a build system
* system dependencies are combined in a docker image, then uploaded to a registry
* configuration files are generated then sent to a compute cluster or load balancer
- source code flows from a git repository to a build system
- system dependencies are combined in a docker image, then uploaded to a registry
- configuration files are generated then sent to a compute cluster or load balancer
### Introduction to Cue development
@@ -56,22 +55,22 @@ Cue is a powerful declarative language by Marcel van Lohuizen. Marcel co-created
If you are new to Cue development, don't worry: this tutorial will walk you through the basic
steps to get started, and give you resources to learn more.
In technical terms, our plan is a [Cue Package](https://cuelang.org/docs/concepts/packages/#packages). In this tutorial we will develop a new Cue package from scratch for our plan; but you can use any Cue package as a plan.
In technical terms, our plan is a [Cue Package](https://cuelang.org/docs/concepts/packages/#packages). This tutorial will develop a new Cue package from scratch for our plan, but you can use any Cue package as a plan.
## Initial setup
### Install Cue
Although not strictly necessary, for an optimal development experience we recommend
Although not strictly necessary, for an optimal development experience, we recommend
[installing a recent version of Cue](https://github.com/cuelang/cue/releases/).
### Prepare Cue learning resources
If you are new to Cue, we recommend keeping the following resources in browser tabs:
* The unofficial but excellent [Cuetorials](https://cuetorials.com/overview/foundations/) in a browser tab, to look up Cue concepts as they appear.
- The unofficial but excellent [Cuetorials](https://cuetorials.com/overview/foundations/) in a browser tab, to look up Cue concepts as they appear.
* The official [Cue interactive sandbox](https://cuelang.org/play) for easy experimentation.
- The official [Cue interactive sandbox](https://cuelang.org/play) for easy experimentation.
### Setup example app
@@ -94,9 +93,9 @@ cd examples/todoapp
Developing for Dagger takes place in a [Cue module](https://cuelang.org/docs/concepts/packages/#modules).
If you are familiar with Go, Cue modules are directly inspired by Go modules.
Otherwise, don't worry: a Cue module is simply a directory with one or more Cue packages in it. A Cue module has a `cue.mod` directory at its root.
Otherwise, don't worry: a Cue module is simply a directory with one or more Cue packages in it. For example, a Cue module has a `cue.mod` directory at its root.
In this guide we will use the same directory as the root of the Dagger workspace and the root of the Cue module; but you can create your Cue module anywhere inside the Dagger workspace.
This guide will use the same directory as the root of the Dagger workspace and the Cue module, but you can create your Cue module anywhere inside the Dagger workspace.
```shell
cue mod init
@@ -106,10 +105,9 @@ cue mod init
Now we start developing our Cue package at the root of our Cue module.
In this guide we will split our package in multiple files, one per component.
But you can organize your package any way you want: the Cue evaluator simply merges together
all files from the same package, as long as they are in the same directory and start with the same
`package` clause. It is common for a Cue package to have only one file.
In this guide, we will split our package into multiple files, one per component.
Thus, it is typical for a Cue package to have only one file. However, you can organize your package any way you want: the Cue evaluator merges all files from the same package, as long as they are in the same directory, and start with the same
`package` clause...
See the [Cue documentation](https://cuelang.org/docs/concepts/packages/#files-belonging-to-a-package) for more details.
We will call our package `multibucket` because it sounds badass and vaguely explains what it does.
@@ -118,42 +116,42 @@ But you can call your packages anything you want.
Let's create a new directory for our Cue package:
```shell
mkdir multibucket
mkdir cue.mod/multibucket
```
### Component 1: app source code
The first component of our plan is the source code of our React application.
In Dagger terms, this component has 2 important properties:
In Dagger terms, this component has two essential properties:
1. It is an *artifact*: something that can be represented as a directory.
2. It is an *input*: something that is provided by the end user.
1. It is an _artifact_: something that can be represented as a directory.
2. It is an _input_: something that is provided by the end-user.
Let's write the corresponding Cue code to a new file in our package:
```cue title="todoapp/multibucket/source.cue"
```cue title="todoapp/cue.mod/multibucket/source.cue"
package multibucket
import (
"dagger.io/dagger"
"alpha.dagger.io/dagger"
)
// Source code of the sample application
src: dagger.#Artifact & dagger.#Input
```
This defines a component at the key `src`, and specifies that it is both an artifact and an input.
This code defines a component at the key `src`, and specifies that it is both an artifact and an input.
### Component 2: yarn package
The second component of our plan is the Yarn package built from the app source code:
```cue title="todoapp/multibucket/yarn.cue"
```cue title="todoapp/cue.mod/multibucket/yarn.cue"
package multibucket
import (
"dagger.io/js/yarn"
"alpha.dagger.io/js/yarn"
)
// Build the source code using Yarn
@@ -164,25 +162,25 @@ app: yarn.#Package & {
Let's break it down:
* `package multibucket`: this file is part of the multibucket package
* `import ( "dagger.io/js/yarn" )`: import a package from the [Dagger Universe](https://github.com/dagger/dagger/tree/main/stdlib).
* `app: yarn.#Package`: apply the `#Package` definition at the key `app`
* `&`: also merge the following values at the same key...
* `{ source: src }`: set the key `app.source` to the value of `src`. This connects our 2 components, forming the first link in our DAG.
- `package multibucket`: this file is part of the multibucket package
- `import ( "alpha.dagger.io/js/yarn" )`: import a package from the [Dagger Universe](../reference/universe/README.md).
- `app: yarn.#Package`: apply the `#Package` definition at the key `app`
- `&`: also merge the following values at the same key...
- `{ source: src }`: set the key `app.source` to the value of `src`. This snippet of code connects our two components, forming the first link in our DAG
### Component 3: dedicated S3 bucket
*FIXME*: this section is not yet available, because the [Amazon S3 package](https://github.com/dagger/dagger/tree/main/stdlib/aws/s3) does [not yet support bucket creation](https://github.com/dagger/dagger/issues/623). We welcome external contributions :)
_FIXME_: this section is not yet available because the [Amazon S3 package](https://github.com/dagger/dagger/tree/main/stdlib/aws/s3) does [not yet support bucket creation](https://github.com/dagger/dagger/issues/623). We welcome external contributions :)
### Component 4: deploy to Netlify
The third component of our plan is the Netlify site to which the app will be deployed:
```cue title="todoapp/multibucket/netlify.cue"
```cue title="todoapp/cue.mod/multibucket/netlify.cue"
package multibucket
import (
"dagger.io/netlify"
"alpha.dagger.io/netlify"
)
// Netlify site
@@ -191,25 +189,25 @@ site: "netlify": netlify.#Site & {
}
```
This is very similar to the previous component:
This component is very similar to the previous one:
* We use the same package name as the other files
* We import another package from the [Dagger Universe](https://github.com/dagger/dagger/tree/main/stdlib).
* `site: "netlify": site.#Netlify`: apply the `#Site` definition at the key `site.netlify`. Note the use of quotes to protect the key from name conflict.
* `&`: also merge the following values at the same key...
* `{ contents: app.build }`: set the key `site.netlify.contents` to the value of `app.build`. This connects our components 2 and 3, forming the second link in our DAG.
- We use the same package name as the other files
- We import another package from the [Dagger Universe](../reference/universe/README.md).
- `site: "netlify": site.#Netlify`: apply the `#Site` definition at the key `site.netlify`. Note the use of quotes to protect the key from name conflict.
- `&`: also merge the following values at the same key...
- `{ contents: app.build }`: set the key `site.netlify.contents` to the value of `app.build`. This line connects our components 2 and 3, forming the second link in our DAG.
### Exploring a package documentation
But wait: how did we know what fields were available in `yarn.#Package` and `netlify.#Site`?
Answer: thanks to the `dagger doc` command, which prints the documentation of any package from [Dagger Universe](https://github.com/dagger/dagger/tree/main/stdlib).
Answer: thanks to the `dagger doc` command, which prints the documentation of any package from [Dagger Universe](../reference/universe/README.md).
```shell
dagger doc dagger.io/netlify
dagger doc dagger.io/js/yarn
dagger doc alpha.dagger.io/netlify
dagger doc alpha.dagger.io/js/yarn
```
You can also browse the [Dagger Universe](/reference/universe) reference in the documentation.
You can also browse the [Dagger Universe](../reference/universe/README.md) reference in the documentation.
## Setup the environment
@@ -218,27 +216,56 @@ You can also browse the [Dagger Universe](/reference/universe) reference in the
Now that your Cue package is ready, let's create an environment to run it:
```shell
dagger new 'multibucket'
dagger new 'multibucket' -m cue.mod/multibucket
```
### Load the plan into the environment
Now let's configure the new environment to use our package as its plan:
```shell
cp multibucket/*.cue .dagger/env/multibucket/plan/
```
Note: you need to copy the files from your package into the environment, as shown above.
If you make more changes to your package, you will need to copy the new version, or it will not be used.
In the future, we will add the ability to reference your Cue package directory, making this manual copy unnecessary.
### Configure user inputs
[This section is not yet written](https://github.com/dagger/dagger/blob/main/CONTRIBUTING.md)
You can inspect the list of inputs (both required and optional) using dagger input list:
```shell
dagger input list -e multibucket
# Input Value Set by user Description
# site.netlify.account.name *"" | string false Use this Netlify account name (also referred to as "team" in the Netlify docs)
# site.netlify.account.token dagger.#Secret false Netlify authentication token
# site.netlify.name string false Deploy to this Netlify site
# site.netlify.create *true | bool false Create the Netlify site if it doesn't exist?
# src dagger.#Artifact false Source code of the sample application
# app.cwd *"." | string false working directory to use
# app.writeEnvFile *"" | string false Write the contents of `environment` to this file, in the "envfile" format
# app.buildDir *"build" | string false Read build output from this directory (path must be relative to working directory)
# app.script *"build" | string false Run this yarn script
# app.args *[] | [] false Optional arguments for the script
```
All the values without default values (without `*`) have to be specified by the user. Here, required fields are:
- `site.netlify.account.token`, your access token
- `site.netlify.name`, name of the published website
- `src`, source code of the app
Please note the type of the user inputs: a string, a #Secret and an artifact. Let's see how to input them:
```shell
# As a string input is expected for `site.netlify.name`, we set a `text` input
dagger input text site.netlify.name <GLOBALLY-UNIQUE-NAME> -e multibucket
# As a secret input is expected for `site.netlify.account.token`, we set a `secret` input
dagger input secret site.netlify.account.token <PERSONAL-ACCESS-TOKEN> -e multibucket
# As an Artifact is exepected for `src`, we set a `dir` input (dagger input list for alternatives)
dagger input dir src . -e multibucket
```
### Deploy
Now that everything is properly set, let's deploy on Netlify:
```shell
dagger up -e multibucket
```
[This section is not yet written](https://github.com/dagger/dagger/blob/main/CONTRIBUTING.md)
### Using the environment

2
docs/learn/103-script.md
View File

@@ -4,7 +4,7 @@ slug: /learn/103-script
# Dagger 103: integrate custom shell scripts
In this guide, you will learn how to incorporate your custom shell scripts into a Dagger environment. For example, to run integration tests before deployment; call a custom processing step; or any other custom task which you have already automated, and want to incorporate into your Dagger environment with minimal effort.
In this guide, you will learn how to incorporate your custom shell scripts into a Dagger environment. For example, run integration tests before deployment; call a custom processing step; or any other custom task which you have already automated and want to incorporate into your Dagger environment with minimal effort.
This section is not yet written. Help Dagger growing by suggesting content improvements.

24
docs/learn/107-kubernetes.md
View File

@@ -164,14 +164,14 @@ values={[
package kube
import (
"dagger.io/kubernetes"
"alpha.dagger.io/kubernetes"
)
// input: ~/.kube/config file used for deployment
// set with `dagger input text kubeconfig -f ~/.kube/config`
kubeconfig: string @dagger(input)
// deploy uses the `dagger.io/kubernetes` package to apply a manifest to a
// deploy uses the `alpha.dagger.io/kubernetes` package to apply a manifest to a
// Kubernetes cluster.
deploy: kubernetes.#Resources & {
// reference the `kubeconfig` input above
@@ -190,8 +190,8 @@ deploy: kubernetes.#Resources & {
package kube
import (
"dagger.io/kubernetes"
"dagger.io/gcp/gke"
"alpha.dagger.io/kubernetes"
"alpha.dagger.io/gcp/gke"
)
// gkeConfig used for deployment
@@ -199,7 +199,7 @@ gkeConfig: gke.#KubeConfig @dagger(input)
kubeconfig: gkeConfig.kubeconfig
// deploy uses the `dagger.io/kubernetes` package to apply a manifest to a
// deploy uses the `alpha.dagger.io/kubernetes` package to apply a manifest to a
// Kubernetes cluster.
deploy: kubernetes.#Resources & {
// reference the `kubeconfig` input above
@@ -218,8 +218,8 @@ deploy: kubernetes.#Resources & {
package kube
import (
"dagger.io/kubernetes"
"dagger.io/aws/eks"
"alpha.dagger.io/kubernetes"
"alpha.dagger.io/aws/eks"
)
// eksConfig used for deployment
@@ -227,7 +227,7 @@ eksConfig: eks.#KubeConfig @dagger(input)
kubeconfig: eksConfig.kubeconfig
// deploy uses the `dagger.io/kubernetes` package to apply a manifest to a
// deploy uses the `alpha.dagger.io/kubernetes` package to apply a manifest to a
// Kubernetes cluster.
deploy: kubernetes.#Resources & {
// reference the `kubeconfig` input above
@@ -245,7 +245,7 @@ This defines:
- `kubeconfig` a _string_ **input**: kubernetes configuration (`~/.kube/config`)
used for `kubectl`
- `deploy`: Deployment step using the package `dagger.io/kubernetes`. It takes
- `deploy`: Deployment step using the package `alpha.dagger.io/kubernetes`. It takes
the `manifest` defined earlier and deploys it to the Kubernetes cluster specified in `kubeconfig`.
### Setup the environment
@@ -578,7 +578,7 @@ The following configuration will:
- Declare a `repository` input as a `dagger.#Artifact`. This will be mapped to
the source code directory.
- Declare a `registry` input. This is the address used for docker push
- Use `dagger.io/docker` to build and push the image
- Use `alpha.dagger.io/docker` to build and push the image
- Use the registry image reference (`push.ref`) as the image for the deployment.
```cue title="todoapp/kube/manifest.cue"
@@ -587,8 +587,8 @@ package kube
import (
"encoding/yaml"
"dagger.io/dagger"
"dagger.io/docker"
"alpha.dagger.io/dagger"
"alpha.dagger.io/docker"
)
// input: source code repository, must contain a Dockerfile

1136
docs/learn/108-cloudformation.md
View File

File diff suppressed because it is too large Load Diff

31
docs/reference/universe/README.md Normal file
View File

@@ -0,0 +1,31 @@
# Index
- [alpine](./alpine.md) - Base package for Alpine Linux
- [aws](./aws/README.md) - AWS base package
- [aws/cloudformation](./aws/cloudformation.md) - AWS CloudFormation
- [aws/ecr](./aws/ecr.md) - Amazon Elastic Container Registry (ECR)
- [aws/ecs](./aws/ecs.md) - AWS Elastic Container Service (ECS)
- [aws/eks](./aws/eks.md) - AWS Elastic Kubernetes Service (EKS)
- [aws/elb](./aws/elb.md) - AWS Elastic Load Balancer (ELBv2)
- [aws/rds](./aws/rds.md) - AWS Relational Database Service (RDS)
- [aws/s3](./aws/s3.md) - AWS Simple Storage Service
- [dagger](./dagger/README.md) - Dagger core types
- [dagger/op](./dagger/op.md) - op: low-level operations for Dagger processing pipelines
- [docker](./docker/README.md) - Docker container operations
- [docker/compose](./docker/compose.md) - Docker-compose operations
- [gcp](./gcp/README.md) - Google Cloud Platform
- [gcp/gcr](./gcp/gcr.md) - Google Container Registry
- [gcp/gcs](./gcp/gcs.md) - Google Cloud Storage
- [gcp/gke](./gcp/gke.md) - Google Kubernetes Engine
- [git](./git.md) - Git operations
- [go](./go.md) - Go build operations
- [io](./io.md) - IO operations
- [java/maven](./java/maven.md) - Maven is a build automation tool for Java
- [js/yarn](./js/yarn.md) - Yarn is a package manager for Javascript applications
- [kubernetes](./kubernetes/README.md) - Kubernetes client operations
- [kubernetes/helm](./kubernetes/helm.md) - Helm package manager
- [kubernetes/kustomize](./kubernetes/kustomize.md) - Kustomize config management
- [netlify](./netlify.md) - Netlify client operations
- [os](./os.md) - OS operations
- [random](./random.md) - Random generation utilities
- [terraform](./terraform.md) - Terraform operations

4
docs/reference/universe/alpine.md
View File

@@ -2,12 +2,12 @@
sidebar_label: alpine
---
# dagger.io/alpine
# alpha.dagger.io/alpine
Base package for Alpine Linux
```cue
import "dagger.io/alpine"
import "alpha.dagger.io/alpine"
```
## alpine.#Image

4
docs/reference/universe/aws/README.md
View File

@@ -2,12 +2,12 @@
sidebar_label: aws
---
# dagger.io/aws
# alpha.dagger.io/aws
AWS base package
```cue
import "dagger.io/aws"
import "alpha.dagger.io/aws"
```
## aws.#CLI

8
docs/reference/universe/aws/cloudformation.md
View File

@@ -2,12 +2,12 @@
sidebar_label: cloudformation
---
# dagger.io/aws/cloudformation
# alpha.dagger.io/aws/cloudformation
AWS CloudFormation
```cue
import "dagger.io/aws/cloudformation"
import "alpha.dagger.io/aws/cloudformation"
```
## cloudformation.#Stack
@@ -30,6 +30,4 @@ AWS CloudFormation Stack
### cloudformation.#Stack Outputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*outputs* | `struct` |- |
_No output._

4
docs/reference/universe/aws/ecr.md
View File

@@ -2,12 +2,12 @@
sidebar_label: ecr
---
# dagger.io/aws/ecr
# alpha.dagger.io/aws/ecr
Amazon Elastic Container Registry (ECR)
```cue
import "dagger.io/aws/ecr"
import "alpha.dagger.io/aws/ecr"
```
## ecr.#Credentials

4
docs/reference/universe/aws/ecs.md
View File

@@ -2,10 +2,10 @@
sidebar_label: ecs
---
# dagger.io/aws/ecs
# alpha.dagger.io/aws/ecs
AWS Elastic Container Service (ECS)
```cue
import "dagger.io/aws/ecs"
import "alpha.dagger.io/aws/ecs"
```

4
docs/reference/universe/aws/eks.md
View File

@@ -2,12 +2,12 @@
sidebar_label: eks
---
# dagger.io/aws/eks
# alpha.dagger.io/aws/eks
AWS Elastic Kubernetes Service (EKS)
```cue
import "dagger.io/aws/eks"
import "alpha.dagger.io/aws/eks"
```
## eks.#KubeConfig

4
docs/reference/universe/aws/elb.md
View File

@@ -2,12 +2,12 @@
sidebar_label: elb
---
# dagger.io/aws/elb
# alpha.dagger.io/aws/elb
AWS Elastic Load Balancer (ELBv2)
```cue
import "dagger.io/aws/elb"
import "alpha.dagger.io/aws/elb"
```
## elb.#RandomRulePriority

4
docs/reference/universe/aws/rds.md
View File

@@ -2,12 +2,12 @@
sidebar_label: rds
---
# dagger.io/aws/rds
# alpha.dagger.io/aws/rds
AWS Relational Database Service (RDS)
```cue
import "dagger.io/aws/rds"
import "alpha.dagger.io/aws/rds"
```
## rds.#Database

4
docs/reference/universe/aws/s3.md
View File

@@ -2,12 +2,12 @@
sidebar_label: s3
---
# dagger.io/aws/s3
# alpha.dagger.io/aws/s3
AWS Simple Storage Service
```cue
import "dagger.io/aws/s3"
import "alpha.dagger.io/aws/s3"
```
## s3.#Object

6
docs/reference/universe/dagger/README.md
View File

@@ -2,10 +2,12 @@
sidebar_label: dagger
---
# dagger.io/dagger
# alpha.dagger.io/dagger
Dagger core types
```cue
import "dagger.io/dagger"
import "alpha.dagger.io/dagger"
```
## dagger.#Secret

4
docs/reference/universe/dagger/op.md
View File

@@ -2,12 +2,12 @@
sidebar_label: op
---
# dagger.io/dagger/op
# alpha.dagger.io/dagger/op
op: low-level operations for Dagger processing pipelines
```cue
import "dagger.io/dagger/op"
import "alpha.dagger.io/dagger/op"
```
## op.#Copy

6
docs/reference/universe/docker.md → docs/reference/universe/docker/README.md
View File

@@ -2,12 +2,12 @@
sidebar_label: docker
---
# dagger.io/docker
# alpha.dagger.io/docker
Docker container operations
```cue
import "dagger.io/docker"
import "alpha.dagger.io/docker"
```
## docker.#Build
@@ -33,6 +33,7 @@ A container image that can run any docker command
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*command* | `string` |Command to execute |
|*registries* | `[]` |Image registries |
### docker.#Command Outputs
@@ -99,6 +100,7 @@ _No output._
|*run.ssh.key* | `dagger.#Secret` |private key |
|*run.command* | `"""\n # Run detach container\n OPTS=""\n \n if [ ! -z "$CONTAINER_NAME" ]; then\n \tOPTS="$OPTS --name $CONTAINER_NAME"\n fi\n \n docker container run -d $OPTS "$IMAGE_REF"\n """` |Command to execute |
|*run.env.IMAGE_REF* | `string` |- |
|*run.registries* | `[]` |Image registries |
### docker.#Run Outputs

40
docs/reference/universe/docker/compose.md Normal file
View File

@@ -0,0 +1,40 @@
---
sidebar_label: compose
---
# alpha.dagger.io/docker/compose
Docker-compose operations
```cue
import "alpha.dagger.io/docker/compose"
```
## compose.#App
### compose.#App Inputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*name* | `*"source" \| string` |App name (use as COMPOSE_PROJECT_NAME) |
|*registries* | `[]` |Image registries |
|*run.command* | `"""\n if [ -n "$DOCKER_HOSTNAME" ]; then\n \tssh -i /key -fNT -o "StreamLocalBindUnlink=yes" -L "$(pwd)"/docker.sock:/var/run/docker.sock -p "$DOCKER_PORT" "$DOCKER_USERNAME"@"$DOCKER_HOSTNAME"\n \texport DOCKER_HOST="unix://$(pwd)/docker.sock"\n fi\n \n # Extend session duration\n echo "Host *\\nServerAliveInterval 240" \>\> "$HOME"/.ssh/config\n chmod 600 "$HOME"/.ssh/config\n \n # Move compose\n if [ -d "$SOURCE_DIR" ]; then\n \tif [ -f docker-compose.yaml ]; then\n \t\tcp docker-compose.yaml "$SOURCE_DIR"/docker-compose.yaml\n \tfi\n \tcd "$SOURCE_DIR"\n fi\n \n docker-compose build\n docker-compose up -d\n """` |Command to execute |
|*run.env.COMPOSE_PROJECT_NAME* | `*"source" \| string` |- |
|*run.package."docker-compose"* | `true` |- |
|*run.registries* | `[]` |Image registries |
### compose.#App Outputs
_No output._
## compose.#Client
A container image to run the docker-compose client
### compose.#Client Inputs
_No input._
### compose.#Client Outputs
_No output._

84
docs/reference/universe/file.md
View File

@@ -1,84 +0,0 @@
---
sidebar_label: file
---
# dagger.io/file
DEPRECATED: see dagger.io/os
## #Append
### #Append Inputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*filename* | `string` |- |
|*permissions* | `*0o644 \| int` |- |
|*contents* | `(string\|bytes)` |- |
|*from* | `dagger.#Artifact` |- |
### #Append Outputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*orig* | `string` |- |
## #Create
### #Create Inputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*filename* | `string` |- |
|*permissions* | `*0o644 \| int` |- |
|*contents* | `(string\|bytes)` |- |
### #Create Outputs
_No output._
## #Glob
### #Glob Inputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*glob* | `string` |- |
|*from* | `dagger.#Artifact` |- |
### #Glob Outputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*filenames* | `_\|_` |trim suffix because ls always ends with newline |
|*files* | `string` |- |
## #Read
### #Read Inputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*filename* | `string` |- |
|*from* | `dagger.#Artifact` |- |
### #Read Outputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*contents* | `string` |- |
## #read
### #read Inputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*path* | `string` |- |
|*from* | `dagger.#Artifact` |- |
### #read Outputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*data* | `string` |- |

4
docs/reference/universe/gcp/README.md
View File

@@ -2,12 +2,12 @@
sidebar_label: gcp
---
# dagger.io/gcp
# alpha.dagger.io/gcp
Google Cloud Platform
```cue
import "dagger.io/gcp"
import "alpha.dagger.io/gcp"
```
## gcp.#Config

4
docs/reference/universe/gcp/gcr.md
View File

@@ -2,12 +2,12 @@
sidebar_label: gcr
---
# dagger.io/gcp/gcr
# alpha.dagger.io/gcp/gcr
Google Container Registry
```cue
import "dagger.io/gcp/gcr"
import "alpha.dagger.io/gcp/gcr"
```
## gcr.#Credentials

34
docs/reference/universe/gcp/gcs.md Normal file
View File

@@ -0,0 +1,34 @@
---
sidebar_label: gcs
---
# alpha.dagger.io/gcp/gcs
Google Cloud Storage
```cue
import "alpha.dagger.io/gcp/gcs"
```
## gcs.#Object
GCS Bucket object(s) sync
### gcs.#Object Inputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*config.region* | `string` |GCP region |
|*config.project* | `string` |GCP project |
|*config.serviceKey* | `dagger.#Secret` |GCP service key |
|*source* | `dagger.#Artifact` |Source Artifact to upload to GCS |
|*target* | `string` |Target GCS URL (eg. gs://\<bucket-name\>/\<path\>/\<sub-path\>) |
|*delete* | `*false \| true` |Delete files that already exist on remote destination |
|*contentType* | `*"" \| string` |Object content type |
|*always* | `*true \| false` |Always write the object to GCS |
### gcs.#Object Outputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*url* | `string` |URL of the uploaded GCS object |

4
docs/reference/universe/gcp/gke.md
View File

@@ -2,12 +2,12 @@
sidebar_label: gke
---
# dagger.io/gcp/gke
# alpha.dagger.io/gcp/gke
Google Kubernetes Engine
```cue
import "dagger.io/gcp/gke"
import "alpha.dagger.io/gcp/gke"
```
## gke.#KubeConfig

4
docs/reference/universe/git.md
View File

@@ -2,12 +2,12 @@
sidebar_label: git
---
# dagger.io/git
# alpha.dagger.io/git
Git operations
```cue
import "dagger.io/git"
import "alpha.dagger.io/git"
```
## git.#CurrentBranch

4
docs/reference/universe/go.md
View File

@@ -2,12 +2,12 @@
sidebar_label: go
---
# dagger.io/go
# alpha.dagger.io/go
Go build operations
```cue
import "dagger.io/go"
import "alpha.dagger.io/go"
```
## go.#Build

4
docs/reference/universe/io.md
View File

@@ -2,12 +2,12 @@
sidebar_label: io
---
# dagger.io/io
# alpha.dagger.io/io
IO operations
```cue
import "dagger.io/io"
import "alpha.dagger.io/io"
```
## io.#Dir

32
docs/reference/universe/java/maven.md Normal file
View File

@@ -0,0 +1,32 @@
---
sidebar_label: maven
---
# alpha.dagger.io/java/maven
Maven is a build automation tool for Java
```cue
import "alpha.dagger.io/java/maven"
```
## maven.#Project
A Maven project
### maven.#Project Inputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*source* | `dagger.#Artifact` |Application source code |
|*package* | `struct` |Extra alpine packages to install |
|*env* | `struct` |Environment variables |
|*phases* | `*["package"] \| []` |- |
|*goals* | `*[] \| []` |- |
|*args* | `*[] \| []` |Optional arguments for the script |
### maven.#Project Outputs
| Name | Type | Description |
| ------------- |:-------------: |:-------------: |
|*build* | `struct` |Build output directory |

4
docs/reference/universe/js/yarn.md
View File

@@ -2,12 +2,12 @@
sidebar_label: yarn
---
# dagger.io/js/yarn
# alpha.dagger.io/js/yarn
Yarn is a package manager for Javascript applications
```cue
import "dagger.io/js/yarn"
import "alpha.dagger.io/js/yarn"
```
## yarn.#Package

4
docs/reference/universe/kubernetes/README.md
View File

@@ -2,12 +2,12 @@
sidebar_label: kubernetes
---
# dagger.io/kubernetes
# alpha.dagger.io/kubernetes
Kubernetes client operations
```cue
import "dagger.io/kubernetes"
import "alpha.dagger.io/kubernetes"
```
## kubernetes.#Kubectl

4
docs/reference/universe/kubernetes/helm.md
View File

@@ -2,12 +2,12 @@
sidebar_label: helm
---
# dagger.io/kubernetes/helm
# alpha.dagger.io/kubernetes/helm
Helm package manager
```cue
import "dagger.io/kubernetes/helm"
import "alpha.dagger.io/kubernetes/helm"
```
## helm.#Chart

4
docs/reference/universe/kubernetes/kustomize.md
View File

@@ -2,12 +2,12 @@
sidebar_label: kustomize
---
# dagger.io/kubernetes/kustomize
# alpha.dagger.io/kubernetes/kustomize
Kustomize config management
```cue
import "dagger.io/kubernetes/kustomize"
import "alpha.dagger.io/kubernetes/kustomize"
```
## kustomize.#Kustomization

4
docs/reference/universe/netlify.md
View File

@@ -2,12 +2,12 @@
sidebar_label: netlify
---
# dagger.io/netlify
# alpha.dagger.io/netlify
Netlify client operations
```cue
import "dagger.io/netlify"
import "alpha.dagger.io/netlify"
```
## netlify.#Account

8
docs/reference/universe/os.md
View File

@@ -2,10 +2,12 @@
sidebar_label: os
---
# dagger.io/os
# alpha.dagger.io/os
OS operations
```cue
import "dagger.io/os"
import "alpha.dagger.io/os"
```
## os.#Container
@@ -32,7 +34,7 @@ _No output._
## os.#File
Built-in file implementation, using buildkit
Built-in file implementation, using buildkit A single file
### os.#File Inputs

4
docs/reference/universe/random.md
View File

@@ -2,12 +2,12 @@
sidebar_label: random
---
# dagger.io/random
# alpha.dagger.io/random
Random generation utilities
```cue
import "dagger.io/random"
import "alpha.dagger.io/random"
```
## random.#String

4
docs/reference/universe/terraform.md
View File

@@ -2,12 +2,12 @@
sidebar_label: terraform
---
# dagger.io/terraform
# alpha.dagger.io/terraform
Terraform operations
```cue
import "dagger.io/terraform"
import "alpha.dagger.io/terraform"
```
## terraform.#Configuration