This repository has been archived on 2024-04-08. You can view files and clone it, but cannot push or open issues or pull requests.
dagger/docs/core-concepts/1202-plan.md
Gerhard Lazu da8e8fbaac
Extract snippets from docs into separate files
So that we get auto-formatting and syntax checking in our code editor.
The only snippets which have not been extracted are either terminal
output, or file fragments (e.g. CUE) which are not valid standalone files.

Resolves https://github.com/dagger/dagger/issues/1715

While at it, do a few fly-by improvements:
- beta.1 -> beta.2
- add CUE & BuildKit links
- up -> do

Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
2022-03-10 16:35:50 +00:00

74 lines
2.7 KiB
Markdown

---
slug: /1202/plan
displayed_sidebar: europa
---
# It all starts with a plan
A CI/CD pipeline declared in Dagger starts with a plan, specifically `dagger.#Plan`
This plan is the entrypoint for everything that runs within a pipeline. The simplest plan will usually:
- interact with the client filesystem to read (e.g. source code) or write files (e.g. build output)
- read environment variables
- declare a few actions, e.g. deps, test & build
This is our **Getting Started** example app 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:
```shell
[✔] client.filesystem.".".read 0.0s
[✔] actions.deps 1.1s
[✔] actions.test.script 0.0s
[✔] actions.test 0.0s
[✔] actions.build.run.script 0.0s
[✔] actions.build.run 0.0s
[✔] actions.build.contents 0.0s
[✔] client.filesystem.build.write 0.1s
```
Since these actions have run before, they are cached and take less than 1 second to complete.
While the names used for the actions above - `deps`, `test` & `build` - are short & descriptive,
any other names would have worked. Put differently, action naming does not affect plan execution.
In the example above, the `deps` action is an instance of the docker package build definition.
This is written as `deps: docker.#Build`
Default definition configuration - `docker.#Build` in this case - can be modified via curly brackets, e.g.
```cue
deps: docker.#Build & {
// ...
}
```
We can build complex pipelines efficiently by referencing any definition, from any package in our actions.
This is one of the fundamental concepts that makes Dagger a powerful language for CI/CD.
Before we can use a package in a plan, we need to declare it at the top of the pipeline configuration, like this:
```cue
import (
"universe.dagger.io/docker"
)
```
Since we are using the plan definition from the dagger package - `dagger.#Plan` - we also need to declare it at the top of the pipeline configuration:
```cue
import (
"dagger.io/dagger"
"universe.dagger.io/docker"
)
```
:::tip
Now that we understand the basics of a Dagger plan, we are ready to learn more about how to interact with the client environment.
This will enable us to configure plans just-in-time, save build artefacts, and perform other interactions with the environment within which Dagger runs.
:::