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

docs: Implement FAQ page, default values in Cue + fix sidebar and titles

Browse Source 
Move faq pages from guide to specific FAQ page, shown as per tailscale format.
Custom in-house logic implemented because Docusaurus doesn't manage it

Signed-off-by: guillaume <guillaume.derouville@gmail.com>
This commit is contained in:
guillaume
2022-04-12 18:41:07 +02:00
parent 15ccee2eaa
commit 204d067bcc
6 changed files with 54 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
docs/guides/1227-empty-buildkit-cache.md
View File

@@ -1,22 +0,0 @@
---
slug: /1227/empty-buildkit-cache
displayed_sidebar: europa
---
# How to empty BuildKit's cache ?
There are two ways of emptying the BuildKit cache:
- Run your action with the `--no-cache` option:
```console
dagger do <your-action> --no-cache
```
- Stop and remove the buildkitd container and remove its associated volume:
```console
docker stop dagger-buildkitd ; docker rm dagger-buildkitd ; docker volume rm dagger-buildkitd
```
In 99.9% of the cases, the first solution is enough

23
docs/guides/1228-better-logs.md
View File

@@ -1,23 +0,0 @@
---
slug: /1228/better-logs
displayed_sidebar: europa
---
# How can I have better logs ?
Dagger exposes 2 logging format options:
- `--log-format auto|plain|tty|json`
The default mode is `auto`. If you want to keep each actions' logs, use the `plain` mode
- `--log-level panic|fatal|error|warn|info|debug|trace`
`debug` is useful to check whether an explicit dependency has been found between two actions.
You can also export these options as env variables:
```console
export DAGGER_LOG_FORMAT="plain"
export DAGGER_LOG_LEVEL="debug"
```

24
docs/guides/1229-always-execute.md
View File

@@ -1,24 +0,0 @@
---
slug: /1229/always-execute
displayed_sidebar: europa
---
# How to make sure an action is always being executed ?
Dagger implemented a way to tell Buildkit not to rely on cache for a specific action.
The `docker.#Run` and `core.#Exec` definitions have an `always` field:
```cue
// If set to true, the cache will never be triggered for that specific action.
always: bool | *false
```
Any package composed on top of it (`bash.#Run` for example) also exposes this field as it will inherit it from `docker.#Run`:
```cue
test: bash.#Run & {
always: true
...
}
```

54
docs/guides/1230-chain-actions.md
View File

@@ -1,54 +0,0 @@
---
slug: /1230/chain-actions
displayed_sidebar: europa
---
# How can I chain actions together ?
Dependencies are materialized at runtime, when your Cue files are parsed and the corresponding DAG gets generated:
```cue
// Prerequisite action that runs when `test` is being called
_dockerCLI: alpine.#Build & {
packages: {
bash: {}
}
}
// Main action
foo: bash.#Run & {
input: _dockerCLI.output // <== CHAINING of action happening here
always: true
script: contents: #"""
echo "bonjour"
"""#
}
```
On above example, `_dockerCLI` gets executed first, as the corresponding DAG shows that it is required for the action `foo` to be processed.
This is the `input-output` model: `foo`'s input is `_dockerCLI`'s output.
We currently don't support explicit dependencies at the moment (one of our top priority). But, if you need one, here is how your can hack your way around it:
```cue
foo: bash.#Run & {
input: _dockerCLI.output
always: true
script: contents: #"""
echo "bonjour"
"""#
}
// Main action
bar: bash.#Run & {
input: _dockerCLI.output
always: true
script: contents: #"""
echo "bonjour"
"""#
env: HACK: "\(test.success)" // <== HACK: CHAINING of action happening here
}
```
`foo` and `bar` are similar actions. I don't want to rely on the `input-output` model but still want to force a dependency between them. The easiest way is to create an environment variable that relies on the other action's success