This also updates Getting Started - CI/CD in your local dev - Linux & Mac doc.
A few other related doc changes were pulled in by this.
I wanted to try different versions of dagger on Linux, and this was the
easiest way of doing that:
curl -L https://dl.dagger.io/dagger/install.sh -O
# make this change, and then:
DAGGER_VERSION=0.2.0 sh install.sh
# ...
./bin/dagger version
dagger 0.2.0 (e499297e) linux/amd64
DAGGER_VERSION=0.2.1 sh install.sh
# ...
./bin/dagger version
dagger 0.2.1 (69b4845d) linux/amd64
This change enables anyone to do the following instead:
curl -L https://dl.dagger.io/dagger/install.sh \
| DAGGER_VERSION=0.2.0 sh
Until this gets merged, you can test how this change works in practice
via this temporary file:
curl -L https://dl.dagger.io/dagger/install-pr-1819.sh \
| DAGGER_VERSION=0.2.0 sh
One thing which I was not sure about is how the file from this
repository ends up on https://dl.dagger.io/dagger/install.sh. I think
this is a manual process today, but I need to confirm this assumption.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
We're currently running markdownlint in CI and we didn't have a target
for that in our makefile. Adding that to prevent rejected PR's due to
markdown linting errors
Signed-off-by: Marcos Lilljedahl <marcosnils@gmail.com>
This is a quick fix to attempt to automatically select the user's OS tab
on the pages that requires so which potentially avoids users following
incorrect docs
Signed-off-by: Marcos Lilljedahl <marcosnils@gmail.com>
This duplicates the existing page and uses a new ID so that clicking on
it in one sidebar (pre-Europa) will not update the sidebar. We have
learned about this behaviour via
https://github.com/dagger/dagger/pull/1758
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
The reference to `docker.Copy` does not exist and should be `docker.#Copy` instead. This also leads to a confusing error message (possibly related to #493) as it isn't found while CUE is compiled, and instead results in the following runtime error:
```
[✗] actions.deps 2.1s
9:16PM FTL failed to execute plan: task failed: actions.deps._dag."2"._exec: invalid FS at path "actions.deps._dag.\"2\"._exec.input": FS is not set
```
Signed-off-by: Ben Gesoff <ben@gesoff.uk>
- Temporary page that just points to the GitHub Discussion
- Goal: create a stable link we can share, update with proper content
later
- Wasn't sure how to categorize this so I've renamed `DRAFTS` into
`Knowledge Base`
Signed-off-by: Andrea Luzzardi <aluzzardi@gmail.com>
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>
There are a few outstanding tasks, but they can be finished tomorrow.
This is just the beginning of many refinements, so it's all good 🙌
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
The todoapp example contains a Netlify plan which uses the latest dagger
additions: do & Client API. We are thinking of merging the examples
repository into this one to make working with this easier. This is a
step in that direction.
We are not using the yarn package so that we can revert
https://github.com/dagger/dagger/pull/1673 without breaking this
implementation.
The GitHub Action is WIP, we will continue with that tomorrow:
https://github.com/dagger/dagger-for-github/issues/24
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
We are still figuring out caching, specifically Buildkit go client
caching, while packages is something that users can start creating right away.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
The idea is to start simple and get users a good feel for how this works
within 5 minutes or less. We should cover the three popular OSes, and
ensure that everything works as expected.
At the end of this, users will have Dagger set up for local CI/CD, and
know how to make a change to the example app and re-run the build, test
& deploy loop.
This is part of https://github.com/dagger/dagger/issues/1327
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
The current plan is to add them post 0.2.0 shipping, for now the focus
is on Getting Started & Core Concepts.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
So that it's easy for anyone to jump to the new docs that we are
currently working on, and intend to replace the existing docs with.
While I would have preferred to link to the local dev page, it's still
stuck in the PR state, currently blocked on another PR:
https://github.com/dagger/dagger/pull/1586
Also added a link to the pre-Europa docs, so that it's easy to go back.
While at it, drop "Sidebar" from the name of sidebars, and replace
tutorial with a more descriptive name.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
Left a few TODOs and ideas for next steps. The goal is to get this live,
and enable others to iterate on it via separate PRs.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
There are a few more things to do before we can finish this, see the
comments in the doc. The most important item is to switch the Dagger
config to Europa. That is actually one of the next steps.
Sharing this early so that we start collaborating. Pushing to a branch
in the dagger org so that we can work on it together (personal
repositories make it more difficult).
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
The goal is to capture the shape of the new docs. It is not meant to be
final, but it should be as close as possible. We only want the bare
minimum for new users that on-board with Dagger Europa. As soon as the
new europaSidebar replaces replaces the existing one, the previous docs
will still remain available - doc IDs are unique and permanent. We will
do this by simply changing the default `slug: /` to point to the Europa
Docs entrypoint, which is doc 1200.
Helpful Docusaurus link re multiple sidebars:
https://docusaurus.io/docs/sidebar/multiple-sidebars
The new pages are numbered from `1200` onwards. This is meant to reflect
the `0.2.0` Dagger version. This numbering felt more meaningful than
just continuing to increment existing numbers.
I didn't want to be "wasteful" with the digits and start at `2000`, but
that was my first instinct.
I am keen on getting this live on https://docs.dagger.io/1200/local-ci.
Anything that is not in production, is inventory. Inventory is bad.
The goal is to allow anyone that has a link to get a feel for the new
docs as soon as possible, so that we can all see how they improve in
real-time, and steer them continuously towards the desired state. We
should be aware of the timeline, and not muck about, but instead
evaluate constantly how close are we to "flipping the switch".
Remember, the best releases are those where switches are flipped (e.g.
`--europa)`. The feature will have been out there for weeks (maybe even
months), improved by talking to users and then one day realising that we
are done, and just enabling it by default. It's the same principle
behind these docs.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
- what_is didn't have an id, started with 1000 (it's easier to find this file now)
- operator-manual doc id was clashing with ci use-case
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
The build from source instructions were deprecated since it prints the
available make targets when running `make` whereas, before it built
dagger in dev mode.
Now to build dagger in dev mode, you have to run `make dagger`.
The doc is now up to date with this.
Signed-off-by: Benjamin Reigner <benjamin.reigner@epitech.eu>
Doc's main image is currently heavy.
This PR makes it 5x smaller while keeping equivalent design
Pairs: @gerhard, @slumbering
Signed-off-by: guillaume <guillaume.derouville@gmail.com>
- Refactored to keep every transformation of built-in types (e.g. FS,
Secret, etc) to/from CUE in the same place (plancontext)
- dagger.#Service and dagger.#Secret are now following the new FS-like format
(e.g. `_service: id: string`)
- Backward compatibility
- dagger.#Stream is now an alias for dagger.#Service
Signed-off-by: Andrea Luzzardi <aluzzardi@gmail.com>
- Implement dagger.#FS support
- Migrate `context.imports` to dagger.#FS
- Backward compat: dagger.#FS can be passed in lieu of a
dagger.#Artifact
- For instance, an import (`dagger.#FS`) can be passed to the current
`yarn.#Package` implementation
Signed-off-by: Andrea Luzzardi <aluzzardi@gmail.com>
In the documentation the specified path for the source.cue indicates
it under the cue.mod folder, meanwhile everything is set up outside of
it. Puting the source.cue file in its specified folder resulted in the
example not working, meanwhile puting it in the gcpcloudrun folder
directly resulted in the example perfectly working
Signed-off-by: Benjamin Reigner <benjamin.reigner@epitech.eu>
This adds support to loading artifacts (e.g. docker.#Build,
os.#Container, ...) into any arbitrary docker engine (through a
dagger.#Stream for UNIX sockets or SSH for a remote engine)
Implementation:
- Add op.#SaveImage which serializes an artifact into an arbitrary path
(docker tarball format)
- Add docker.#Load which uses op.#SaveImage to serialize to disk and
executes `docker load` to load it back
Caveats: Because we're doing this in userspace rather than letting
dagger itself load the image, the performance is pretty bad.
The buildkit API is meant for streaming (get a stream of a docker image
pipe it into docker load). Because of userspace, we have to load the
entire docker image into memory, then serialize it in a single WriteFile
LLB operation.
Example:
```cue
package main
import (
"alpha.dagger.io/dagger"
"alpha.dagger.io/docker"
)
source: dagger.#Input & dagger.#Artifact
dockersocket: dagger.#Input & dagger.#Stream
build: docker.#Build & {
"source": source
}
load: docker.#Load & {
source: build
tag: "testimage"
socket: dockersocket
}
```
Signed-off-by: Andrea Luzzardi <aluzzardi@gmail.com>
