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

website: hardcode version banner for 0.1 docs

Browse Source 
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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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!

2
docs/1214-migrate-from-dagger-0.1.md
View File

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

1
docs/administrator/1013-operator-manual.md
View File

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

3
docs/core-concepts/1202-plan.md
View File

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

9
docs/core-concepts/1203-client.md
View File

@ -1,6 +1,6 @@
---
slug: /1203/client
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# 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:
```cue file=../tests/core-concepts/client/plans/fs.cue
```
It’s also easy to write a file locally:
```cue file=../tests/core-concepts/client/plans/file.cue
```
## Using a local socket
@ -40,6 +42,7 @@ import BrowserOnly from '@docusaurus/BrowserOnly';
<TabItem value="unix" label="Linux/macOS">
```cue file=../tests/core-concepts/client/plans/unix.cue
```
</TabItem>
@ -47,6 +50,7 @@ import BrowserOnly from '@docusaurus/BrowserOnly';
<TabItem value="windows" label="Windows">
```cue file=../tests/core-concepts/client/plans/windows.cue
```
</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:
```cue file=../tests/core-concepts/client/plans/env.cue
```
## 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:
```cue file=../tests/core-concepts/client/plans/cmd.cue
```
:::tip
@ -77,4 +83,5 @@ You can also capture `stderr` for errors and provide `stdin` for input.
If you need the current platform though, there’s a more portable way than running `uname` like in the previous example:
```cue file=../tests/core-concepts/client/plans/platform.cue
```

7
docs/core-concepts/1204-secrets.md
View File

@ -1,6 +1,6 @@
---
slug: /1204/secrets
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# How to use secrets
@ -28,6 +28,7 @@ dagger.#Plan & {
You may need to trim the whitespace, especially when reading from a file:
```cue file=../tests/core-concepts/secrets/plans/file.cue
```
## SOPS
@ -36,9 +37,9 @@ There’s many ways to store encrypted secrets in your git repository. If you us
```yaml title="secrets.yaml"
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"
```

2
docs/core-concepts/1206-packages.md
View File

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

2
docs/core-concepts/1207-caching.md
View File

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

10
docs/core-concepts/1213-dagger-cue.md
View File

@ -1,6 +1,6 @@
---
slug: /1213/api
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# 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`
| 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 |
### 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:
| Definition | File | Description |
| :-- | :-- | :-- |
| :------------- | :------------------------------------------------------------------------------------------ | :---------------------------------------------------- |
| `#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 |
| `#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.
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.
The following core actions are available:
| 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 |
| `#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 |

22
docs/core-concepts/1221-action.md
View File

@ -1,6 +1,6 @@
---
slug: /1221/action
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# 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.
There are two types of actions: *core actions* and *composite actions*.
There are two types of actions: _core actions_ and _composite actions_.
## Core Actions
@ -36,7 +36,7 @@ A composite action's lifecycle has 4 stages:
### 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:
@ -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.
* "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.
* "sub-actions" are simply fields which contain another action definition. For example, `write` is a sub-action.
- "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.
- "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.
@ -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:
* What actions to present to the end user
* Dependencies between those tasks, if any
* Interactions between the tasks and the client system, if any
- What actions to present to the end user
- Dependencies between those tasks, 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:
@ -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).

2
docs/getting-started/1200-local-dev.md
View File

@ -1,6 +1,6 @@
---
slug: /1200/local-dev
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# CI/CD in your local dev

3
docs/getting-started/1201-ci-environment.md
View File

@ -1,6 +1,6 @@
---
slug: /1201/ci-environment
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# Integrating with your CI environment
@ -98,7 +98,6 @@ build:
extends: [.dagger]
variables:
ARGS: build
```
</TabItem>

20
docs/getting-started/1220-vs.md
View File

@ -1,6 +1,6 @@
---
slug: /1220/vs
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# 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 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 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 vs. PaaS (Heroku, Firebase, etc.)
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 catalog of possible customizations, managed by the platform team
* On-demand staging or development environments
- A simple deployment abstraction for the developer
- A catalog of possible customizations, managed by the platform team
- 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),
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:
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.
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.
## Dagger vs. Infrastructure as Code (Terraform, Pulumi, Cloudformation, CDK)
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?
* 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?
- 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?
It is very common for a Dagger configuration to integrate with at least one IaC tool.

2
docs/getting-started/index.md
View File

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

6
docs/guides/1205-container-images.md
View File

@ -1,6 +1,6 @@
---
slug: /1205/container-images
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# Building container images
@ -14,6 +14,7 @@ Dagger can natively load and execute Dockerfiles. This is recommended in cases w
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
```
## 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.
```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.
@ -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:
```cue file=../tests/core-concepts/container-images/template/dagger.cue
```
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.
```cue file=../tests/core-concepts/container-images/multi-stage/dagger.cue
```

