website: hardcode version banner for 0.1 docs

O.1 docs is deprecated. Let's inform user to switch the the latest version

Signed-off-by: user.email <jf@dagger.io>
This commit is contained in:
user.email 2022-04-13 15:58:51 +02:00
parent 991c8dc6ff
commit d20ffbe8be
31 changed files with 262 additions and 204 deletions

16
docs/0.1.md Normal file
View File

@ -0,0 +1,16 @@
---
slug: /0.1
displayed_sidebar: '0.1'
---
# Dagger 0.1
This documentation is for dagger 0.1 which is no longer maintained.
If you are still running dagger 0.1, we encourage you to upgrade to 0.2.
These are the [current dagger 0.2 docs](/).
If you need help migrating your plan, we will be happy to assist you!
Simply reply to [this thread](https://github.com/dagger/dagger/discussions/1772) with a description of your configuration.
If you've already started migrating, please let us know and share details of your progress and issues you're encountering.
We will do our best to assist you!

View File

@ -1,6 +1,6 @@
--- ---
slug: /1214/migrate-from-dagger-0.1 slug: /1214/migrate-from-dagger-0.1
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Migrate from Dagger 0.1 # Migrate from Dagger 0.1

View File

@ -1,5 +1,6 @@
--- ---
slug: /1013/operator-manual/ slug: /1013/operator-manual/
displayed_sidebar: "0.1"
--- ---
# Dagger Operator Manual # Dagger Operator Manual

View File

@ -1,6 +1,6 @@
--- ---
slug: /1202/plan slug: /1202/plan
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# It all starts with a plan # It all starts with a plan
@ -20,6 +20,7 @@ Within this plan we can:
This is our **Getting Started** todoapp plan structure: This is our **Getting Started** todoapp plan structure:
```cue file=../tests/core-concepts/plan/structure.cue.fragment ```cue file=../tests/core-concepts/plan/structure.cue.fragment
``` ```
When the above plan gets executed via `dagger do build`, it produces the following output: When the above plan gets executed via `dagger do build`, it produces the following output:

View File

@ -1,6 +1,6 @@
--- ---
slug: /1203/client slug: /1203/client
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Interacting with the client # Interacting with the client
@ -18,11 +18,13 @@ displayed_sidebar: europa
You may need to load a local directory as a `dagger.#FS` type in your plan: You may need to load a local directory as a `dagger.#FS` type in your plan:
```cue file=../tests/core-concepts/client/plans/fs.cue ```cue file=../tests/core-concepts/client/plans/fs.cue
``` ```
Its also easy to write a file locally: Its also easy to write a file locally:
```cue file=../tests/core-concepts/client/plans/file.cue ```cue file=../tests/core-concepts/client/plans/file.cue
``` ```
## Using a local socket ## Using a local socket
@ -40,6 +42,7 @@ import BrowserOnly from '@docusaurus/BrowserOnly';
<TabItem value="unix" label="Linux/macOS"> <TabItem value="unix" label="Linux/macOS">
```cue file=../tests/core-concepts/client/plans/unix.cue ```cue file=../tests/core-concepts/client/plans/unix.cue
``` ```
</TabItem> </TabItem>
@ -47,6 +50,7 @@ import BrowserOnly from '@docusaurus/BrowserOnly';
<TabItem value="windows" label="Windows"> <TabItem value="windows" label="Windows">
```cue file=../tests/core-concepts/client/plans/windows.cue ```cue file=../tests/core-concepts/client/plans/windows.cue
``` ```
</TabItem> </TabItem>
@ -59,6 +63,7 @@ import BrowserOnly from '@docusaurus/BrowserOnly';
Environment variables can be read from the local machine as strings or secrets, just specify the type: Environment variables can be read from the local machine as strings or secrets, just specify the type:
```cue file=../tests/core-concepts/client/plans/env.cue ```cue file=../tests/core-concepts/client/plans/env.cue
``` ```
## Running commands ## Running commands
@ -66,6 +71,7 @@ Environment variables can be read from the local machine as strings or secrets,
Sometimes you need something more advanced that only a local command can give you: Sometimes you need something more advanced that only a local command can give you:
```cue file=../tests/core-concepts/client/plans/cmd.cue ```cue file=../tests/core-concepts/client/plans/cmd.cue
``` ```
:::tip :::tip
@ -77,4 +83,5 @@ You can also capture `stderr` for errors and provide `stdin` for input.
If you need the current platform though, theres a more portable way than running `uname` like in the previous example: If you need the current platform though, theres a more portable way than running `uname` like in the previous example:
```cue file=../tests/core-concepts/client/plans/platform.cue ```cue file=../tests/core-concepts/client/plans/platform.cue
``` ```

View File

@ -1,6 +1,6 @@
--- ---
slug: /1204/secrets slug: /1204/secrets
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# How to use secrets # How to use secrets
@ -28,6 +28,7 @@ dagger.#Plan & {
You may need to trim the whitespace, especially when reading from a file: You may need to trim the whitespace, especially when reading from a file:
```cue file=../tests/core-concepts/secrets/plans/file.cue ```cue file=../tests/core-concepts/secrets/plans/file.cue
``` ```
## SOPS ## SOPS
@ -36,9 +37,9 @@ Theres many ways to store encrypted secrets in your git repository. If you us
```yaml title="secrets.yaml" ```yaml title="secrets.yaml"
myToken: ENC[AES256_GCM,data:AlUz7g==,iv:lq3mHi4GDLfAssqhPcuUIHMm5eVzJ/EpM+q7RHGCROU=,tag:dzbT5dEGhMnHbiRTu4bHdg==,type:str] myToken: ENC[AES256_GCM,data:AlUz7g==,iv:lq3mHi4GDLfAssqhPcuUIHMm5eVzJ/EpM+q7RHGCROU=,tag:dzbT5dEGhMnHbiRTu4bHdg==,type:str]
sops: sops: ...
...
``` ```
```cue file=../tests/core-concepts/secrets/plans/sops.cue title="main.cue" ```cue file=../tests/core-concepts/secrets/plans/sops.cue title="main.cue"
``` ```

View File

@ -1,6 +1,6 @@
--- ---
slug: /1206/packages slug: /1206/packages
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Create your own package # Create your own package

View File

@ -1,6 +1,6 @@
--- ---
slug: /1207/caching slug: /1207/caching
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Make your builds fast # Make your builds fast

View File

@ -1,6 +1,6 @@
--- ---
slug: /1213/api slug: /1213/api
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Dagger CUE API # Dagger CUE API
@ -16,7 +16,7 @@ Developers of other Dagger packages are expected to build on top of these core p
`#Plan` defines the structure of a Dagger plan - a complete configuration executable by `dagger do` `#Plan` defines the structure of a Dagger plan - a complete configuration executable by `dagger do`
| Definition | File | Description | | Definition | File | Description |
| :-- | :-- | :-- | | :--------- | :------------------------------------------------------------------------------------- | :--------------------------------------------------- |
| `#Plan` | [plan.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/plan.cue) | A special kind of program which `dagger` can execute | | `#Plan` | [plan.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/plan.cue) | A special kind of program which `dagger` can execute |
### Core types ### Core types
@ -24,7 +24,7 @@ Developers of other Dagger packages are expected to build on top of these core p
Dagger extends the CUE type system with the following core types: Dagger extends the CUE type system with the following core types:
| Definition | File | Description | | Definition | File | Description |
| :-- | :-- | :-- | | :------------- | :------------------------------------------------------------------------------------------ | :---------------------------------------------------- |
| `#Address` | [types.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/types.cue) | Network service address | | `#Address` | [types.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/types.cue) | Network service address |
| `#CacheDir` | [exec.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/exec.cue) | A (best effort) persistent cache dir | | `#CacheDir` | [exec.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/exec.cue) | A (best effort) persistent cache dir |
| `#FS` | [types.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/types.cue) | Reference to a filesystem tree | | `#FS` | [types.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/types.cue) | Reference to a filesystem tree |
@ -42,13 +42,13 @@ Dagger extends the CUE type system with the following core types:
Dagger works by executing actions in a certain order and passing data between actions in a certain layout. Dagger works by executing actions in a certain order and passing data between actions in a certain layout.
Developers can combine actions into higher-level actions, which in turn can be combined into even higher-level actions, Developers can combine actions into higher-level actions, which in turn can be combined into even higher-level actions,
and so on at arbitrary levels of depth. At the bottom of this abstraction stack are *core actions*: these and so on at arbitrary levels of depth. At the bottom of this abstraction stack are _core actions_: these
are implemented by Dagger itself, and are always available. are implemented by Dagger itself, and are always available.
The following core actions are available: The following core actions are available:
| Definition | File | Description | | Definition | File | Description |
| :-- | :-- | :-- | | :-------------- | :------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------------- |
| `#Copy` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Copy files between two filesystem trees | | `#Copy` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Copy files between two filesystem trees |
| `#DecodeSecret` | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Decode a secret without leaking its contents | | `#DecodeSecret` | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Decode a secret without leaking its contents |
| `#Diff` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Extract the difference between two filesystems as its own file system | | `#Diff` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Extract the difference between two filesystems as its own file system |

View File

@ -1,6 +1,6 @@
--- ---
slug: /1221/action slug: /1221/action
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Dagger Actions # Dagger Actions
@ -11,7 +11,7 @@ software component that can be safely shared, and repeatably executed by any Dag
Actions can be executed directly with `dagger do`, or integrated as a component of a more complex action. Actions can be executed directly with `dagger do`, or integrated as a component of a more complex action.
There are two types of actions: *core actions* and *composite actions*. There are two types of actions: _core actions_ and _composite actions_.
## Core Actions ## Core Actions
@ -36,7 +36,7 @@ A composite action's lifecycle has 4 stages:
### Definition ### Definition
A new action is *defined* in a declarative template called a [CUE definition](https://cuetorials.com/overview/foundations/#definitions). This definition describes the action's inputs, outputs, sub-actions, and the wiring between them. A new action is _defined_ in a declarative template called a [CUE definition](https://cuetorials.com/overview/foundations/#definitions). This definition describes the action's inputs, outputs, sub-actions, and the wiring between them.
Here is an example of a simple action definition: Here is an example of a simple action definition:
@ -71,9 +71,9 @@ Note that this action includes one sub-action: `core.#WriteFile`. An action can
Also note the free-form structure: an action definition is not structured by a rigid schema. It is simply a CUE struct with fields of various types. Also note the free-form structure: an action definition is not structured by a rigid schema. It is simply a CUE struct with fields of various types.
* "inputs" are simply fields which are not complete, and therefore can receive an external value at integration. For example, `dir` and `name` are inputs. - "inputs" are simply fields which are not complete, and therefore can receive an external value at integration. For example, `dir` and `name` are inputs.
* "outputs" are simply fields which produce a value that can be referenced externally at integration. For example, `result` is an output. - "outputs" are simply fields which produce a value that can be referenced externally at integration. For example, `result` is an output.
* "sub-actions" are simply fields which contain another action definition. For example, `write` is a sub-action. - "sub-actions" are simply fields which contain another action definition. For example, `write` is a sub-action.
There are no constraints to an action's field names or types. There are no constraints to an action's field names or types.
@ -83,11 +83,11 @@ Action definitions cannot be executed directly: they must be integrated into a p
A plan is an execution context for actions. It specifies: A plan is an execution context for actions. It specifies:
* What actions to present to the end user - What actions to present to the end user
* Dependencies between those tasks, if any - Dependencies between those tasks, if any
* Interactions between the tasks and the client system, if any - Interactions between the tasks and the client system, if any
Actions are integrated into a plan by *merging* their CUE definition into the plan's CUE definition. Actions are integrated into a plan by _merging_ their CUE definition into the plan's CUE definition.
Here is an example of a plan: Here is an example of a plan:
@ -110,7 +110,7 @@ dagger.#Plan & {
} }
``` ```
Note that `#AddHello` was integrated *directly* into the plan, whereas `core.#WriteFile` was integrated *indirectly*, by virtue of being a sub-action of `#AddHello`. Note that `#AddHello` was integrated _directly_ into the plan, whereas `core.#WriteFile` was integrated _indirectly_, by virtue of being a sub-action of `#AddHello`.
To learn more about the structure of a plan, see [it all begins with a plan](./1202-plan.md). To learn more about the structure of a plan, see [it all begins with a plan](./1202-plan.md).

