docs: docs: guide - default values cue
Add default values cue doc page + implement all maintainers suggestions Signed-off-by: guillaume <guillaume.derouville@gmail.com>
This commit is contained in:
parent
204d067bcc
commit
49de5d022c
@ -1,9 +1,9 @@
|
|||||||
---
|
---
|
||||||
slug: /1229/empty-buildkit-cache
|
slug: /1229/empty-buildkit-cache
|
||||||
displayed_sidebar: europa
|
displayed_sidebar: '0.2'
|
||||||
---
|
---
|
||||||
|
|
||||||
# Empty BuildKit's cache
|
# How to empty BuildKit's cache ?
|
||||||
|
|
||||||
There are two ways of emptying the BuildKit cache:
|
There are two ways of emptying the BuildKit cache:
|
||||||
|
|
||||||
@ -13,7 +13,7 @@ There are two ways of emptying the BuildKit cache:
|
|||||||
dagger do <your-action> --no-cache
|
dagger do <your-action> --no-cache
|
||||||
```
|
```
|
||||||
|
|
||||||
- Stop and remove the buildkitd container and remove its associated volume:
|
- Stop and remove the buildkitd container then remove its associated volume:
|
||||||
|
|
||||||
```console
|
```console
|
||||||
docker stop dagger-buildkitd ; docker rm dagger-buildkitd ; docker volume rm dagger-buildkitd
|
docker stop dagger-buildkitd ; docker rm dagger-buildkitd ; docker volume rm dagger-buildkitd
|
||||||
|
@ -1,19 +1,19 @@
|
|||||||
---
|
---
|
||||||
slug: /1230/better-logs
|
slug: /1230/better-logs
|
||||||
displayed_sidebar: europa
|
displayed_sidebar: '0.2'
|
||||||
---
|
---
|
||||||
|
|
||||||
# Log formats
|
# How can I have better logs ?
|
||||||
|
|
||||||
Dagger exposes 2 logging format options:
|
Dagger exposes 2 logging format options:
|
||||||
|
|
||||||
- `--log-format auto|plain|tty|json`
|
- `--log-format <auto|plain|tty|json>`
|
||||||
|
|
||||||
The default mode is `auto`. If you want to keep each actions' logs, use the `plain` mode
|
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`
|
- `--log-level <panic|fatal|error|warn|info|debug|trace>`
|
||||||
|
|
||||||
`debug` is useful to check whether an explicit dependency has been found between two actions.
|
`debug` is useful to check whether an explicit dependency has been found between two actions and see CUE DAG at run time.
|
||||||
|
|
||||||
You can also export these options as env variables:
|
You can also export these options as env variables:
|
||||||
|
|
||||||
|
@ -1,11 +1,11 @@
|
|||||||
---
|
---
|
||||||
slug: /1231/always-execute
|
slug: /1231/always-execute
|
||||||
displayed_sidebar: europa
|
displayed_sidebar: '0.2'
|
||||||
---
|
---
|
||||||
|
|
||||||
# Always executing an action
|
# How to always execute an action ?
|
||||||
|
|
||||||
Dagger implemented a way to tell Buildkit not to rely on cache for a specific action.
|
Dagger implemented a way invalidate cache for a specific action.
|
||||||
|
|
||||||
The `docker.#Run` and `core.#Exec` definitions have an `always` field:
|
The `docker.#Run` and `core.#Exec` definitions have an `always` field:
|
||||||
|
|
||||||
@ -22,3 +22,7 @@ test: bash.#Run & {
|
|||||||
...
|
...
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
|
:::warning
|
||||||
|
Any dependent actions will also be retriggered
|
||||||
|
:::
|
||||||
|
@ -1,26 +1,23 @@
|
|||||||
---
|
---
|
||||||
slug: /1232/chain-actions
|
slug: /1232/chain-actions
|
||||||
displayed_sidebar: europa
|
displayed_sidebar: '0.2'
|
||||||
---
|
---
|
||||||
|
|
||||||
# Chaining actions
|
# How can I chain actions together ?
|
||||||
|
|
||||||
Dependencies are materialized at runtime, when your Cue files are parsed and the corresponding DAG gets generated:
|
Dependencies are materialized at runtime, when your Cue files are parsed and the corresponding DAG gets generated:
|
||||||
|
|
||||||
```cue
|
```cue
|
||||||
// Prerequisite action that runs when `test` is being called
|
// Prerequisite action that runs when `test` is being called
|
||||||
_dockerCLI: alpine.#Build & {
|
_dockerCLI: alpine.#Build & {
|
||||||
packages: {
|
packages: bash: _
|
||||||
bash: {}
|
|
||||||
}
|
|
||||||
}
|
}
|
||||||
|
|
||||||
// Main action
|
// Main action
|
||||||
foo: bash.#Run & {
|
foo: bash.#Run & {
|
||||||
input: _dockerCLI.output // <== CHAINING of action happening here
|
input: _dockerCLI.output // <== CHAINING of action happening here
|
||||||
always: true
|
|
||||||
script: contents: #"""
|
script: contents: #"""
|
||||||
echo "bonjour"
|
echo "hello"
|
||||||
"""#
|
"""#
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
@ -29,26 +26,24 @@ On above example, `_dockerCLI` gets executed first, as the corresponding DAG sho
|
|||||||
|
|
||||||
This is the `input-output` model: `foo`'s input is `_dockerCLI`'s output.
|
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:
|
We currently do not support explicit dependencies at the moment (one of our top priority). But, if you need one, here is how you can hack your way around it:
|
||||||
|
|
||||||
```cue
|
```cue
|
||||||
foo: bash.#Run & {
|
foo: bash.#Run & {
|
||||||
input: _dockerCLI.output
|
input: _dockerCLI.output
|
||||||
always: true
|
|
||||||
script: contents: #"""
|
script: contents: #"""
|
||||||
echo "bonjour"
|
echo "hello"
|
||||||
"""#
|
"""#
|
||||||
}
|
}
|
||||||
|
|
||||||
// Main action
|
// Main action
|
||||||
bar: bash.#Run & {
|
bar: bash.#Run & {
|
||||||
input: _dockerCLI.output
|
input: _dockerCLI.output
|
||||||
always: true
|
|
||||||
script: contents: #"""
|
script: contents: #"""
|
||||||
echo "bonjour"
|
echo "hello"
|
||||||
"""#
|
"""#
|
||||||
env: HACK: "\(test.success)" // <== HACK: CHAINING of action happening here
|
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
|
`foo` and `bar` are similar actions. If you do not 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
|
||||||
|
54
docs/faq/1233-default-values-cue.md
Normal file
54
docs/faq/1233-default-values-cue.md
Normal file
@ -0,0 +1,54 @@
|
|||||||
|
---
|
||||||
|
slug: /1233/default-values-cue
|
||||||
|
displayed_sidebar: '0.2'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Default values and optional fields
|
||||||
|
|
||||||
|
When writing a Cue config, you will sometimes want to set default values in your package.
|
||||||
|
|
||||||
|
The most common way you'll encounter in our codebase is: `key: type | *value`:
|
||||||
|
|
||||||
|
```cue
|
||||||
|
defaultValue: string | *"foo"
|
||||||
|
defaultValue: bool | *false
|
||||||
|
```
|
||||||
|
|
||||||
|
You'll also encounter the `*null` default value, which is self explanatory:
|
||||||
|
|
||||||
|
```cue
|
||||||
|
// here, defaultValue either accepts a #PersonalDefinition, or stays null by default
|
||||||
|
defaultValue: #PersonalDefinition | *null
|
||||||
|
```
|
||||||
|
|
||||||
|
To test the type of `defaultValue`, you can directly do such assertion:
|
||||||
|
|
||||||
|
```cue
|
||||||
|
if defaultValue != "foo" | if defaultValue != false | if defaultValue != null {
|
||||||
|
...
|
||||||
|
}
|
||||||
|
|
||||||
|
if defaultValue == "foo" | if defaultValue == false | if defaultValue == null {
|
||||||
|
...
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
However, don't get confused with the optional fields. Optional fields check whether a key is concrete at the given scope in the DAG. You declare them with `?` at the end of their name: `foo?`.
|
||||||
|
|
||||||
|
```cue
|
||||||
|
foo?: string // 1. declare foo. It remains undefined for now
|
||||||
|
|
||||||
|
foo: "bar" // 2. Now, `foo` gets concrete. The field isn't undefined anymore
|
||||||
|
```
|
||||||
|
|
||||||
|
To check on a field's concreteness, use the bottom value `_|_`:
|
||||||
|
|
||||||
|
```cue
|
||||||
|
if foo != _|_ { // if foo is not `undefined`
|
||||||
|
...
|
||||||
|
}
|
||||||
|
|
||||||
|
if foo == _|_ { // if foo is `undefined`
|
||||||
|
...
|
||||||
|
}
|
||||||
|
```
|
@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
slug: /faq
|
slug: /faq
|
||||||
displayed_sidebar: europa
|
displayed_sidebar: '0.2'
|
||||||
---
|
---
|
||||||
|
|
||||||
# FAQ
|
# FAQ
|
||||||
@ -13,7 +13,7 @@ export const FaqItems = () => {
|
|||||||
{/* access root category object from Docusaurus */}
|
{/* access root category object from Docusaurus */}
|
||||||
const docsVersion = useDocsVersion();
|
const docsVersion = useDocsVersion();
|
||||||
{/* customProps object retrieved from sidebar.js */}
|
{/* customProps object retrieved from sidebar.js */}
|
||||||
const faqItem = docsVersion.docsSidebars.europa.filter(item => item.label === 'FAQ');
|
const faqItem = docsVersion.docsSidebars['0.2'].filter(item => item.label === 'FAQ');
|
||||||
{/* Return custom FAQ Items array */}
|
{/* Return custom FAQ Items array */}
|
||||||
const customPropsItem = faqItem[0].customProps.items.map(customPropsItem => {
|
const customPropsItem = faqItem[0].customProps.items.map(customPropsItem => {
|
||||||
const result = Object.values(docsVersion.docs).filter(item => item.id === customPropsItem.docId)[0]
|
const result = Object.values(docsVersion.docs).filter(item => item.id === customPropsItem.docId)[0]
|
||||||
|
@ -67,6 +67,7 @@ module.exports = {
|
|||||||
{ docId: "faq/better-logs", href: "1230/better-logs" },
|
{ docId: "faq/better-logs", href: "1230/better-logs" },
|
||||||
{ docId: "faq/always-execute", href: "1231/always-execute" },
|
{ docId: "faq/always-execute", href: "1231/always-execute" },
|
||||||
{ docId: "faq/chain-actions", href: "1232/chain-actions" },
|
{ docId: "faq/chain-actions", href: "1232/chain-actions" },
|
||||||
|
{ docId: "faq/default-values-cue", href: "1233/default-values-cue" },
|
||||||
]
|
]
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
|
Reference in New Issue
Block a user