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

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).