View File

@ -1,6 +1,6 @@
--- ---
slug: /1200/local-dev slug: /1200/local-dev
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# CI/CD in your local dev # CI/CD in your local dev
@ -215,7 +215,7 @@ From a powershell terminal, run:
Invoke-WebRequest -UseBasicParsing -Uri https://dl.dagger.io/dagger/install.ps1 | Invoke-Expression Invoke-WebRequest -UseBasicParsing -Uri https://dl.dagger.io/dagger/install.ps1 | Invoke-Expression
``` ```
We'll save everything under `<your home folder>/dagger` We'll save everything under `<your home folder>/dagger`
Check that `dagger` is installed correctly by opening a `Command Prompt` terminal and run: Check that `dagger` is installed correctly by opening a `Command Prompt` terminal and run:

View File

@ -1,6 +1,6 @@
--- ---
slug: /1201/ci-environment slug: /1201/ci-environment
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Integrating with your CI environment # Integrating with your CI environment
@ -48,57 +48,56 @@ If you would like us to document CircleCI next, vote for it here: [dagger#1677](
```yaml ```yaml
.docker: .docker:
image: docker:${DOCKER_VERSION}-git image: docker:${DOCKER_VERSION}-git
services: services:
- docker:${DOCKER_VERSION}-dind - docker:${DOCKER_VERSION}-dind
variables: variables:
# See https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#docker-in-docker-with-tls-enabled-in-the-docker-executor # See https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#docker-in-docker-with-tls-enabled-in-the-docker-executor
DOCKER_HOST: tcp://docker:2376 DOCKER_HOST: tcp://docker:2376
DOCKER_TLS_VERIFY: '1' DOCKER_TLS_VERIFY: '1'
DOCKER_TLS_CERTDIR: '/certs' DOCKER_TLS_CERTDIR: '/certs'
DOCKER_CERT_PATH: '/certs/client' DOCKER_CERT_PATH: '/certs/client'
# Faster than the default, apparently # Faster than the default, apparently
DOCKER_DRIVER: overlay2 DOCKER_DRIVER: overlay2
DOCKER_VERSION: '20.10' DOCKER_VERSION: '20.10'
.dagger: .dagger:
extends: [.docker] extends: [.docker]
variables: variables:
DAGGER_VERSION: 0.2.4 DAGGER_VERSION: 0.2.4
DAGGER_LOG_FORMAT: plain DAGGER_LOG_FORMAT: plain
DAGGER_CACHE_PATH: .dagger-cache DAGGER_CACHE_PATH: .dagger-cache
ARGS: '' ARGS: ''
cache: cache:
key: dagger-${CI_JOB_NAME} key: dagger-${CI_JOB_NAME}
paths: paths:
- ${DAGGER_CACHE_PATH} - ${DAGGER_CACHE_PATH}
before_script: before_script:
- apk add --no-cache curl - apk add --no-cache curl
- | - |
# install dagger # install dagger
cd /usr/local cd /usr/local
curl -L https://dl.dagger.io/dagger/install.sh | sh curl -L https://dl.dagger.io/dagger/install.sh | sh
cd - cd -
dagger version dagger version
script: script:
- dagger project update - dagger project update
- | - |
dagger \ dagger \
do \ do \
--cache-from type=local,src=${DAGGER_CACHE_PATH} \ --cache-from type=local,src=${DAGGER_CACHE_PATH} \
--cache-to type=local,mode=max,dest=${DAGGER_CACHE_PATH} \ --cache-to type=local,mode=max,dest=${DAGGER_CACHE_PATH} \
${ARGS} ${ARGS}
build: build:
extends: [.dagger] extends: [.dagger]
variables: variables:
ARGS: build ARGS: build
``` ```
</TabItem> </TabItem>

View File

@ -1,6 +1,6 @@
--- ---
slug: /1220/vs slug: /1220/vs
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Dagger vs. Other Software # Dagger vs. Other Software
@ -9,16 +9,16 @@ displayed_sidebar: europa
Dagger does not replace your CI: it improves it by adding a portable development layer on top of it. Dagger does not replace your CI: it improves it by adding a portable development layer on top of it.
* Dagger runs on all major CI products. This *reduces CI lock-in*: you can change CI without rewriting all your pipelines. - Dagger runs on all major CI products. This _reduces CI lock-in_: you can change CI without rewriting all your pipelines.
* Dagger also runs on your dev machine. This allows *dev/CI parity*: the same pipelines can be used in CI and development. - Dagger also runs on your dev machine. This allows _dev/CI parity_: the same pipelines can be used in CI and development.
## Dagger vs. PaaS (Heroku, Firebase, etc.) ## Dagger vs. PaaS (Heroku, Firebase, etc.)
Dagger is not a PaaS, but you can use it to add PaaS-like features to your CICD pipelines: Dagger is not a PaaS, but you can use it to add PaaS-like features to your CICD pipelines:
* A simple deployment abstraction for the developer - A simple deployment abstraction for the developer
* A catalog of possible customizations, managed by the platform team - A catalog of possible customizations, managed by the platform team
* On-demand staging or development environments - On-demand staging or development environments
Using Dagger is a good way to get many of the benefits of a PaaS (developer productivity and peace of mind), Using Dagger is a good way to get many of the benefits of a PaaS (developer productivity and peace of mind),
without giving up the benefits of custom CICD pipelines (full control over your infrastructure and tooling). without giving up the benefits of custom CICD pipelines (full control over your infrastructure and tooling).
@ -29,15 +29,15 @@ Most applications have a custom deploy script that usually gets the job done, bu
Using Dagger, you have two options: Using Dagger, you have two options:
1. You can *replace* your script with a DAG that is better in every way: more features, more reliable, faster, easier to read, improve, and debug. 1. You can _replace_ your script with a DAG that is better in every way: more features, more reliable, faster, easier to read, improve, and debug.
2. You can *extend* your script by wrapping it, as-is, into a DAG. This allows you to start using Dagger right away, and worry about rewrites later. 2. You can _extend_ your script by wrapping it, as-is, into a DAG. This allows you to start using Dagger right away, and worry about rewrites later.
## Dagger vs. Infrastructure as Code (Terraform, Pulumi, Cloudformation, CDK) ## Dagger vs. Infrastructure as Code (Terraform, Pulumi, Cloudformation, CDK)
Dagger is the perfect complement to an IaC tool. Dagger is the perfect complement to an IaC tool.
* IaC tools help infrastructure teams answer questions like: what is the current state of my infrastructure? What is its desired state? And how do I get there? - IaC tools help infrastructure teams answer questions like: what is the current state of my infrastructure? What is its desired state? And how do I get there?
* Dagger helps CICD teams answer question like: what work needs to be done to deliver my application, in what order, and how do I orchestrate it? - Dagger helps CICD teams answer question like: what work needs to be done to deliver my application, in what order, and how do I orchestrate it?
It is very common for a Dagger configuration to integrate with at least one IaC tool. It is very common for a Dagger configuration to integrate with at least one IaC tool.

View File

@ -1,6 +1,6 @@
--- ---
slug: / slug: /
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Getting Started # Getting Started

View File

@ -1,6 +1,6 @@
--- ---
slug: /1205/container-images slug: /1205/container-images
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Building container images # Building container images
@ -11,9 +11,10 @@ You can use Dagger to build container images, either by executing a Dockerfile,
Dagger can natively load and execute Dockerfiles. This is recommended in cases where compatibility with existing Dockerfiles is more important than fully leveraging the power of CUE. Dagger can natively load and execute Dockerfiles. This is recommended in cases where compatibility with existing Dockerfiles is more important than fully leveraging the power of CUE.
Here's a simple example of a [Dockerfile](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) build: Here's a simple example of a [Dockerfile](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) build:
```cue file=../tests/core-concepts/container-images/simple/with-dockerfile.cue ```cue file=../tests/core-concepts/container-images/simple/with-dockerfile.cue
``` ```
## Specifying a build in CUE ## Specifying a build in CUE
@ -23,6 +24,7 @@ You can specify your container build natively in CUE, using the official Docker
Native CUE builds have the same backend as Dockerfile builds, so all the same features are available. Since CUE is a more powerful language than the Dockerfile syntax, every Dockerfile can be ported to an equivalent CUE configuration, but the opposite is not true. The following example produces the same image as above. Native CUE builds have the same backend as Dockerfile builds, so all the same features are available. Since CUE is a more powerful language than the Dockerfile syntax, every Dockerfile can be ported to an equivalent CUE configuration, but the opposite is not true. The following example produces the same image as above.
```cue file=../tests/core-concepts/container-images/simple/build.cue ```cue file=../tests/core-concepts/container-images/simple/build.cue
``` ```
Because this build configuration is pure CUE, it can leverage the full power of Dagger's composition model. Because this build configuration is pure CUE, it can leverage the full power of Dagger's composition model.
@ -32,6 +34,7 @@ Because this build configuration is pure CUE, it can leverage the full power of
Building images in CUE gives you greater flexibility. For example, you can automate building multiple versions of an image, and deploy, all in Dagger: Building images in CUE gives you greater flexibility. For example, you can automate building multiple versions of an image, and deploy, all in Dagger:
```cue file=../tests/core-concepts/container-images/template/dagger.cue ```cue file=../tests/core-concepts/container-images/template/dagger.cue
``` ```
Now you can deploy all versions: Now you can deploy all versions:
@ -51,4 +54,5 @@ dagger do versions 8.0 build
Another common pattern is [multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds). This allows you to have heavier build images during the build process, and copy the built artifacts into a cleaner and lighter image to run in production. Another common pattern is [multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds). This allows you to have heavier build images during the build process, and copy the built artifacts into a cleaner and lighter image to run in production.
```cue file=../tests/core-concepts/container-images/multi-stage/dagger.cue ```cue file=../tests/core-concepts/container-images/multi-stage/dagger.cue
``` ```

View File

@ -1,6 +1,6 @@
--- ---
slug: /1216/docker-cli-load slug: /1216/docker-cli-load
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Loading a dagger image into a docker daemon # Loading a dagger image into a docker daemon
@ -12,9 +12,11 @@ It can be useful to debug or test a build locally before pushing.
## Local daemon ## Local daemon
```cue file=../plans/docker-cli-load/local.cue ```cue file=../plans/docker-cli-load/local.cue
``` ```
## Remote daemon, via SSH ## Remote daemon, via SSH
```cue file=../plans/docker-cli-load/ssh.cue ```cue file=../plans/docker-cli-load/ssh.cue
``` ```

View File

@ -1,6 +1,6 @@
--- ---
slug: /1217/docker-cli-run slug: /1217/docker-cli-run
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Running commands with the docker binary (CLI) # Running commands with the docker binary (CLI)
@ -10,14 +10,17 @@ There's a `universe.dagger.io/docker/cli` package that allows you to run docker
## Local daemon ## Local daemon
```cue file=../plans/docker-cli-run/local.cue ```cue file=../plans/docker-cli-run/local.cue
``` ```
## Remote daemon, via SSH ## Remote daemon, via SSH
```cue file=../plans/docker-cli-run/ssh.cue ```cue file=../plans/docker-cli-run/ssh.cue
``` ```
## Remote daemon, via HTTPS ## Remote daemon, via HTTPS
```cue file=../plans/docker-cli-run/tcp.cue ```cue file=../plans/docker-cli-run/tcp.cue
``` ```

View File

@ -1,6 +1,6 @@
--- ---
slug: /1218/cli-telemetry slug: /1218/cli-telemetry
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Understanding CLI Telemetry # Understanding CLI Telemetry
@ -15,10 +15,10 @@ us better understand how Dagger is used, and will allow us to improve your exper
The following information is included in telemetry: The following information is included in telemetry:
* Dagger version - Dagger version
* Platform information - Platform information
* Command run - Command run
* Anonymous device ID - Anonymous device ID
We use telemetry for aggregate analysis, and do not tie telemetry events to a specific identity. We use telemetry for aggregate analysis, and do not tie telemetry events to a specific identity.

View File

@ -1,6 +1,6 @@
--- ---
slug: /1226/coding-style slug: /1226/coding-style
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Package Coding Style # Package Coding Style
@ -59,7 +59,7 @@ Choose `_camelCase` for private fields (implementation details).
} }
``` ```
## Definitions for *schemas*, fields for concrete *implementations* ## Definitions for _schemas_, fields for concrete _implementations_
```cue ```cue
// good, defines a schema // good, defines a schema
@ -187,7 +187,7 @@ run: bash.#Run & {
## Dont inline scripts ## Dont inline scripts
Avoid inlining scripts (e.g., *sh*, *py*, etc). Instead, put them in their own files Avoid inlining scripts (e.g., _sh_, _py_, etc). Instead, put them in their own files
with proper extension, and use `core.#Source` to import into CUE. This allows linting with proper extension, and use `core.#Source` to import into CUE. This allows linting
and avoids some limitations (script size, escaping). and avoids some limitations (script size, escaping).
@ -259,7 +259,7 @@ run: python.#Run & {
} }
``` ```
## Favor disjunctions over *if* conditions ## Favor disjunctions over _if_ conditions
```cue ```cue
// bad // bad
@ -283,7 +283,7 @@ if type == "cache" {
} }
``` ```
## Favor templates over *for* loops ## Favor templates over _for_ loops
```cue ```cue
// bad // bad
@ -334,11 +334,11 @@ files: {
} }
``` ```
## Use *top* to match anything ## Use _top_ to match anything
From [CUE](https://cuelang.org/docs/references/spec/#values-1): From [CUE](https://cuelang.org/docs/references/spec/#values-1):
> At the top of the lattice is the single ancestor of all values, called *top*, denoted `_` in CUE. Every value is an instance of top. > At the top of the lattice is the single ancestor of all values, called _top_, denoted `_` in CUE. Every value is an instance of top.
There's a recurring theme when you have a template and need to create instances from it: There's a recurring theme when you have a template and need to create instances from it:

View File

@ -1,16 +1,16 @@
--- ---
slug: /1200/what/ slug: /1000/what/
--- ---
# What is Dagger? # What is Dagger?
Dagger is a portable devkit for CICD. It helps you develop powerful CICD pipelines that can run anywhere. Dagger is a portable devkit for CICD. It helps you develop powerful CICD pipelines that can run anywhere.
* Choose from a wide catalog of reusable actions, or create your own in your favorite programming language. - Choose from a wide catalog of reusable actions, or create your own in your favorite programming language.
* Tie it all together with [CUE](https://cuelang.org), the next-generation declarative language invented at Google. No more YAML hell! - Tie it all together with [CUE](https://cuelang.org), the next-generation declarative language invented at Google. No more YAML hell!
* Unify dev and CI. The same Dagger pipeline can run on your dev machine or in CI. All you need is a Docker-compatible runtime. - Unify dev and CI. The same Dagger pipeline can run on your dev machine or in CI. All you need is a Docker-compatible runtime.
* Avoid CI lock-in. Dagger runs natively on GitHub Actions, GitLab, CircleCI, Jenkins, AWS Codebuild, Tekton, and more. - Avoid CI lock-in. Dagger runs natively on GitHub Actions, GitLab, CircleCI, Jenkins, AWS Codebuild, Tekton, and more.
* Test and debug your pipelines locally; catch configuration errors in seconds with static type checking. - Test and debug your pipelines locally; catch configuration errors in seconds with static type checking.
<img src="/img/what-is-dagger.png" alt="Dagger_Website_Ship" style={{maxWidth: '50%'}} /> <img src="/img/what-is-dagger.png" alt="Dagger_Website_Ship" style={{maxWidth: '50%'}} />

View File

@ -24,7 +24,7 @@ function new() {
cat <<- EOF > "$filename" cat <<- EOF > "$filename"
--- ---
slug: /$next/$name slug: /$next/$name
displayed_sidebar: europa displayed_sidebar: "0.2"
--- ---
EOF EOF
} }

View File

@ -1,6 +1,6 @@
--- ---
slug: /1222/core-actions-reference slug: /1222/core-actions-reference
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Core Actions Reference # Core Actions Reference
@ -13,40 +13,40 @@ The following core actions are available:
## Core Actions related to filesystem trees ## Core Actions related to filesystem trees
| Definition | File | Description | | Definition | File | Description |
| :-- | :-- | :-- | | :----------- | :-------------------------------------------------------------------------------------- | :-------------------------------------------------------------------- |
| `#Copy` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Copy files between two filesystem trees | | `#Copy` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Copy files between two filesystem trees |
| `#Diff` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Extract the difference between two filesystems as its own file system | | `#Diff` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Extract the difference between two filesystems as its own file system |
| `#Merge` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Merge multiple filesystem trees | | `#Merge` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Merge multiple filesystem trees |
| `#Mkdir` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Create a directory in a filesystem tree | | `#Mkdir` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Create a directory in a filesystem tree |
| `#ReadFile` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Read a file from a filesystem tree | | `#ReadFile` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Read a file from a filesystem tree |
| `#Scratch` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Create an empty filesystem tree | | `#Scratch` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Create an empty filesystem tree |
| `#Source` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Access the source for the current CUE package | | `#Source` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Access the source for the current CUE package |
| `#Subdir` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Read a subdirectory from a filesystem tree | | `#Subdir` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Read a subdirectory from a filesystem tree |
| `#WriteFile` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Write a file to a filesystem tree | | `#WriteFile` | [fs.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/fs.cue) | Write a file to a filesystem tree |
## Core Actions related to secrets ## Core Actions related to secrets
| Definition | File | Description | | Definition | File | Description |
| :-- | :-- | :-- | | :-------------- | :------------------------------------------------------------------------------------------------ | :------------------------------------------------------- |
| `#DecodeSecret` | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Decode a secret without leaking its contents | | `#DecodeSecret` | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Decode a secret without leaking its contents |
| `#NewSecret` | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Create a new a secret from a filesystem tree | | `#NewSecret` | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Create a new a secret from a filesystem tree |
| `#TrimSecret` | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Trim leading and trailing space characters from a secret | | `#TrimSecret` | [secrets.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/secrets.cue) | Trim leading and trailing space characters from a secret |
## Core Actions related to containers ## Core Actions related to containers
| Definition | File | Description | | Definition | File | Description |
| :-- | :-- | :-- | | :------------ | :-------------------------------------------------------------------------------------------- | :------------------------------------------------- |
| `#Dockerfile` | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Build a container image using a Dockerfile | | `#Dockerfile` | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Build a container image using a Dockerfile |
| `#Exec` | [exec.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/exec.cue) | Execute a command in a docker-compatible container | | `#Exec` | [exec.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/exec.cue) | Execute a command in a docker-compatible container |
| `#Export` | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Export a docker image as a tar archive | | `#Export` | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Export a docker image as a tar archive |
| `#Pull` | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Download an image from a docker registry | | `#Pull` | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Download an image from a docker registry |
| `#Push` | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Upload an image to a docker registry | | `#Push` | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Upload an image to a docker registry |
| `#Set` | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Modify a docker image config | | `#Set` | [image.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/image.cue) | Modify a docker image config |
## Core Actions related to remote data sources ## Core Actions related to remote data sources
| Definition | File | Description | | Definition | File | Description |
| :-- | :-- | :-- | | :----------- | :------------------------------------------------------------------------------------------ | :--------------------------------------------- |
| `#GitPull` | [git.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/git.cue) | Download a repository from a remote git server | | `#GitPull` | [git.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/git.cue) | Download a repository from a remote git server |
| `#HTTPFetch` | [http.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/http.cue) | Get a file from an HTTP server | | `#HTTPFetch` | [http.cue](https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/core/http.cue) | Get a file from an HTTP server |

View File

@ -1,6 +1,6 @@
--- ---
slug: /1208/phoenix-kubernetes slug: /1208/phoenix-kubernetes
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Elixir/Phoenix on Kubernetes # Elixir/Phoenix on Kubernetes

View File

@ -1,6 +1,6 @@
--- ---
slug: /1209/docusaurus-netlify slug: /1209/docusaurus-netlify
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Docusaurus on Netlify # Docusaurus on Netlify

View File

@ -1,6 +1,6 @@
--- ---
slug: /1210/go-goreleaser slug: /1210/go-goreleaser
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Go with GoReleaser # Go with GoReleaser

View File

@ -1,6 +1,6 @@
--- ---
slug: /1211/go-docker-swarm slug: /1211/go-docker-swarm
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Go on Docker Swarm # Go on Docker Swarm

View File

@ -1,6 +1,6 @@
--- ---
slug: /1212/svelte-vercel slug: /1212/svelte-vercel
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Svelte on Vercel # Svelte on Vercel

View File

@ -1,6 +1,6 @@
--- ---
slug: /1219/go-docker-hub slug: /1219/go-docker-hub
displayed_sidebar: europa displayed_sidebar: '0.2'
--- ---
# Go on Docker Hub # Go on Docker Hub
@ -22,6 +22,7 @@ You can indeed choose which files to include. Since it's a Golang project
it should contain the module and all Go source files: it should contain the module and all Go source files:
```cue file=../tests/use-cases/ci-cd-for-go-project/retrieve-go-project/dagger.cue ```cue file=../tests/use-cases/ci-cd-for-go-project/retrieve-go-project/dagger.cue
``` ```
:::tip :::tip
@ -38,6 +39,7 @@ to build your pipeline, but your project may use `CGO` or any external dependenc
You can customize the base image to install required dependencies: You can customize the base image to install required dependencies:
```cue file=../tests/use-cases/ci-cd-for-go-project/base.cue.fragment ```cue file=../tests/use-cases/ci-cd-for-go-project/base.cue.fragment
``` ```
## Run unit tests ## Run unit tests
@ -48,9 +50,11 @@ Use the [#Test](https://github.com/dagger/dagger/blob/main/pkg/universe.dagger.i
definition: definition:
```cue file=../tests/use-cases/ci-cd-for-go-project/test.cue.fragment ```cue file=../tests/use-cases/ci-cd-for-go-project/test.cue.fragment
``` ```
<!-- FIXME(TomChv): we should write a bunch of documentation about TDD with dagger --> <!-- FIXME(TomChv): we should write a bunch of documentation about TDD with dagger -->
:::tip :::tip
You can also use Dagger to write integration tests. You can also use Dagger to write integration tests.
::: :::
@ -63,6 +67,7 @@ Use the [#Build](https://github.com/dagger/dagger/blob/main/pkg/universe.dagger.
definition to do that: definition to do that:
```cue file=../tests/use-cases/ci-cd-for-go-project/build.cue.fragment ```cue file=../tests/use-cases/ci-cd-for-go-project/build.cue.fragment
``` ```
:::tip :::tip
@ -76,6 +81,7 @@ To make it usable for other users, you must put your binary in an image and set
For optimization purposes, you can use alpine as the base image to contain your binary: For optimization purposes, you can use alpine as the base image to contain your binary:
```cue file=../tests/use-cases/ci-cd-for-go-project/image.cue.fragment ```cue file=../tests/use-cases/ci-cd-for-go-project/image.cue.fragment
``` ```
## Push to Docker Hub ## Push to Docker Hub
@ -98,6 +104,7 @@ dagger.#Plan & {
You can now push your image: You can now push your image:
```cue file=../tests/use-cases/ci-cd-for-go-project/push.cue.fragment ```cue file=../tests/use-cases/ci-cd-for-go-project/push.cue.fragment
``` ```
## Complete CI/CD ## Complete CI/CD
@ -106,6 +113,7 @@ After merging all examples, you will have a complete CI/CD to deliver a Go
binary on Docker Hub. binary on Docker Hub.
```cue file=../tests/use-cases/ci-cd-for-go-project/complete-ci-cd/dagger.cue ```cue file=../tests/use-cases/ci-cd-for-go-project/complete-ci-cd/dagger.cue
``` ```
You can then use `dagger do` to select which action you want to run. You can then use `dagger do` to select which action you want to run.

View File

@ -10,71 +10,7 @@
*/ */
module.exports = { module.exports = {
preEuropa: [ "0.2": [
{
type: "category",
label: "Introduction",
collapsible: true,
items: ["introduction/what_is", "introduction/vs"],
},
{
type: "doc",
id: "install",
},
{
type: "category",
label: "Learn Dagger",
collapsible: true,
collapsed: false,
items: [
"learn/what_is_cue",
"learn/get-started",
"learn/google-cloud-run",
"learn/kubernetes",
"learn/aws-cloudformation",
"learn/github-actions",
"learn/dev-cue-package",
"learn/package-manager",
],
},
{
type: "category",
label: "Use Cases",
collapsible: true,
collapsed: true,
items: ["use-cases/ci"],
},
{
type: "category",
label: "Universe - API Reference",
collapsible: true,
collapsed: true,
// generate the sidebar for reference doc automatically
items: [
{
type: "autogenerated",
dirName: "reference",
},
],
},
{
type: "category",
label: "Administrator Manual",
collapsible: true,
collapsed: true,
items: ["administrator/operator-manual"],
},
{
type: "link",
label: "Dagger 0.2 ➡️",
href: "/",
},
],
europa: [
{
type: "doc",
id: "migrate-from-dagger-0.1",
},
{ {
type: "category", type: "category",
label: "Getting Started", label: "Getting Started",
@ -142,10 +78,74 @@ module.exports = {
"use-cases/go-docker-swarm", "use-cases/go-docker-swarm",
], ],
}, },
{
type: "doc",
id: "migrate-from-dagger-0.1",
},
{ {
type: "link", type: "link",
label: "⬅️ Dagger 0.1", label: "⬅️ Dagger 0.1",
href: "/1200/what/", href: "/0.1",
},
],
"0.1": [
{
type: "category",
label: "Introduction",
collapsible: true,
items: ["introduction/what_is", "introduction/vs"],
},
{
type: "doc",
id: "install",
},
{
type: "category",
label: "Learn Dagger",
collapsible: true,
collapsed: false,
items: [
"learn/what_is_cue",
"learn/get-started",
"learn/google-cloud-run",
"learn/kubernetes",
"learn/aws-cloudformation",
"learn/github-actions",
"learn/dev-cue-package",
"learn/package-manager",
],
},
{
type: "category",
label: "Use Cases",
collapsible: true,
collapsed: true,
items: ["use-cases/ci"],
},
{
type: "category",
label: "Universe - API Reference",
collapsible: true,
collapsed: true,
// generate the sidebar for reference doc automatically
items: [
{
type: "autogenerated",
dirName: "reference",
},
],
},
{
type: "category",
label: "Administrator Manual",
collapsible: true,
collapsed: true,
items: ["administrator/operator-manual"],
},
{
type: "link",
label: "Dagger 0.2 ➡️",
href: "/",
}, },
], ],
}; };

View File

@ -0,0 +1,12 @@
import React from 'react'
function DeprecatedVersionBanner() {
return (
<div class="theme-doc-version-banner alert alert--warning margin-bottom--md" role="alert">
<div>This is documentation for Dagger <b>0.1</b>, which is no longer actively maintained.</div>
<div class="margin-top--md">For up-to-date documentation, see the <b><a href="/">latest version</a></b> (0.2).</div>
</div>
)
}
export default DeprecatedVersionBanner

View File

@ -27,6 +27,7 @@ import {
} from '@docusaurus/theme-common'; } from '@docusaurus/theme-common';
import Head from '@docusaurus/Head'; import Head from '@docusaurus/Head';
import amplitude from 'amplitude-js'; import amplitude from 'amplitude-js';
import DeprecatedVersionBanner from '../../components/DeprecatedVersionBanner';
function DocPageContent({ function DocPageContent({
currentDocRoute, currentDocRoute,
@ -171,6 +172,9 @@ function DocPage(props) {
currentDocRoute={currentDocRoute} currentDocRoute={currentDocRoute}
versionMetadata={versionMetadata} versionMetadata={versionMetadata}
sidebarName={sidebarName}> sidebarName={sidebarName}>
{currentDocRoute.sidebar === '0.1' && (
<DeprecatedVersionBanner />
)}
<div data-cy="cy-doc-content"> <div data-cy="cy-doc-content">
{renderRoutes(docRoutes, { {renderRoutes(docRoutes, {
versionMetadata, versionMetadata,