4
docs/guides/1216-docker-cli-load.md
View File

@ -1,6 +1,6 @@
---
slug: /1216/docker-cli-load
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# 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
```cue file=../plans/docker-cli-load/local.cue
```
## Remote daemon, via SSH
```cue file=../plans/docker-cli-load/ssh.cue
```

5
docs/guides/1217-docker-cli-run.md
View File

@ -1,6 +1,6 @@
---
slug: /1217/docker-cli-run
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# 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
```cue file=../plans/docker-cli-run/local.cue
```
## Remote daemon, via SSH
```cue file=../plans/docker-cli-run/ssh.cue
```
## Remote daemon, via HTTPS
```cue file=../plans/docker-cli-run/tcp.cue
```

10
docs/guides/1218-cli-telemetry.md
View File

@ -1,6 +1,6 @@
---
slug: /1218/cli-telemetry
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# 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:
* Dagger version
* Platform information
* Command run
* Anonymous device ID
- Dagger version
- Platform information
- Command run
- Anonymous device ID
We use telemetry for aggregate analysis, and do not tie telemetry events to a specific identity.

14
docs/guides/1226-coding-style.md
View File

@ -1,6 +1,6 @@
---
slug: /1226/coding-style
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# 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
// good, defines a schema
@ -187,7 +187,7 @@ run: bash.#Run & {
## Don’t 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
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
// bad
@ -283,7 +283,7 @@ if type == "cache" {
}
```
## Favor templates over *for* loops
## Favor templates over _for_ loops
```cue
// 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):
> 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:

12
docs/introduction/1000-what_is.md
View File

@ -1,16 +1,16 @@
---
slug: /1200/what/
slug: /1000/what/
---
# What is Dagger?
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.
* 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.
* 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.
- 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!
- 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.
- 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%'}} />

2
docs/new.sh
View File

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

10
docs/references/1222-core-actions-reference.md
View File

@ -1,6 +1,6 @@
---
slug: /1222/core-actions-reference
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# Core Actions Reference
@ -14,7 +14,7 @@ The following core actions are available:
## Core Actions related to filesystem trees
| 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 |
| `#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 |
@ -28,7 +28,7 @@ The following core actions are available:
## Core Actions related to secrets
| 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 |
| `#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 |
@ -36,7 +36,7 @@ The following core actions are available:
## Core Actions related to containers
| 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 |
| `#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 |
@ -47,6 +47,6 @@ The following core actions are available:
## Core Actions related to remote data sources
| 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 |
| `#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 |

2
docs/use-cases/1208-phoenix-kubernetes.md
View File

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

2
docs/use-cases/1209-docusaurus-netlify.md
View File

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

2
docs/use-cases/1210-go-goreleaser.md
View File

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

2
docs/use-cases/1211-go-docker-swarm.md
View File

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

2
docs/use-cases/1212-svelte-vercel.md
View File

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

10
docs/use-cases/1219-go-docker-hub.md
View File

@ -1,6 +1,6 @@
---
slug: /1219/go-docker-hub
displayed_sidebar: europa
displayed_sidebar: '0.2'
---
# 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:
```cue file=../tests/use-cases/ci-cd-for-go-project/retrieve-go-project/dagger.cue
```
:::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:
```cue file=../tests/use-cases/ci-cd-for-go-project/base.cue.fragment
```
## Run unit tests
@ -48,9 +50,11 @@ Use the [#Test](https://github.com/dagger/dagger/blob/main/pkg/universe.dagger.i
definition:
```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 -->
:::tip
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:
```cue file=../tests/use-cases/ci-cd-for-go-project/build.cue.fragment
```
:::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:
```cue file=../tests/use-cases/ci-cd-for-go-project/image.cue.fragment
```
## Push to Docker Hub
@ -98,6 +104,7 @@ dagger.#Plan & {
You can now push your image:
```cue file=../tests/use-cases/ci-cd-for-go-project/push.cue.fragment
```
## 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.
```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.

132
website/sidebars.js
View File

@ -10,71 +10,7 @@
*/
module.exports = {
preEuropa: [
{
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",
},
"0.2": [
{
type: "category",
label: "Getting Started",
@ -142,10 +78,74 @@ module.exports = {
"use-cases/go-docker-swarm",
],
},
{
type: "doc",
id: "migrate-from-dagger-0.1",
},
{
type: "link",
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: "/",
},
],
};

12
website/src/components/DeprecatedVersionBanner.js Normal file
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

4
website/src/theme/DocPage/index.js
View File

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