Probably a bit generic but adding more language "build" support. Today there is bash, go, python and yarn (JS right ?). We could add more things here ruby, java, clojure, rust, …
#github-feed
1 messages · Page 26 of 1
What is the issue?
Dagger paniced again and again when executing my plan.
Log output
7:03PM INF actions.up.getIngressEndPoint.get._exec | computing
7:03PM DBG actions.up.getIngressEndPoint.get._exec | dependency detected dependency=actions.up.getIngressEndPoint._kubectl.dep._dag."0"._op
7:03PM DBG actions.up.getIngressEndPoint.get._exec | dependency detected dependency=actions.up.getIngressEndPoint._kubectl.run._exec
7:03PM DBG actions.up.getIngressEndPoint.get._exec | dep...
@Guikingone tried yesterday to implement the Symfony demo package with dagger 0.2. The result is here, and is still too verbose (due to lack of documentation): thread twitter ici
Here is the actual implementation

There seems to be room for improvement, let's try to help him. What format would you prefer @Guikingo...
You can definitely reduce duplication in linting_ with a template. Would help if this was code I could copy instead of a screenshot though.
linting: {
[string]: docker.#Run & {
input: build.output
command: name: "bin/console"
mounts: _vendorMount
}
yaml: args: ["lint:yaml", "config", "--parse-tags"]
xlif: args: ["lint:xliff", "translations"]
container: args: ["lint:container", "--no-debug"]
}
Hi @helderco, here's the code:
package symfony_demo
import (
"dagger.io/dagger"
"dagger.io/dagger/core"
"universe.dagger.io/docker"
)
dagger.#Plan & {
_vendorMount: "/srv/app/vendor": {
dest: "/srv/app/vendor",
type: "cache",
contents: core.#CacheDir & {
id: "vendor-cache"
}
}
_phpunitMount: "/srv/app/bin/.phpunit": {
dest: "/srv/app/bin/.phpunit",
type: "cache",
contents: core.#CacheDir & {
id: "phpunit-cache"
}
}
client: {...
How's this (not tested)?
package symfony_demo
import (
"dagger.io/dagger"
"universe.dagger.io/docker"
)
dagger.#Plan & {
_vendorMount: vendor: {
dest: "/srv/app/vendor",
type: "cache",
contents: id: "vendor-cache"
}
_phpunitMount: phpunit: {
dest: "/srv/app/bin/.phpunit",
type: "cache",
contents: id: "phpunit-cache"
}
client: {
filesystem: {
"./": read: {
contents: dagger.#FS,
exclude: [
".github",
".editorcon...
Thanks for the code 😇 + on the contrary, your use case is a great way of improving the on-boarding and the docs, thanks for trying Dagger and mentioning us on Twitter 😇
I like the new syntax, here's the updated version:
package symfony_demo
import (
"dagger.io/dagger"
"universe.dagger.io/docker"
)
dagger.#Plan & {
_vendorMount: "/srv/app/vendor": {
dest: "/srv/app/vendor",
type: "cache",
contents: id: "vendor-cache"
}
_phpunitMount: "/srv/app/bin/.phpunit": {
dest: "/srv/app/bin/.phpunit",
type: "cache",
contents: id: "phpunit-cache"
}
client: {
filesystem: {
"./": read: {
contents: dagger.#FS,...
It's just to reduce duplication. See that in the next actions I'm using #Run instead of docker.#Run to reuse the input and _vendorMount.
Oh, that's nice, can we see this as a boilerplate for following steps? Maybe like a contract for each call?
Here's the "prettier" structure:
package symfony_demo
import (
"dagger.io/dagger"
"universe.dagger.io/docker"
)
dagger.#Plan & {
_vendorMount: "/srv/app/vendor": {
dest: "/srv/app/vendor",
type: "cache",
contents: id: "vendor-cache"
}
_phpunitMount: "/srv/app/bin/.phpunit": {
dest: "/srv/app/bin/.phpunit",
type: "cache",
contents: id: "ph...
But that's what I did 🙂
Yes, I know, I mean, now I understand the goal of the directive, that was the question 😅
BTW, a huge thanks to both of you for the support, I can now explore Dragger with a better starting point, I have other questions about the Docker building phase (especially on how to copy executable from external image) but I'll see if I can solve them before asking for help in the discussions 🙂
Again, a huge thank you for the help 😊
Yes, I know, I mean, now I understand the goal of the directive, that was the question 😅
Oh, I see it now 😇
Sure, anytime 🙂
Linked to issue https://github.com/dagger/dagger.io/issues/168
Signed-off-by: jffarge
AZDO support is required for better or for worse.
There's a lot of cloud native pipeline adoption. Personally I'd like to see support for ADO build pipelines.
What is the issue?
When I use dagger.#Writefile and mount it with mount, it says mounts is not set, and does not say that the dagger.#Writefile package does not exist. Finally I realized with the help of @grouville that some packages were migrated from dagger to core.
I think there should be a more friendly alert, such as a direct message that the package does not exist, or a way to automatically link to the core package.
Finally, I think this kind of migration should be a 0.2 to 0...
What are you trying to do?
Get up and running as fast as possible with minimal friction
Expect
git clone https://github.com/dagger/dagger
make mdlint
....
file lint success!
Actual
git clone https://github.com/dagger/dagger
make mdlint
bash: line 1: markdownlint: command not found
make: *** [Makefile:87: mdlint] Error 127
Why is this important to you?
Doing things automatically for a developer lets them get to their innerLoop faster.
Optimise ...
What are you trying to do?
Dogfooding notes/wishlist from #1984
/cc @shykes @helderco @samalba
- I wish I could do
dagger do build lint(a laMakefile) - I wish console outputs were available. It would have been a tremendous help to debug. Also very helpful to inform what just happened (e.g.
dagger do buildshould print the revision we just built). I hacked around by writing a file and then removed that line before committing - I wish the platform defaulted to buildkitd's ...
What is the issue?
When attempting to use an image containing an entry point:
_image: docker.#Pull & {
source: "tmknom/markdownlint:0.31.1"
}
container: docker.#Run & {
input: _image.output
mounts: "source": {
dest: "/src"
contents: source
}
workdir: "/src"
command: {
args: ["./docs"]
}
}
I get actions.lint.markdown.container._exec.args.1: cannot convert non-concrete value string
Removing command works (I get the help m...
Bumps amplitude-js from 8.17.0 to 8.18.0.
Release notes
Sourced from amplitude-js's releases.
v8.18.0
8.18.0 (2022-03-31)
Features
Add versionId to tracking plan data (#518) (26dd38b)
Changelog
Sourced from amplitude-js's changelog.
8.18.0 (2022-03-31)
Features
Add versionId to tracking plan data (#518) (26dd38b)
Commits
eca4003 chore(release): 8.18.0 [skip ci]
26dd38b feat: Add versionId to tracking plan data (#518)
36adf79 d...
What are you trying to do?
I think it's performance critical to do this ASAP. I know we have unfinished discussions regarding the DX for multi-platform and how to override one.
I propose as a stopgap to add a --platform flag to dagger do for overrides -- no CUE syntax.
Background:
When the requested architecture (e.g. linux/amd64 -- which is our default) is different from buildkit's architecture (e.g. linux/aarch64 -- which is the actual architecture of my MacBook), buil...
The following definitions should be moved from dagger.io/dagger to dagger.io/dagger/core:
#ImageConfig(tightly coupled to our image-related core actions)#HealthCheck(same)#Ref(same)#Scratch(tightly coupled to our fs-related core actions)
I just hit the issue while developing a plan. I used core.#Copy and automatically assumed core.#Scratch. This is made worse by #1635 because if a definition doesn't exist (in this case core.#Scratch) it's not clear at...
Especially Jenkins on Kubernetes!
- Split out shell scripts
- (more)
What is the issue?
BuildKit does not seem to be spawning
Log output
$ dagger do build -l debug
10:49PM DBG spawning buildkit job attrs=null localdirs={}
... forever ...
Steps to reproduce
Installed from GitHub.tar.gz
tried to run the examples from universe
Dagger version
0.2.4
OS version
Debian 10 on ChromeOS | amd64
What are you trying to do?
I try to get logs with no colors so it is easy to read dagger logs collected by some CI system.
Why is this important to you?
It is hard to read when ANSI color codes are displayed in a log when coloring is not available.
How are you currently working around this?
no workaround, getting json is not an option as it is totally not human readable
What is the issue?
I run this:
dagger do build --cache-from type=local,src=~/cc --cache-to type=local,mode=max,dest=~/cc
and in current directory new folder was create that was named ~.
dagger should expand ~ to current user home folder path.
Log output
nothing in logs
Steps to reproduce
dagger do build --cache-from type=local,src=~/cc --cache-to type=local,mode=max,dest=~/cc
Dagger version
0.2.4
OS version
ubuntu 21.10
What are you trying to do?
When building with buildkit the default logs show feedback from the individual dockerfile commands during the build process, eg:
[+] Building 12.9s (9/17)
=> [internal] load build definition from Dockerfile 0.0s
=> =...
@gerhard I created a simple dagger pipe for bitbucket pipelines just like dagger-for-github
But ended up with following error
{"level":"error","error":"exit status 125","output":"docker: Error response from daemon: authorization denied by plugin pipelines: --privileged=true is not allowed.\nSee 'docker run --help'.\n","time":"2022-04-03T07:20:49Z","time":"2022-04-03T07:20:49Z","caller":"/home/runner/work/dagger/dagger/util/buildkitd/buildk...
Signed-off-by: Nick Flückiger
This pr converts the src/dest in cache options from home relative paths e.g. ~/path to absolute paths.
Example:
./cmd/dagger/dagger do build --cache-from type=local,src=~/cc
is being interpreted as
./cmd/dagger/dagger do build --cache-from type=local,src=/Users/liberatys/cc (/Users/liberatys being my home-dir)
#2003
What are you trying to do?
There's no binary that I could find on the latest release for 32-bit ARM or Raspberry Pi.
Why is this important to you?
I'm attempting to add dagger support to the arkade marketplace, many people use Raspberry Pis with the default 32-bit ARM OS provided.
How are you currently working around this?
Perhaps it could be built from source. Or is there a technical reason why this isn't supported?
Signed-off-by: Yuvraj
This allows running Dagger in armv7 32 bit architectures.
Fixes 2007
Signed-off-by: Marcos Lilljedahl
Targets to support .NET "publish" and "test" commands on same way like Golang build and test works.
Marked as draft because unit test(s) to verify "test" command is not yet implemented.
This feels like a good sensible default and will keep pipelines clean of many:
source: core.#Source & { path: "." }
What is the issue?
https://twitter.com/alexellisuk/status/1510880710294396928
Log output
No response
Steps to reproduce
Visit https://dagger.io on safari on a mac m1.
Dagger version
should not be required
OS version
should not be required
As much as I'd love to be back on GitHub Actions, Jenkins please!
This hooks into the PRs and their authors.
Signed-off-by: Helder Correia
What is the issue?
I'm trying to push an image to our private registry, but docker.#Push is failing with x509: certificate signed by unknown authority.
I'm running dagger locally on macOS and can confirm that the our private CA cert is indeed present in the system keychain as described here. I am able to manually run docker push $private-registry/$image without issue.
Log output
[✗] action...
For tasks that souldn’t be in the changelog but don’t match the other stuff.
Signed-off-by: Helder Correia
Overview
If there's a change that requires migrations from users, an easy thing we can do right now is to make them clear in the changelog. In Python, I'm used to read the release notes for packages before updating them.
The convention, according to https://www.conventionalcommits.org is to add a ! before the ::
chore!: Move packages to corefeat!: Rename field X
RFCs
- I thought about using
break:instead, but decided to go with the convention above in c...
What is the issue?
I'm trying to build a plan like this
dagger.#Plan & {
actions: {
linux: {
build: docker.#Build & {
....
},
updated: {
build: docker.#Build & {
steps: [
linux.build,
...
},
box: {
build: docker.#Build & {
steps: [
updated.build,
....
}
}
and fails with this error
$ dagger do box build -p image_output.issue.cue
9:00AM FTL failed to lo...
Credit to @gerhard in https://github.com/dagger/dagger/pull/2019#issuecomment-1087466687
Signed-off-by: Helder Correia
The current guide is a bit hidden and we need to rely on links. Users will find it more easily in the source code, which is where I'd search for it anyway.
We are currently using the dagger/.github repo to share the guidelines amongst the organization, but there's also an argument for moving the guide here and reference this one in other places instead. Just not sure about the automatic "Contributing" links that GitHub adds automatically in some places.
Signed-off-by: Helder Correia
...
Would be nice to have it but honestly companies using Bamboo are so dated in tech to decide quickly to move to dagger :(
Fixes #1867
Signed-off-by: Helder Correia
Fixes #1886
Moving the ifs inside the fields avoids some issues.
Signed-off-by: Helder Correia
What is the issue?
If contents is wrongly set to dagger.#FS instead of string when reading a file from the host filesystem, dagger do hangs indefinitely without any error message.
dagger.#Plan & {
client: {
filesystem: {
"./app": read: contents: dagger.#FS
"./manifest": read: contents: dagger.#FS
"./kubeconfig/config": read: contents: dagger.#FS //Should be a string here for example
}
Log out...
Implements part of #1997.
BREAKING CHANGE: Adjust imports for for #Ref, #ImageConfig and #HealthCheck if applicable.
Signed-off-by: Helder Correia
Query Buildkit's daemon and fetch available platform. Additionally try
to match the user's native platform if possible or fallback to
buildkit's outputs
Signed-off-by: Marcos Lilljedahl
Reviewed @radiant rover 🚀 ⚡
The harder part will be dynamic tasks, created by comprehensions, possibly based on the output of previous tasks. These cannot be known by simply reading the input CUE.
@verdverm Totally agree here. I don't know that there is any straightforward way to get dynamic tasks. It might possible with a walking of the cue values, but I don't think the reference (and thus dependency) information would be easy to get at.
Bumps github.com/docker/buildx from 0.8.1 to 0.8.2.
Release notes
Sourced from github.com/docker/buildx's releases.
v0.8.2
Notable changes
Update Compose spec used by buildx bake to v1.2.1 to fix parsing ports definition #1033
Fix possible crash on handling progress streams from BuildKit v0.10 #1042
Fix parsing groups in buildx bake when already loaded by a parent group #1021
Commits
6224def Merge pull request #1042 from tonistiigi/update-buildkit-2...
Bumps sass from 1.49.10 to 1.49.11.
Release notes
Sourced from sass's releases.
Dart Sass 1.49.11
To install Sass 1.49.11, download one of the packages below and add it to your PATH, or see the Sass website for full installation instructions.
Changes
Add support for 64-bit ARM releases on Linux.
Embedded Sass
The embedded compiler now correctly sets the id field for all OutboundMessages.
See the full changelog for changes in earlier releases.
Ch...
Bumps concurrently from 7.0.0 to 7.1.0.
Release notes
Sourced from concurrently's releases.
v7.1.0
Excluding pattern support added, e.g. concurrently npm:lint:*(!fix) (#305, #306)
Fixed programmatic API docs to resemble v7.0.0 changes (#303)
New Contributors
@naxoc made their first contribution in open-cli-tools/concurrently#303
@NullVoxPopuli made their first contribution in open-cli-tools/concurrently#306
Commits
1762f88 7.1.0
49...
Had to recreate #1902 because of private -> public transition
Signed-off-by: Joel Longtine
What are you trying to do?
As a Dagger user, I want to be able to use private keys from the SSH agent to clone private dependencies in order to avoid configuring a username and password or explicit private key
Why is this important to you?
This is important in order to publish and maintain privately accessible Dagger modules
How are you currently working around this?
Manually cloning repository contents
:warning: WIP
Add documentation on export cache, it still requires improvement and work before merge but local cache is complete
Fixes #2034
It's functional. However I had to hardcode the SSH_AUTH_SOCK path, which is not going to work.
Any idea @helderco?
What are you trying to do?
Type a simple command that gives me basic information about my Dagger project
- Its location on the filesystem
- Location and status of available plans (do they load ok?)
Why is this important to you?
No response
How are you currently working around this?
No response
ci: Move ci dagger commands to top level of repo, update CI to use them, remove corresponding commands from makefile
Signed-off-by: Kenneth Lear
#1522
Makefilenow usesdagger do lintto lint- GHA uses dagger to lint
What is the issue?
CUE has a powerful concept called "embedding", similar to Go embedding. This pattern is used extensively in Universe. It makes sense once you're familiar with CUE, but for absolute beginners it can be quite confusing.
There should be a documentation section explaining this concept.
Update some API references that had fallen out of use.
Notably this no longer ran, since docker.#Run now asks for an "input" not an "image," alpine.#Image became alpine.#Build and you have to reference its output. Additionally, fix up the FIXME tag in the simplest way possible, though a better solution may exist.
What is the issue?
dagger do doesn't return useful info from stderr.
When I change the logging format to --logformat plain I get the info I need.
Log output
➜ service-foo git:(master) ✗ dagger do typescript
[✔] client.env 0.0s
[✔] client.filesystem."./".read ...
In the installer instruction for Windows it is claimed that the dagger binary is placed inside the System32 folder if permissions allow it, which seems to be no longer part of the install.ps1 script (and seems like a bad idea anyways).
Resolves: #2042
Signed-off-by: Vasek - Tom C
Signed-off-by: Andrea Luzzardi
This has not been used in months, all releases run through auto-release.yml now.
Follow-up to https://github.com/dagger/dagger/pull/2048
Need some more time to figure out the correct API.
Signed-off-by: Andrea Luzzardi
Add an --experimental-platform flag to the do command to allow
overriding the default auto-detected build platform until we find the
time to think about the definitive multi-platform builds UX
Signed-off-by: Marcos Lilljedahl
Hello developers! Now that we have launched, we are turning our attention to incremental improvement. There are many bugs to fix, features to implement, and documentation to write. We want to prioritize this work based on your feedback.
Based on your experience using Dagger so far, what should we work on next? How can we make Dagger the best possible tool, and why?
- Please reply below with your most pressing requests
- If you have multiple requests, please split them into separate a...
VSCode extension
I'd like a proper integration with the Language Server Protocol and a nice VSCode extension that comes with it. It's important for CUE and libraries added by Dagger. I spend too much time reading through the library code base to know what I can use, ideally VSCode could auto-complete everything nicely.
Cryptic error messages
The biggest pain I have experienced was lack of clarity in error messages. In particular:
-
When I reference the wrong definition in a package (for example
git.#Cloneinstead ofgit.#Pull), it doesn't cause a CUE error. Instead, my action runs and I get a very confusing "FS is not set" error. -
When I run a container, and the command in that container fails, I don't get any details, just "execution of command failed". I have to re-run with `--log-format...
Console Outputs
I'd like to be able to define console outputs in a #Plan: https://github.com/dagger/dagger/issues/1351
This is very helpful for developing/debugging a plan, and as a plan user, to get some feedback on what happened (e.g. URL).
Furthermore, I'd like to be able to chose the output format (e.g. console, json, ...). This would allow to programmatically extract information (for instance, bats tests could extract a field, e.g.)
Also, once outputs can be extracted p...
Being able to support Windows and Linux builds is vital to my needs.
I want this too, but not sure about the output formats. I didn't get a response on https://github.com/dagger/dagger/pull/1486#issuecomment-1047105707. We'd need to disable logging to have a clean output that can be consumed programatically.
HowTo: Write a Plan
It all starts with a plan, so it makes sense that you would want to understand how to write your own plans. Currently it's not entirely clear how a developer could become skilled at writing one.
Console UI
The console experience (e.g. status of dagger do) is not great. Oftentimes, we have to resort to --log-format plain --log-level debug because the default suppresses important information. In no particular order:
- TTY rendering is buggy (e.g. flashing/broken lines)
- Some errors are suppressed when run fails (e.g. container logs)
- It's not clear what's going on, the list of actions is confusing. Currently the CUE path of all "actions" is displayed. I think there are...
Explicit Dependencies
Currently, it's not possible to define explicit dependencies without resorting to hacks.
actions: build: yarn.#Run & { ... }
actions: test: yarn.#Run & { ... } // How can `test` depend on `build`?
Related issues: #940 #1248
Persistent caching on CI
There's 2 caching systems in buildkit:
- Layer caching: Avoid running the same operation if it was already completed with the same inputs
- Cache directories (e.g.
core.#CacheDir): Mount a directory with the same contents (e.g. fornode_modulesetc)
Currently, both are tied to the local machine. Layer caching can be used on a CI environment using --cache-to (supports registry, GitHub caching, etc). However, core.#CacheDir doesn't work on CIs which...
Intellij plugin
(similarly to VSCode extension above)
There is an existing plugin here that provides cue support: https://github.com/monogon-dev/intellij-cue but unfortunately does not seem to be updated. Could be used as a base though?
Ability to build & push multi-arch images
This is a subset of: https://github.com/dagger/dagger/issues/1371 - which does cover the broader topic of multi-architecture (<- all of it is desirable, but this suggestion here is specifically about building / pushing).
Skeleton Generation
In order to receive a faster onboarding when starting fresh with Dagger. It would be really nice when dagger project init generates a project.cue file with some basic dagger plan.
In future it could extended to do auto discovery of the project and generate a better project cue file for the project type.
What are you trying to do?
I have problem with access github and some domain with my network, when I do some plans it required that resource, It got network error.
Why is this important to you?
No response
How are you currently working around this?
set global proxy for my PC.
Dagger TDD/BDD as first class concept
We can create a Dagger definition and a plan to test that new definition using bash/bats, like dagger team does in universe package.
I would like Dagger introduce tdd/bdd using cue syntax
dagger.#Spec & { // Like Dagger plan
"removeSNames": dagger.#Describe & {
"should remove all S names": dagger.#It & {
// verify definition
}
"should not remove other names": dagger.#It & {
// verify d...
What is the issue?
when tried to do example app command: dagger do build, it reported below errors
Log output
No response
Steps to reproduce
No response
Dagger version
dagger 0.2.5 (7d2f279c) linux/amd64
OS version
CentOS Linux release 7.2 (Final)
This feels like it should work, but when it runs it fails and I can't work out how to get further debugging information.
9:53AM DBG actions.rawkode.apply._exec | #6 Exec ["kubectl", "apply", "--kubeconfig", "/kubeconfig", "-f", "/work"]
9:53AM DBG actions.rawkode.apply._exec | #6 sha256:c676aabdc1af55ae8852a03a5a7e25a92009e466a0ae932db97e4ce140e19827
9:53AM ERR actions.rawkode.apply._exec | failed: process "kubectl apply --kubeconfig /kubeconfig -f /work" did not complete successful...
RE: output formats, I've always been a fan of programs writing user-facing information to stderr and leave stdout for programmatic access. My solution to the logger vs output problem would then be that the TTY logs to stderr, not stdout. That sounds like a huge breaking change though so I'm not sure how much political will there is to make it.
RE: output formats, I've always been a fan of programs writing user-facing information to stderr and leave stdout for programmatic access. My solution to the logger vs output problem would then be that the TTY logs to stderr, not stdout. That sounds like a huge breaking change though so I'm not sure how much political will there is to make it.
Not a breaking change, the logger is already outputting to stderr.
The issue is that when you output to stdout for this feature, it's messy wit...
Declaratively Trust CA Certificates
- As a developer, I'd love it if I could declaratively tell dagger/buildkit that I want to trust my organization's private CA cert, so that, for example, actions like
docker.#Pullanddocker.#Pushwork with our internal registry.- Currently, a buildkit instance must be created manually with the private CA cert(s) mounted into it.
- E.g. `docker run --net=host -d --restart always -v $PWD/my-cert.pem:/etc/ssl/certs/my-cert.pem --name da...
- Currently, a buildkit instance must be created manually with the private CA cert(s) mounted into it.
Agreed, and we should do one for Jetbrains IDE too, as a Jetbrains's user that would be painful to switch to VSCode to get an autocompletion.
As well, I think it's not only about autocompletion, it should be possible to jump to a definition in a single click, view documentation on hover, see fields's type, get an error when a field has wrong type etc...
Totally agree with you!
When I run a container, and the command in that container fails, I don't get any details, just "execution of command failed". I have to re-run with --log-format plain to see the stderr of the command.
Related to #2044
What do you mean by "builds"? It's currently possible to run dagger on Windows and Linux.
Do not hesitate to open an issue to explain your problem 😄
I created a simple build action with go.#Build and cache was correctly exported/imported.
I wrote a piece of documentation about it (see #2035)
I mean running Windows containers from Linux or Windows, not running Linux containers from Windows or Linux.
I think jetbrains is working on an IDE that is compatible with LSP, so then you could have all the goodies from that.
And for me LSP would give me that for vim as well as we have a few plugins for that already. But yes, exploring code, jumping to definitions would be super useful to explore the dagger CUE codebase. As beginner, it is very important.
Yeah there's a common miscommunication between "running Windows containers" vs "running containers in Windows". 😁
Is it possible to run Windows containers from Linux?
Is it possible to run Windows containers from Linux?
I don't believe so. Containers inside Linux hosts only rely on namespaces and cgroups.
OTOH containers inside Windows hosts rely on a thin virtualization layer, and that is why they can run both Windows and Linux containers.
Agreed. And cookbooks are usually of great help.
And not only complex ones, but simple examples help as well.
One of my favourite documents references is from Ansible. They layout each functionality, explain the options into an easy-to-read table and then wrap it up with several examples.
Here is the documentation for the copy modules for reference:
https://docs.ansible.com/ansible/2.4/copy_module.html
Yeah, you can trigger the starting of Windows containers from Linux by sending the request to a remote Docker daemon running Windows containers, which is really the sort of model we would expect to see supported, but BuildKit does not yet support that.
What are you trying to do?
Once a CUE action fails, we can't know which CUE node fail specifically.
For example, if I run the following CUE code:
up: bash.#Run & {
script: contents: #"""
some_problem_here
"""#
}
I could tell the up command fail from the logs from dagger do up --log-format plain.
But dagger as the engine should know that up node failed, and can get the stdout/stderr from bash.#Run. It would be great if dagger can expose these thre...
What are you trying to do?
Expose my buildkit daemon container through TCP or SSH without expose my docker daemon.
Why is this important to you?
I want to start a buildkitd container for each user so they can use my machine to execute their dagger plan.
After they executing their dagger plan, I will delete that particular container.
At the same time, I can't share my docker daemon with them because I don't want them to start containers other than buildkitd on my machine.
By the ...
What is the issue?
@jpluscplusm reported that he had a log deduplication issue on his Dagger Plan, both locally and on GHA.
After checking it, It's the exact same behavior as #449, but no #Push operation is involved in the process 🤔 I personally didn't believe this was possible.
Making it an issue so that we don't lose track of that.
Log output
Downloading https://dl.dagger.io/dagger/releases/0.2.4/dagger_v0.2.4_linux_amd64.tar.gz
Extracting Dagger
/usr/bin/tar xz --...
In the same realm, ability to also pass a client TLS certificate (to push and pull - per registry, just like credentials).
Print the DAG
Being able to print the DAG, wether it is through an ASCII code or a web UI
Totally agree with this one ⬆️
Yeah @TomChv; my team are heavy JetBrains users, and we would want to have the full experience with styling, syntax analysis, refactoring, documentation &etc. as you mentioned. Without that, we'd feel like we were going back 10 years.
Document better actions inputs / outputs
Sometimes I find myself jumping between a task definition [1] and it's corresponding source code [2] to understand what some actions are doing in regards to inputs and outputs. The API docs [3] also don't mention this information.
It'd be nice to have a page a la terraform registry [4] with more structured information about the actions and their corresponding inputs / output values
[1]: https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagg...
buildkit caching is not additive, e.g., it can only import/export cache off a single dagger do.
In our own CI, it means that each PR is overwriting the cache with that PR's content. Which in turn means each PR is invaliding each other's cache. Example:
PR 1has some go changes. Cache is built using that source code and exportedPR 2has different go changes. Cache is re-built using that source code, overwritingPR 1cachePR 1has an update. It will load cache from `PR...
Publish Images in ECR
Currently docker.#Push only accept username & secret, it only work for Registry like dockerhub & GHCR, Currently it is not possible to publish them in ECR. It would be great if we get more broader support for registry
@shykes Described on discord that it is possible and this functionality exist in v1.0.0, Just need to port in v2.
Dagger Hub
Currently for learning about any package, I need dagger code base. It would be great if there is dagger hub equivalent to docker hub.
That will provide me package definition and example
Are we entirely sure it doesn't work with ECR? According to the AWS docs (https://docs.aws.amazon.com/AmazonECR/latest/userguide/getting-started-cli.html#cli-authenticate-registry) using username AWS and password the token obtained from the get-login-password it should be possible to push an image to ECR
Bumps amplitude-js from 8.18.0 to 8.18.1.
Release notes
Sourced from amplitude-js's releases.
v8.18.1
8.18.1 (2022-04-06)
Bug Fixes
update analytics-connector to 1.4.1 (#520) (956d53b)
Changelog
Sourced from amplitude-js's changelog.
8.18.1 (2022-04-06)
Bug Fixes
update analytics-connector to 1.4.1 (#520) (956d53b)
Commits
d6df263 chore(release): 8.18.1 [skip ci]
956d53b fix: update analytics-connector to 1.4.1 (#520)
See full...
Proxied for user @Lutin on Dagger Discord:
We already have a decent amount of infrastructure built on top of Buildkite pipelines.
Need for UI, task history, visualizations of DAG, etc. is pretty high up on the list when comparing different ways to do things. Yes we can use Dagger with Buildkite, but parsing out the DAG that it runs from log lines is a bit painful and a worse UX, and often parts of that DAG are running under different service accounts with different permissions in dif...
Right. The part that is missing is calling get-login-password automatically in an action. Right now you have to call it yourself on the client machine.
What are you trying to do?
We have the circumstance where a build could engage a large amount of expensive steps to all be engaged in order to assemble the pieces necessary to create a final build artifact. A number of these steps are large enough that even a well equipped machine might have a hard time coping with it.
My intent is to be able to schedule some/all actions as separate Pods scheduled on a K8s cluster. We could define their resource constraints so that K8s would be able t...
I have a semi-complete simple implementation for azure devops at https://github.com/joachim-isaksson/dagger-for-azure-devops
It's based on the existing github actions implementation. Sadly I don't have the time to finish for the next few days, so if someone is so inclined, feel free to take it over :)
The task runs, dagger downloads and installs, runs correctly and the task fails in cleanup (a recursive delete that won't)
Right. The part that is missing is calling get-login-password automatically in an action. Right now you have to call it yourself on the client machine.
Got it, so what would be the right level of composability here?
- An
aws.#ECRPullthat automatically pulls the image and wraps thecore.#Pullone? - An
aws#ECRLoginaction that returns the password as a dagger secret which the user can later use in a standardcore.#Pull?
What's the criteria to have in mind when creating n...
Got it, so what would be the right level of composability here?
- An
aws.#ECRPullthat automatically pulls the image and wraps thecore.#Pullone?- An
aws#ECRLoginaction that returns the password as a dagger secret which the user can later use in a standardcore.#Pull?
In 0.1 we did the latter, and it worked well. Here's the code for ECR for example. We also had Google GCR I believe.
feat: Adding project info command to find where project is located
Implement part of #2038. Only question is testing this change. I attempted to add basic test but nothing concrete. Any ideas to better test this are appreciated. Also I wouldn't mind adding a 'Test' section to the contributing page to let other users understand this better as well with it looking like a non-standard golang testing structure.
Overview
As an end-user, if an action has an incomplete field of type dagger.#FS, I want to be able to set it from the command-line, for example:
actions: build: {
source: dagger.#FS
...
}
dagger do build --source ./src
re: tty logger.
It's possible to stop it (tty.Stop()), so I guess we could finish the Do(), stop the tty logger, then Printf the console outputs
Once stopped the tty logger won't refresh the screen anymore.
Pseudo-code:
// Use tty logger for Do
tty.Start()
err = cl.Do(ctx, p.Context(), func(ctx context.Context, s *solver.Solver) error {
return p.Do(ctx, target, s)
})
tty.Stop()
// Optional: Reset the context logger to be non-tty
lg = logger.New() // re-create...
Signed-off-by: vgjm
To avoid broken url, the next step is to use docusaurus plugin client redirects
redirects: [
// /docs/oldDoc -> /docs/newDoc
{
to: '/0.1/1002/vs',
from: '/1002/vs',
},
],
cc @gerhard @dolanor
Signed-off-by: jffarge
I agree. We are making a first step in that direction thanks to #2033 , which relies on auto-detecting which fields in an action are inputs.
What is the issue?
We need an example of how to run dagger within a Jenkins pipeline. Will use a jenkinsfile approach.
What is the issue?
There should be a banner at the top of every Dagger 0.1 documentation page saying "This page is for Dagger 0.1 and is now outdated, for up-to-date documentation, see ".
Cool, how are we detecting which is an input and which is an output? Can we use that logic to generate reference documentation?
Bumps go.opentelemetry.io/otel/trace from 1.6.1 to 1.6.2.
Release notes
Sourced from go.opentelemetry.io/otel/trace's releases.
Release v1.6.2
1.6.2 - 2022-04-06
Changed
Don't panic anymore when setting a global TracerProvider or TextMapPropagator to itself. (#2749)
Upgrade go.opentelemetry.io/proto/otlp in go.opentelemetry.io/otel/exporters/otlp/otlptrace from v0.12.1 to v0.15.0.
This replaces the use of the now deprecated Instrumentat...
Bumps github.com/moby/buildkit from 0.10.0 to 0.10.1.
Commits
5bc9c7b Merge pull request #2790 from tonistiigi/k8s-examples-update-v0.10
58b5892 examples/kubernetes: replace deprecated seccomp annotations with securityContext
939c71d Merge pull request #2780 from tonistiigi/cherry-picks-v0.10.1
42f892f vendor: update containerd and continuity
6ee29df vendor: github.com/containerd/containerd v1.6.2
6221947 Dockerfile: update containerd to v1.6.2, v1.5.11
9...
Bumps go.opentelemetry.io/otel/exporters/jaeger from 1.6.1 to 1.6.2.
Release notes
Sourced from go.opentelemetry.io/otel/exporters/jaeger's releases.
Release v1.6.2
1.6.2 - 2022-04-06
Changed
Don't panic anymore when setting a global TracerProvider or TextMapPropagator to itself. (#2749)
Upgrade go.opentelemetry.io/proto/otlp in go.opentelemetry.io/otel/exporters/otlp/otlptrace from v0.12.1 to v0.15.0.
This replaces the use of the now d...
Bumps go.opentelemetry.io/otel/sdk from 1.6.1 to 1.6.2.
Release notes
Sourced from go.opentelemetry.io/otel/sdk's releases.
Release v1.6.2
1.6.2 - 2022-04-06
Changed
Don't panic anymore when setting a global TracerProvider or TextMapPropagator to itself. (#2749)
Upgrade go.opentelemetry.io/proto/otlp in go.opentelemetry.io/otel/exporters/otlp/otlptrace from v0.12.1 to v0.15.0.
This replaces the use of the now deprecated InstrumentationL...
Bumps sass from 1.49.11 to 1.50.0.
Release notes
Sourced from sass's releases.
Dart Sass 1.50.0
To install Sass 1.50.0, download one of the packages below and add it to your PATH, or see the Sass website for full installation instructions.
Changes
@extend now treats :where() the same as :is().
Command Line Interface
Closing the standard input stream will now cause the --watch command to stop running.
Embedded Sass
Fix a bug where the JS embedded ...
Before this change, if BUILDKIT_HOST was set to an invalid value that
resulted in the connection of the grpc client to the server to fail,
then deadlock occured waiting for the eventsCh to be closed.
This happened because the call to the buildkit client's Build method
returned an error before the provided callback was executed, which is
where the eventsCh gets closed.
This change places the creation of eventsCh inside the Build callback,
which avoids the increment of the Wait...
Improve Package Management
Non exhaustive list of requirements, in random order:
- Do not require to commit vendored packages in
git(e.g. commit onlydagger.modanddagger.sum, just like go) - Treat
dagger.io/daggeranduniverse.dagger.ioas external packages- Fetch them from
gitrather than embedding in the binary - Figure out version management
- Fetch them from
- Support "tidy"'ing, i.e. remove stuff in cue.mod/pkg that's not being used
- Support
replacedirectives like ...
I think some of these we can do now. For others, better to way for CUE's package management (e.g., support vanity URLs). It's a big issue, with some controversial ideas (like reusing some of Go's "infrastructure").
What is the issue?
Error messages start with the word "FTL", for example:
5:15AM FTL failed to execute plan: task failed: actions.lint.markdown._exec: process "/home/nonroot/entrypoint.sh markdownlint ./docs README.md" did not complete successfully: exit code: 1
Several people have asked me "what does FTL mean"? The answer is "fatal error". But clearly that is not at all obvious.
Log output
Steps to reproduce
Run dagger do of an action that fails. Look at ...
Dogfooding notes/wishlist from #1984
/cc @shykes @helderco @samalba
- I wish I could do
dagger do build lint(a laMakefile) - I wish console outputs were available. It would have been a tremendous help to debug. Also very helpful to inform what just happened (e.g.
dagger do buildshould print the revision we just built). I hacked around by writing a file and then removed that line before committing - I wish the platform defaulted to buildkitd's platform. The performance is hor...
Great stuff 🙂
Dogfooding notes/wishlist @shykes @helderco @samalba:
- I wish I could do
dagger do build lint(a laMakefile)
Me too! And it makes it more portable. (windows anyone?)
- I wish console outputs were available. It would have been a tremendous help to debug. Also very helpful to inform what just happened (e.g.
dagger do buildshould print the revision we just built). I hacked arou...
I wish the platform defaulted to buildkitd's platform. The performance is horrible in any other setting. I know we had long discussions around the API for this, but it's so important my recommendation would be to default to buildkitd and provide a --platform flag (so we don't need to define the whole CUE DX before making this change)
Not aware of this. Want to know more.
Opened a separate issue #1996 with more details
Console outputs (or another hermetic-seal-breaking-but-not-really equivalent): very hard agree!
I'm trying to debug a universe/aws.cli run that's working locally but failing in GHA, and I'm almost out of ideas for how to surface the underlying AWS response error.
As a slight extra ask in the console output space: it'd be great to have a way to unconditionally print some output from a step, regardless of if the DAG failed at that step. My current strategy breaks (I think!) because the `c...
Console outputs (or another hermetic-seal-breaking-but-not-really equivalent): very hard agree!
Context:
- Converting this line from our Makefile resulted in 40 lines of CUE:
go build -ldflags '-s -w -X go.dagger.io/dagger/version.Revision=$(git rev-parse --short HEAD). Mostly because of the point above
You could also use the local host:
client: commands: gitVersion: {
name: "git"
args: ["rev-parse", "--short", "HEAD"]
}
actions: {
build: go.#Build & {
ldflags: "-s -w -X go.dagger.io/dagger/version.Revision=\(client.commands.gitVersion.stdout)"
}
}
But t...
This project seems promising, but regarding https://docs.dagger.io/1201/ci-environment and CI pipelines
With multiple stages and jobs, wouldn't you always have to execute each dagger action independently to be able to use parallelism and autoscaling of pipeline agents/workers? So in fact you are always tied to writing a pipeline file (for those platforms that support Pipelines as Code) and call dagger actions from that?
You will need to write a pipeline file specific to the CI environment in order to run dagger do <action> commands. Dagger uses BuildKit to run these actions. By default, BuildKit gets created as a container in the local Docker instance. If you try running this locally, you will see the dagger-buildkitd container running. All actions will be represented as a DAG, and many will be cached. Subsequent runs will be faster.
Now imagine that you have a cluster of BuildKit instances, perhaps r...
Currently the dagger Github Action can install dagger binary:
- name: Install Dagger
uses: dagger/dagger-action@v1
with:
install-only: true
But running dagger up in Action will fail for any buildkit operations. For example:
patchGrafana: {=
#up: [
op.#Load & {
from: kubernetes.#Kubectl & {
version: "v1.23.3"
}
},
...
op.#Exec & {
always: true
args: [
"/bin/bash",
"--noprofile",
"--no...
Hi @hongchaodeng,
Does this config work locally ? Can you please show us what is inside the /entrypoint.sh ?
Dagger always stops when a command has a return code != 0 (we have issues working on some fixes)
Here is a working example.
Some things to consider:
You need to set your SOPS key as a Github secret, for the action to be able to decrypt your dagger.#Secret.
That's what I do in the below code: secrets.DAGGER_AGE_KEY. This key lies inside the ~/.config/dagger/keys.txt file.
You also need to pass an arg: which dagger command do you want to run ?
name: CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
deploy:
runs-on...
Hi @grouville
Yes It works locally.
Here's the full code sample: https://github.com/hongchaodeng/ai-demo/blob/1ef4b706292b742c1b47471ca1a2d0b079b72bf0/plans/ai-demo/monitoring.cue#L10
That's what I do in the below code: secrets.DAGGER_AGE_KEY.
I saw it in the tutorials. But I can't really understand what it means. Instead I used plain dagger input xxx:
https://github.com/hongchaodeng/ai-demo/blob/264043e5136af6843c5ba5d0247f675301265add/.github/workflows/workflow.yml#L23
I sent you a PM on Discord, could we book a 1:1, I think it's going to be easier to debug 😇
I added you as a collaborator on a simple private repro case, showing you in 2 branches how you can change your workflow to make it simpler.
However, my repro shows that what you do works. Your issue seems to be related to https://github.com/hongchaodeng/ai-demo/runs/5152739855?check_suite_focus=true#step:5:67.
What you can do as a next step is to change your workflow to run dagger up --log-format plain -l debug instead of dagger up in order to have more logs in the CI.
As I told...
When deploying A and B, if A succeeds then B fails the rollout is left as is. This can result in a broken deployment since we now have a new version of A with an old version of B.
Ideally, if a version N of a plan fails, dagger should be re-apply N-1 to bring back A and B to the same version.
/cc @samalba
cc @gvidon as it was his request during the last demo.
Sometimes my configuration fetches a git or docker repository without specifying a digest, and I want to add the current digest to avoid unexpected changes in the future. But how do I find out the current digest? Dagger does not provide a command to do this. I have to search for specialized tooling and learn how to use it, just to get that ref.
Since git and docker refs and digests are important concepts in Dagger, it makes sense for the dagger command to make it easy to manage digests.
Related to #338, I suggested to have op: "fetch-container" to output /dagger/commit or similar, that provides the ability to export it as needed. Similar mechanism than "push-container". It's actually implementable without changing the current spec.
Having spent a significant amount of my last six weeks on https://github.com/dagger/dagger/issues/1327, I thought that it would help to share my learnings, current state and the steps that I see us taking next.
While this is the continuity that I imagine, now is a good time to share your perspectives and drive the improvements that you would like to see in https://docs.dagger.io as we open up Dagger to the world.
Learnings worth sharing
It served me well to have a clear user in mi...
I am CC-ing @samalba since we were talking about this yesterday.
Maybe we could have a common pitfalls page. Examples would be recommending disjunctions over if conditions and templates over for loops. We can leave in draft and add to it until it's mature enough to publish.
Also, sometimes I feel docs are too basic and need more examples (in general). Maybe a section for more in-depth or advanced concepts? React has a Main Concepts section and an Advanced Guides and I've found those helpful. Y...
All excellent ideas @helderco!
This is the https://docs.dagger.io that I imagine us all working towards over the coming weeks:
DOCS STRUCTURE TODAY DOCS STRUCTURE TOMORROW
-------------------- -----------------------
⬅️ Dagger 0.1 ⬅️ Dagger 0.1
Migrate from Dagger 0.1 Migrate from Dagger 0.1
Getting Started Getting Started
|- CI/CD in your local dev ...
What about Manage packages using the package manager? It's the next logical step to Create your own package (Develop a new CUE package for Dagger).
I'll write both.
Note: Using the package manager can be used standalone if you're reusing packages from others, but there's no sense in creating a package for yourself without using the package manager ...
@talentedmrjones I think that it will help to have the above context for when we talk docs next 🙂
Dagger Upgrade
dagger upgrade
What is the issue?
Received from docs feedback form:
“FYI link to "To learn more about the structure of a plan, see it all begins with a plan" is broken”
Is this intended to upgrade the dagger binary itself?
@Alvise88, If I recall, you had some configs pre-europa. Do you need help migrating ?
What is the issue?
Part of our CI pipeline is executing code in a private AWS VPC, how can this be done?
What are you trying to do?
There is a lost of users who can't run hello world example or any other example in the docs because they forgot to tip dagger project update.
It is not explicitly explained in the doc and there is no tip in the CLI.
What would be awesome is that you have a small message after dagger project init to remember you to tip dagger project update to install dagger dependencies.
Example
$ dagger project init
Project initialised! To install ...
Hi,
In https://docs.dagger.io/1221/action the link to it all begins with a plan is broken and goes to https://docs.dagger.io/1221/1202-plan.
I am interested in porting the serverless package.
Thanks @munichbughunter. For reference purposes, as we discussed privately, you're talking about this package: https://github.com/grouville/dagger-serverless, in which we tried to do an aws SAM like in Dagger. That would be an awesome contribution
What is the issue?
speaking this is not a bug strictly, maybe can change a kind/enhancement tag
Log output
no need
Steps to reproduce
In official example todoapp, run dapper do build, The following two runners will be called:
- client.filesystem."./".read
- actions.deploy.container.script._load
the first PreRun is excepted, but second in deploy stage, maybe can optimization by some logical judgments.
Dagger version
dagger devel (def93a29) linux/arm64
#...
Adds the ability to select a template which will create a new file
in the CWD with the template name. Templates present in the
"cmd/dagger/project/templates" directory are automatically embedded in the dagger
binary when building and then listed in the dagger project init help output.
Usage:
dagger project init -t
One idea that we had while pairing on this is to eventually try
improving this UX by extending the dagger project command by adding
sub-commands like `dagger project tem...
This is just to start. We’ll keep iterating on it.
Resolves #1360
Signed-off-by: Helder Correia
Hey, Team let me know if i can help in something, New bee but interested in learning cue 😂
Been using GoCD with Buildah rootless builds for a while, GoCD would be a cool addition!
This commit adds a Tekton example which builds and deploys the todoapp
to Netlify.

- pre-requisite
- Tekton installed
$ tkn version Client version: 0.17.0 Pipeline version: v0.33.2- Tekton git-clone task installed
$ kubectl apply -f https://raw.githubusercontent.com/tektoncd/catalog/main/task/git-clone/0.5/git-...
Bumps go.opentelemetry.io/otel/sdk from 1.6.2 to 1.6.3.
Release notes
Sourced from go.opentelemetry.io/otel/sdk's releases.
Release v1.6.3
Fixed
Allow non-comparable global MeterProvider, TracerProvider, and TextMapPropagator types to be set. (#2772, #2773)
Changelog
Sourced from go.opentelemetry.io/otel/sdk's changelog.
[1.6.3] - 2022-04-07
Fixed
Allow non-comparable global MeterProvider, TracerProvider, and TextMapPropagator typ...
Bumps go.opentelemetry.io/otel from 1.6.2 to 1.6.3.
Release notes
Sourced from go.opentelemetry.io/otel's releases.
Release v1.6.3
Fixed
Allow non-comparable global MeterProvider, TracerProvider, and TextMapPropagator types to be set. (#2772, #2773)
Changelog
Sourced from go.opentelemetry.io/otel's changelog.
[1.6.3] - 2022-04-07
Fixed
Allow non-comparable global MeterProvider, TracerProvider, and TextMapPropagator types to be set...
Bumps go.opentelemetry.io/otel/exporters/jaeger from 1.6.2 to 1.6.3.
Release notes
Sourced from go.opentelemetry.io/otel/exporters/jaeger's releases.
Release v1.6.3
Fixed
Allow non-comparable global MeterProvider, TracerProvider, and TextMapPropagator types to be set. (#2772, #2773)
Changelog
Sourced from go.opentelemetry.io/otel/exporters/jaeger's changelog.
[1.6.3] - 2022-04-07
Fixed
Allow non-comparable global MeterProvider, Tr...
Bumps go.opentelemetry.io/otel/trace from 1.6.2 to 1.6.3.
Release notes
Sourced from go.opentelemetry.io/otel/trace's releases.
Release v1.6.3
Fixed
Allow non-comparable global MeterProvider, TracerProvider, and TextMapPropagator types to be set. (#2772, #2773)
Changelog
Sourced from go.opentelemetry.io/otel/trace's changelog.
[1.6.3] - 2022-04-07
Fixed
Allow non-comparable global MeterProvider, TracerProvider, and TextMapPropagat...
Cache invalidation explain
It's very common for an action (or a set of actions) to be re-executed given that "something" in the build cache changed. While speaking with @gerhard today across several topics, we came up with the idea that it'd be great if Dagger could output some optional detailed information about why the cache is being invalidated. I think this could potentially help to prevent mistakes and/or find issues/improvements in already executed pipelines.
As side nice-to...
I love this idea. I think it might be possible to do this with Buildkit Diff. @sipsma would be a good person to chat about this with.
Even being able to translate the cue tool/flow DAG into GraphViz dot would allow visualization.
Yeah "why am I getting a cache miss here" is a very frequently asked question in the Buildkit slack channel, something like this would be great for Dagger and Buildkit in general.
The decisions on whether to re-use cache or not are buried inside Buildkit's solver, so we'd probably want to integrate with it somehow. One possibility might be to re-use the progress system for this. The solver already publishes progress events like "this vertex is starting", it could also publish events when a...
Signed-off-by: Jeremy Adams
What is the issue?
In the docs we have this example of how to get the client platform's os and arch:
https://docs.dagger.io/1203/client#platform
package main
import (
"dagger.io/dagger"
"universe.dagger.io/go"
)
dagger.#Plan & {
client: _
actions: build: go.#Build & {
os: client.platform.os
arch: client.platform.arch
// ...
}
}
But if you flesh this out to make it runnable (package name, imports) and run th...
Ended up with the same error tat I couldn't get around. I may be a bit off, but I think it may be possible to get it running once this is fixed.
I run dagger in my virtual machine ubuntu, when i want update dagger cue pkg, so i run dagger project update in my terminal, but not work
After some checking, I found that there was something wrong with the directory that mounts to the virtual machine, but the error was hidden
dagger project update │>
6:43PM FTL system | vendor pkg failed: open /**/code/github.com/dagger-demos/cue.mod/pkg/dagger.lock:...
Signed-off-by: Andre Passos
What is the issue?
When running an older version of Dagger it notifies the user there is a new release. However, the URL provided is 404:
A new version is available (0.2.5), please go to https://github.com/dagger/dagger/doc/install.md for instructions.
This is coming from here.
I wo...
Retry
From my 2 days of observation with build kit...I found that dagger action failed sometime because of my miss configuration of buildkit, Other case can be registry is down. There are multiple case where dagger action can fail.
If you see any CI/CD Provider, This problem exist before a long time. Pipeline failed sometime because of package manager has issue or something else but no provider provide any solution for that.
But dagger is more like a DAG and if a DAG has retry o...
What are you trying to do?
Add CUE syntax highlighting support to highlight.js which is used by Discord in code blocks.
Why is this important to you?
Highlighted code is more readable and pleasant to look at for many users.
How are you currently working around this?
Today, I often hijack the typescript to render CUE code with some syntax highlighting, but there should be proper support for CUE.
e.g.
```typescript
params: {
imageBuild: {
...
What are you trying to do?
Port/reimplement the Terraform package to make it available with Dagger 0.2
Why is this important to you?
No response
How are you currently working around this?
No response
Signed-off-by: Nico Meisenzahl
Fixes #2109
@marcosnils @shykes are you guys planning it in next release or else for a time being i can write my own package. Without it we can't migrate
What is the issue?
The Dagger core action reference page has an incorrect link to the core actions page.
Incorrect link shown: https://docs.dagger.io/core-concepts/1221-action
Should be: https://docs.dagger.io/1221/action
What is the issue?
I've been trying to figure out what's going on here..
I'm on Windows 10, and can't seem to get dagger to work
dagger do build
4:24AM FTL failed to load plan: import failed: cannot find package "dagger.io/dagger":
C:\Users\agw\git\dagger-src\ci.cue:4:2
: running `dagger project update` may resolve this
I've run through a few things already, project initing project updateing
Destroying and recreating the docker host; I'm using Rancher Desktop v1....
What is the issue?
docker.#Run has a concrete definition that the command is always python3
I will add a one-line PR to fix this.
Log output
After changing pkg/universe.dagger.io/python/test/test.cue to add `image: "python3.8":
3:37PM FTL system | failed to load plan: 0: conflicting values "python3.8" and "python3":
/d/workspace/github.com/nottheeconomist/dagger/pkg/universe.dagger.io/docker/run.cue:92:11
/d/workspace/github.com/nottheeconomist/dagger/pkg/u...
Closes #2114
Signed-off-by: Adam Smith
the "result" property should be #AddHello’s, not dir's
the "result" property should be #AddHello’s, not dir's
Signed-off-by: Ace yu
the "result" property should be #AddHello’s, not dir's
Signed-off-by: Aceyu
Hi everyone, I've been looking at Dagger over the weekend and I'm excited by its possibilities! I think I've started to get to grips with how to build, run tests and deploy with it.
One thing issue I'm running into is knowing how to do one other part of my CI flow. Using pre-built tools to check the code, for example how to use this tool? https://github.com/zricethezav/gitleaks. On Github I would use the prebuilt action for this and on Gitlab I would simply run a step in the container and...
Yes, you can create an action that does this. If you're willing to contribute docs on that, please do! We appreciate contributions 🙂
Just a few pointers. There's two ways to go about it:
- Run the whole plan once (
dagger do deploy), but you need to make sure that the gitleaks action is a dependency of something in order to run before it. We don't have explicit dependencies yet, so if you need actions do depend on this one's success, and there's no clear field to use as a dependency,...
Resolves: #2059
Signed-off-by: Vasek - Tom C
Thanks for the reply @helderco. Thats good advice, I would probably add it as a dependency of test I imagine. I'm going to try and mock one of current workflows that I have on a project.
Is it expected that I would install Brew and install this tool manually or is there a way to run this container and bring the repo in then execute?
As for the docker vs install locally thing. Any recommendation on what would be best?
We definitely recommend running everything in containers so you don't depend on the local host. It's more portable this way.
What are you trying to do?
In the pipeline end, i need post some data to our internal api to report dagger result.
Why is this important to you?
No response
How are you currently working around this?
No response
I think jetbrains is working on an IDE that is compatible with LSP, so then you could have all the goodies from that.
This is what I was thinking about: https://www.jetbrains.com/fleet/
Not sure it integrates LSP natively, except for using some already existing plugins, though.
@arnaud-soulie && @PaulBarrie, we talked privately on the fact that you were interested in porting your Ansible PR to post-europa. It's going to be so useful. Please keep us in touch: https://github.com/dagger/dagger/pull/1653
Expose (and shout about!) the CLI's ability to run actions at any level of the DAG
It's taken me some weeks of using the dagger to discover that if I've defined:
actions: foo: bar: {
baz: { ... }
quux: { ... }
}
... then I can directly invoke quux via dagger do foo bar quux, with Dagger doing the hard work of figuring out, through the DAG, which pre-reqs from anywhere inside actions it needs to run first - and running only those.
This is a fantastic f...
Clearly and prominently document this feature and it's invocation on docs.dagger, explicitly calling out its fantastic "only perform the bare minimum pre-reqs" behaviour
This is a great idea, we should definitely document this better. Thx for the suggestion. Seems like you currently have a real case minimum example where this is worth to highlight. Mind sharing a more concrete case so we can add it to the docs?
Change the dagger do [--help] behaviour to display a nested tree of the ...
Basic UI local support.
Similarly to other projects like Hashicorp's nomad, it'd be awesome if Dagger had something like dagger ui which could bring a visual UX to have better visibility about action's results, fetch logs, re-run workflows, have local documentation, etc.
Signed-off-by: Helder Correia
Only install the dependencies I need in cue.mod, instead of the entire contents of universe...
What is the issue?
I gave Dagger a whirl this weekend and want to uninstall it from my machine, how do I do that?
Overview
This proposes a design in Dagger 0.2 to solve #940.
Problem
Most of the time, dependencies between Dagger tasks are implicit, thanks to the magic of CUE references. If a config value for task foo is referenced by a config value for task bar, Dagger implicitely knows that foo must run before bar.
But sometimes, foo must run before bar even though there is no dependency between their configurations. For example, foo might upload an artifact at a known...
@shykes The problem @grouville is facing (if I understand correctly) is: how does this work with higher level packages?
Let's say you want yarn.#Package to wait for a docker.#Run to complete.
The problem in dagger mainstream is you have no idea which fields are the output of tasks (e.g. can be used as completed field) and which ones are inputs of tasks, since you're working with an abstraction (multi layered at that, e.g. docker.#Run -> docker.#Command -> os.#Container -> `a...
@shykes The problem @grouville is facing (if I understand correctly) is: how does this work with higher level packages?
Let's say you want
yarn.#Packageto wait for adocker.#Runto complete.The problem in dagger mainstream is you have no idea which fields are the output of tasks (e.g. can be used as
completedfield) and which ones are inputs of tasks, since you're working with an abstraction (multi layered at that, e.g.docker.#Run->docker.#Command-> `os.#Contai...
I updated with not one, but TWO design options. Let me know what you think @grouville @helderco
Most of the time, dependencies between Dagger tasks are implicit, thanks to the magic of CUE references. If a config value for task
foois referenced by a config value for taskbar, Dagger implicitely knows thatfoomust run beforebar.
This makes me think any reference is valid.
The problem in dagger mainstream is you have no idea which fields are the output of tasks (e.g. can be used as
completedfield) and which ones are inputs of tasks, since you're working with an a...
Reading on cue flow...
I don't have a strong opinion on all these alternatives, but I like the UX of the third option (@helderco's one) the most (even though his current example isn't fully functional atm [theoritically]). From what I understand, helderco's proposition might be possible with your Option 1: id convention.
The second option seems more "risky" because it relies on Cue to expose subfields in the scope of the if (which led to some issues in the past). @helderco's comment is also relevant, it may ...
Picking this up.
- I updated the top comment, with a summary table of our 3 options.
- Per discussion with @jlongtine : it’s not clear which options work out of the box within the limitations of
cue/flow. It’s possible that none do. There is a chance that option 1 (#Wait) does work if designed correctly: Joel is testing this now - Overall my favorite candidate is Option 1 at the moment.
- An explicit engine API call remains the cleanest way to synchronize IMO. Since it’s the same ...
Duplicate of #940
I edited the title & description to clarify that this is a design proposal, to solve #940 in Europa. I think it's OK to keep both open.
I'm look forward to this new feature
a real case minimum example
For me, having the ability to target nested actions is when I have this:
actions: {
build: { ... emit BuildImage, but don't push it remotely ... }
test: {
tool1: { ... use BuildImage ... }
tool2: { ... use BuildImage ... }
tool3: { ... use BuildImage ... }
}
}
... and having to choose between dagger do test as my pass/fail cycle while I make changes, versus dagger do test tool2.
In other words: because my entry poin...
Bumps cypress from 9.5.3 to 9.5.4.
Release notes
Sourced from cypress's releases.
9.5.4
Released 4/11/2022
Bugfixes:
Updates were made to silence Electron warnings related to being unable to
connect to dbus. These errors are normal and expected, and do not result in
test failures. Because they are always present when running Electron inside
docker containers, it has incorrectly led people to believe it is the
root-cause of an error within their test...
Use a modern web font with a better render on non-retina display
Signed-off-by: jffarge
This fixes an issue with https://github.com/dagger/dagger/pull/2122
Signed-off-by: Helder Correia
/cc @marcosnils @jpadams
Our docs don't have a dedicated page for download / install options. Currently they are hidden in the "getting started" tutorial.
What is the issue?
Dagger documentation is using Docusaurus. By default, it throws an error, to ensure you never ship any broken link, but current configuration has lower this security by displaying a warning message.
The following parameter should be remove to let Docusaurus get back its default behavior.
onBrokenLinks: "warn",
this will throw an error if docusaurus find any broken links
Signed-off-by: jffarge
VSCode extension
I'd like a proper integration with the Language Server Protocol and a nice VSCode extension that comes with it. It's important for CUE and libraries added by Dagger. I spend too much time reading through the library code base to know what I can use, ideally VSCode could auto-complete everything nicely.
_Originally posted by @samalba in https://github.com/dagger/dagger/discussions/2052#discussioncomment-2512196_
I created a new issue to track this: https://github.com/dagger/dagger/issues/2132
Add a guide which highlights how to handle action's outputs by writing
them to the client filesystem and using CUE's integrations to marshal
them as JSON.
Signed-off-by: Marcos Lilljedahl
cc @helderco @jpadams
I think moving the contribution guide to the docs website gives more visibility.
Also adding a CONTRIBUTING.md file for GitHub links and easier discovery for someone browsing the repository’s files. I know that you'll open the link from github and find that you need to click on another link, but I don't find it reason enough to prevent this move. This is how django does it, and many other big projects.
People seem to not...
Problem
Sometimes I want to check if a file exists. There is not core action to do this: core.#ReadFile will simply fail if the file doesn't exist, causing my entire execution to stop.
Solution
Two possible options:
- Add
core.#Statto return information about a path: whether it exists, whether it's a file or regular directory, permissions, etc. - Extend
core.#ReadFileto support a default valuecontents: string | *null. If the file doesn't exist, then the default v...
Remote Projects
If there's a Dagger project in, say, a git repository somewhere, I should be able to run actions from it directly without necessarily having to clone the repo manually. The idea is to sort recreate the magic of docker run <image> where the overhead of playing around with a container image is compressed to a single command, but now applied to the problems dagger is tackling. Once I have dagger installed, I should be able to start trying out plans immediately.
There...
Standalone Dagger Binary
The dagger binary could optionally embed everything it needs to run rather than have a hard dependency on an external Buildkit daemon and/or container runtime. Buildkit can be embedded as a library and even runc can be embedded via libcontainer (though Buildkit will need some upstream support for all of this).
This would not replace use of a standalone Buildkit daemon (which will have advantages like supporting multiple clients in parallel), but could be use...
What are you trying to do?
Have reusable dagger commands for lua for linting/formatting checks using stylua and luacheck
Why is this important to you?
Makes creating CIs for lua projects easier to lua/neovim community
How are you currently working around this?
None
Creating lua package for fmt and linting
#2137
This would require the dagger binary to be run as root, right? How realistic would be thinking about using rootless buildkit?
Added to this epic: https://github.com/dagger/dagger/issues/613
I'm working on it this week :muscle:
Console UI
The console experience (e.g. status of dagger do) is not great. Oftentimes, we have to resort to --log-format plain --log-level debug because the default suppresses important information. In no particular order:
- TTY rendering is buggy (e.g. flashing/broken lines)
- Some errors are suppressed when run fails (e.g. container logs)
- It's not clear what's going on, the list of actions is confusing. Currently the CUE path of all "actions" is displayed. I think there are...
This would require the dagger binary to be run as root, right? How realistic would be thinking about using rootless buildkit?
Yeah this is where things get more nuanced. There's multiple options (which aren't mutually exclusive):
- Run as root (i.e. with sudo). There are ways to do this without completely sacrificing security though. For example, you could have users start the binary with sudo but then fork/exec off the privileged part and drop privileges in the process that doesn't ne...
Though it is worth noting that I have created a fully standalone binary that embedded buildkit+libcontainer and ran rootlessly (as part of a past side project), so I do know it all technically works
:man_technologist: :rocket:
I mainly wanted to bring the idea up to see if there's interest in it from users so we can weigh the cost/benefit, but the cost in terms of effort is most certainly fairly high
definitely something having in the radar. I personally don't see developers g...
Generally speaking, buildkit cache export/import is pretty limiting because it's not "shared": every export cache overwrites the previous one, therefore CI runs are overwriting each other's cache. Persistent cache dirs are not part of the cache. And caching outside of GHA requires setting up some infrastructure (e.g. pointing to a registry).
This is a broad issue, keeping track of CI caching related issues:
- Using the GitHub Action, cache should work out of the box nicely
- #1345
...
- #1345
Created a parent issue to track all of this: #2140
Dagger TDD/BDD as first class concept
We can create a Dagger definition and a plan to test that new definition using bash/bats, like dagger team does in universe package.
I would like Dagger introduce tdd/bdd using cue syntax
dagger.#Spec & { // Like Dagger plan
"removeSNames": dagger.#Describe & {
"should remove all S names": dagger.#It & {
// verify definition
}
"should not remove other names": dagger.#It & {
// verify d...
I created an issue to track this request: #2141
Declaratively Trust CA Certificates
- As a developer, I'd love it if I could declaratively tell dagger/buildkit that I want to trust my organization's private CA cert, so that, for example, actions like
docker.#Pullanddocker.#Pushwork with our internal registry.- Currently, a buildkit instance must be created manually with the private CA cert(s) mounted into it.
- E.g. `docker run --net=host -d --restart always -v $PWD/myCA-cert.pem:/etc/ssl/certs/myCA-cert.pem --nam...
- Currently, a buildkit instance must be created manually with the private CA cert(s) mounted into it.
I created an issue to track this: #2142
Using #940 to track this (#1248 was converted to a discussion)
Jetbrains / Intellij plugin
(similarly to VSCode extension above)
There is an existing plugin here that provides cue support: https://github.com/monogon-dev/intellij-cue but unfortunately does not seem to be updated. Could be used as a base though?
References:
- https://plugins.jetbrains.com/plugin/16126-cue (which is https://github.com/monogon-dev/intellij-cue)
- discussion on intellij tracker: https://youtrack.jetbrains.com/issue/IDEA-242301
- discussion on the cue tracker: ht...
Tracked in #2143
@dubo-dubon-duponey I assume Jetbrains / IntelliJ support LSP, right? In which case when developing a language server for vscode, adding support for other LSP compatible IDEs should be trivial
Visualize the DAG
Being able to visualize the DAG, wether it is through an ASCII code or a web UI
_Originally posted by @grouville in https://github.com/dagger/dagger/discussions/2052#discussioncomment-2517752_
definitely something having in the radar. I personally don't see developers getting rid of {Docker, Rancher} Desktop anytime soon, but it's good to have these options mapped out.
Agreed 100%, this type of feature would probably most appeal to users running in more "esoteric" circumstances (but I have been surprised in the past).
HowTo: Write a Plan
It all starts with a plan, so it makes sense that you would want to understand how to write your own plans. Currently it's not entirely clear how a new developer could become skilled at writing one.
_Originally posted by @mr-joshcrane in https://github.com/dagger/dagger/discussions/2052#discussioncomment-2512326_
You need a plugin for LSP support.
Maybe their new Fleet thingie has native LSP support? Not completely sure.
Either way, if you are going to do LSP for VSCode anyhow, it's totally worth starting with that and seeing if that flies with Jetbrains IDEs and reassess if need be.
nest tree is very important for newer.
maybe dagger draw can build a full tree, display by svg? the leaf node i wish is task node.
Problem
When dagger do fails when a command fails to execute (core.#Exec, docker.#Run, etc), only a very generic error message is printed, for example:
10:58AM FTL failed to execute plan: task failed: actions.build._build: process "/bin/sh -c npm i" did not complete successfully: exit code: 1
To learn more about the cayse of the error, one must re-run dagger do with additional logging flags, to stream stderr from every command. This is tedious and unreliable.
...
Run multiple actions from one invocation
Similar to how Gradle might run
$ ./gradlew assemble check
It would be useful (though low-priority) to run multiple actions in the same invocation of the binary. Perhaps introduce an explicit flag --action that can be multi-included? dagger do --action='foo bar' --action='foo baz'. This seems preferable than changing the syntax to, perhaps, dot-separated nested actions and whitespace-separated multiple actions (`dagger do foo....
Linter for Package Coding Style
It would be great to have a linter to enforce the package coding style.
It would be even better if this was a plug-in design so I could use my testing framework of choice and bats is the default/example implementation.
Related to this, a --dryrun flag that produces a best effort representation of the plan without executing any steps. Maybe a simplified tree view of the cue eval equivalent.
Hi @grouville, it is underway. I'm adapting the package to the new standards. I will be able to deliver a first sketch in the coming days :)
I will say that my team has interest in a completely rootless solution for building and running container workloads. Friends don't let friends run meaningful workloads as root.
Help with using Go modules in Dagger. There is a huge collection of available Go client libraries to interact with various services. Some get packaged into a CLI. Some are just native Go clients. Sometimes I just need one submodule and it would be a lot faster in CI to go get a single module instead of apt install or docker pull the whole tool and all of its dependencies.
Is this reasonable functionality to implement in Dagger or should we continue to focus on just bash/make equival...
I don't understand your use case.
You need a Go CLI for your CI?
You need a Go module code to import in your Go project?
Before and After: Documentation on porting a simple workflow from GitHub Actions/Gitlab CI
I couldn't migrate a single job to dagger. Docker build, tag, push? Helm install? Running a bash script? Dependencies? Concurrency of jobs? Artifacts?
I know all these features exist somewhat in dagger. But showing a before and after in the documentation in one guide would be very helpful to learn.
What are you trying to do?
I know the person who created this PR: https://github.com/facebook/docusaurus/pull/3558
I just asked him how hard it would be to implement a scoped embedding like the Go present tools use
Why is this important to you?
Then we could dump our .cue.fragment files, and only use the full file that we could run tests on, but that we could scope with markups to just present the part we...
They create conflict in gopls (for the govim plugin)
I see.
It is completely possible, but it just requires elbow grease to integrate those as cue modules. But it is the goal to support that.
As a first step, though, it might be simpler to just use a base image with the 160MB az cli embedded.
Adds an FAQ section answering the most common mistakes / questions encountered when doing support: emptying buildkit cache, having better logs, always executing an action, chaining actions together and default values in Cue
Signed-off-by: guillaume
Ive managed to get an example of a pipeline using some tools to very basically check the code for linting/security issues and run some integration tests. https://github.com/RemakingEden/Dagger-Node-Github-Example/blob/main/eden.cue.
Where the "Go on Docker Swarm" use case lost me a little is its focus on the build and can be a little complex.
I wonder if a use case that has:
- A build step
npm install - Some tests (int and unit)
- Some containerised tests (Gitleaks, SonarScan...
What is the issue?
The universe.dagger.io/docker package is so widespread, it deserves its own guide for explaining how to use it, showing common patterns, etc.
The more use cases the better! The one you describe seems very useful.
Great i'll get on that now then, trying to use the same style as the "Go on Docker Swarm" use case. Thanks.
What is the issue?
This page doesn't seem very welcoming for users. I have the feeling that we want to get straight to the point but maybe it's too fast ?
A simple Welcome message with a short intro of Dagger ? A nice illustration ?
Welcome to the documentation for Dagger. Dagger is a tool to run your CI/CD pipelines locally, then easily integrate them with any CI environment.
I want to play with Dagger now! Ok then, let's test and run a CI/CD pipeline locally :)
////// L...
What is the issue?
Hi,
I found a minor issue in the license file. On line 190 there's Copyright [yyyy] [name of copyright owner] which seems like it's missing a year and copyright owner. :slightly_smiling_face:
What is the issue?
If I'd follow GitHub integration manual as-is, I'm going to get following error: failed to load plan: dagger project not found. Run dagger project init. That's because cue.mod` is not there.
I think the documentation should give either recommendation to commit cue.mod to git (is it a good idea?), or explicitly offer run init & update as part of GitHub workflow:
- name: Init dagger (dagger project init...
fixes #1689
encounter this issue while making a review for the GitHub Action: https://github.com/dagger/dagger-for-github/pull/47
/opt/hostedtoolcache/dagger/0.2.6/x64/dagger do test --log-format plain
time="2022-04-13T00:09:40Z" level=warning msg="commandConn.CloseWrite: commandconn: failed to wait: signal: terminated"
time="2022-04-13T00:09:40Z" level=warning msg="commandConn.CloseRead: commandconn: failed to wait: signal: terminated"
time="2022-04-13T00:09:40Z" level=...
Document better actions inputs / outputs
Sometimes I find myself jumping between a task definition [1] and it's corresponding source code [2] to understand what some actions are doing in regards to inputs and outputs. The API docs [3] also don't mention this information.
It'd be nice to have a page a la terraform registry [4] with more structured information about the actions and their corresponding inputs / output values
[1]: https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagg...
Improve Package Management
Non exhaustive list of requirements, in random order:
- Do not require to commit vendored packages in
git(e.g. commit onlydagger.modanddagger.sum, just like go) - Treat
dagger.io/daggeranduniverse.dagger.ioas external packages- Fetch them from
gitrather than embedding in the binary - Figure out version management
- Fetch them from
- Support "tidy"'ing, i.e. remove stuff in cue.mod/pkg that's not being used
- Support
replacedirectives like ...
Cache invalidation explain
It's very common for an action (or a set of actions) to be re-executed given that "something" in the build cache changed. While speaking with @gerhard today across several topics, we came up with the idea that it'd be great if Dagger could output some optional detailed information about why the cache is being invalidated. I think this could potentially help to prevent mistakes and/or find issues/improvements in already executed pipelines.
As side nice-to...
Remote Projects
If there's a Dagger project in, say, a git repository somewhere, I should be able to run actions from it directly without necessarily having to clone the repo manually. The idea is to sort of recreate the magic of docker run where the overhead of playing around with a container image is compressed to a single command, but now applied to the problems dagger is tackling. Once I have dagger installed, I should be able to start trying out plans immediately.
There are...
@sipsma This would only work on "libcontainer native" platforms, right? (e.g. linux)
Platforms requiring a VM (e.g. macOS) would still need to go through Docker for Desktop or equivalent, correct?
Run multiple actions from one invocation
Similar to how Gradle might run
$ ./gradlew assemble check
It would be useful (though low-priority) to run multiple actions in the same invocation of the binary. Perhaps introduce an explicit flag --action that can be multi-included? dagger do --action='foo bar' --action='foo baz'. This seems preferable than changing the syntax to, perhaps, dot-separated nested actions and whitespace-separated multiple actions (`dagger do foo....
Linter for Package Coding Style
It would be great to have a linter to enforce the package coding style.
_Originally posted by @ivorscott in https://github.com/dagger/dagger/discussions/2052#discussioncomment-2551102_
dagger.#Service was renamed dagger.#Socket in #1889 (see #1870)
While the CUE API was updated, there's still bits of Go code using Service (due to time constraints at the time).
/cc @helderco
This would only work on "libcontainer native" platforms, right? (e.g. linux). Platforms requiring a VM (e.g. macOS) would still need to go through Docker for Desktop or equivalent, correct?
Yeah, what I described would only work on Linux. I'm sure in theory you could make something equivalent to what you get with embedded libcontainer for other OSes, but that would probably end up being a lot of work if it doesn't happen to already exist.
What are you trying to do?
Rather than building our own Python image from Alpine, we should use the official Python image produced by Docker https://hub.docker.com/_/python
After discussion on Discord, this seems to be preferred by a majority of responding maintainers. I will contribute a PR.
Why is this important to you?
Using the official image is the natural thing to do and will be what most Python developers expect. In addition to the DX advantages, using the official image ...
What is the issue?
When i started to use the Template for Gitlab (we are using GitLab SaaS) Everytime I get the Errors regarding in the Log output.
other Pipelines works with dind but not with the dagger template.
this is my cue file
package frontend
import (
"dagger.io/dagger"
"dagger.io/dagger/core"
"universe.dagger.io/alpine"
"universe.dagger.io/bash"
"universe.dagger.io/docker"
"universe.dagger.io/docker/cli"
)
dagger.#Plan & {
_nodeModulesMount: ...
closes #2169
Signed-off-by: Adam Smith
link package
It would be nice to be able to link a local package. A bit like you can do with yarn link or npm link.
I am developing a reusable action catalog specific to my company to give some context.
I made a separate project with my custom actions. And in the target project, I install it with the command:
dagger project update --private-key-file ~/.ssh/id_rsa --private-key-password "my-password" myrepo.url/ci/dagger@v0.1.0
But when I try to contribute a...
This is already in https://github.com/dagger/dagger/discussions/2052#discussioncomment-2527660:
- Support replace directives like in Go (e.g. replace dagger.io/dagger => ~/work/dagger/pkg/dagger.io)
Hi @jlongtine If you are looking for directed acyclic graph layout algorithms in pure Go, https://github.com/nikolaydubina/go-graph-layout is currently the best, as it implements the Kozo Sugiyama layer algorithm, which does edge crossing minimization fairly efficiently. GraphViz is the gold standard, but requires cgo, as does the rearchitected dynadag in C++. The closest port of GraphViz to another language besides Go is currently https://github.com/erikbrinkman...
Thanks to a great community contribution, we are improving the GitHub Actions integration further. We should probably do the same for the GitLab integration doc as a follow-up to this.
This should be merged after https://github.com/dagger/dagger/pull/1962. Maybe @ekinbarut wants to take a look at it 👋🏻
0.1 docs is deprecated. Let's inform users to switch to the latest version
Signed-off-by: user.email
What is the issue?
@vandlol is wondering how can he use his own repository to store & use dagger packages. This sounds like a great FAQ to me.
Oh sorry, I haven't seen that point.
Vercel. cc @nabsul @marcosnils
Fly
This is my starting point here: https://github.com/thechangelog/changelog.com/pull/407/files#diff-7f9a218d671a3accf380cc0a32121c588ecec518e18dabdb544b83f3f64fb8a9
cc @mrkurt @brainlid @chrismccord
I would especially like to move this into a Dagger plan: https://github.com/thechangelog/changelog.com/blob/7b8c2a48a01fc11aa2c5848c680c589a09db0b66/2021/manifests/changelog/jobs.yml#L18-L72
There is a lot of that here, and while we intend to move to something like Vault, we are still using LastPass today.
Support for Azure
Secret management: Retrieving secrets from Azure Key Vault
Deployments: Deploying to Azure Static Web Apps, Azure Functions, Azure Container Apps, ...
IaC: Bicep
IMO those would be a good starting point.
We should host a binary-on-demand service eg. get.dagger.io/binary/dagger-$GITREF.tgz that builds the requested version just-in-time for download.
_Originally posted by @shykes in https://github.com/dagger/dagger-for-github/issues/35#issuecomment-1071971420_
What is the issue?
From feedback on twitter:
Oh and apparently you can write Dagger actions in "Python, Go, TypeScript, Ruby, Java, and shell scripts".
@dagger_io how do I do this? I cannot find any docs on your site on how to write Dagger actions in those language. My first impression was you MUST use Go for it.
What are you trying to do?
I created a custom package, imported it and tried the following but received an error.
package main
import (
"dagger.io/dagger"
"github.com/ivorscott/helloworld/pkg/hello" // my custom package
)
dagger.#Plan & {
// Say hello by writing to a file
actions: {
hello: hello.#AddHello & {. // <--- WON'T WORK - VARIABLE IS SHADOWED BY PACKAGE NAME
dir: client.filesystem.".".read.contents
}
}
...
Closes #1924
Signed-off-by: Stavros Panakakis stavrospanakakis@gmail.com
What is the issue?
There are regressions in the test suite caused by changes in comprehensions and tasks in latest master.
#2094 was an attempt to explore this. It's now closed, but I'll re-open/open a new PR when I dig back into this.
Log output
No response
Steps to reproduce
https://github.com/dagger/dagger/pull/2094
Dagger version
main
OS version
macOS 12.3
Bumps github.com/spf13/viper from 1.10.0 to 1.11.0.
Release notes
Sourced from github.com/spf13/viper's releases.
v1.11.0
What's Changed
Exciting New Features 🎉
Experimental yaml v3 library support by @sagikazarmark in spf13/viper#1273
Experimental toml v2 support by @sagikazarmark in spf13/viper#1274
Experimental logger by @sagikazarmark in spf13/viper#1275
Enhancements 🚀
Remove unnecessary operand by @steviebps in spf13/viper#1213
Improve encoding...
What is the issue?
After a dagger project init (without args), the created cue.mod/module.cue file contains:
module: ""
It's not clear to a new user what that means and if it's related to the package name in their cue files.
https://cuelang.org/docs/concepts/packages/#packages
https://cuelang.org/docs/concepts/packages/#modules
https://cuelang.org/docs/tutorials/tour/packages/packages/
https://cuelang.org/docs/tutorials/tour/packages/imports/
https://github.com...
- Clarify a title
- Move 0.1 migration to guides
- Remove duplicate sidebars entry
@StevenACoffman Thanks for the links! go-graph-layout looks nice! The other piece that I'm still unsure how to do best is the actual rendering of ASCII/Unicode in the terminal given the node locations, etc. I haven't had the time to spend to dig more deeply into that.
Use the new flag --action to specify each action. This change is
backwards-compatible so continuing to use dagger do actionName is accepted and
encouraged. In fact they will work together: dagger do -a action1 action2
will run both actions.
Signed-off-by: Adam Smith
Hi,
I know there is another contribution for a Terraform package (https://github.com/dagger/dagger/pull/2110), but this one we are currently using and implementing at work, and currently supports a lot more features. The approach is similar to Nico's implementation, so feel free to merge it into his package if necessary.
Implementation details
There is a terraform.#Run action to wrap the Terraform command and run it within the official Terraform container image, from Hashicorp....
java:
- maven
- gradle
clojure:
- leiningen
- clojure-tools
Signed-off-by: Ezequiel Foncubierta
I know there is another contribution for a Terraform package (#2110), but this one we are currently using and implementing at work, and currently supports a lot more features. The approach is similar to Nico's implementation, so feel free to merge it into his package if necessary.
Implementation details
There is a terraform.#Run action to wrap the Terraform command and run it within the official ...
What is the issue?
I tried to use Minikube as Kubernetes cluster, and mount kubeconfig in docker.#Run, but It can't access Minikube Kubernetes api server.
I tried to use KiND, It worked. so I want to know if we have any solution for access Minikube with docker.#Run or bash.#Run.
Log output
4:26PM INF actions.test.run._exec | #3 3.141 The connection to the server 127.0.0.1:51686 was refused - did you specify the right host or port?
4:26PM INF actions.test.run._exec | #3 3.595 Th...
With the upcoming release of our GitHub Actions, args has been replaced with cmds input allowing multi dagger commands within a single step.
Signed-off-by: CrazyMax
There's a few issues people are having due to the way client: filesystem and client: network paths are set.
Typos in references to path
This one should be easy to spot, but users get confused when they make a small change to a path and don't reflect the exact same path string it in all references to it. For example:
I've seen variations of this while giving support, although users have been understanding of the typos, it's just...
I too have a large customer on ADO - would like to leverage there.
What are you trying to do?
Early versions of Docker allowed execing into intermediate build steps since intermediate images were generated and spawning a container with any of these images was extremely useful for troubleshooting productivity. Since docker (and also dagger) are using buildkit, this UX has been lost and the current way people are troubleshooting this now is commenting out part of their build pipeline only export the end result into an image and then execing into that...
Bumps async from 2.6.3 to 2.6.4.
Changelog
Sourced from async's changelog.
v2.6.4
Fix potential prototype pollution exploit (#1828)
Commits
c6bdaca Version 2.6.4
8870da9 Update built files
4df6754 update changelog
8f7f903 Fix prototype pollution vulnerability (#1828)
See full diff in compare view
Maintainer changes
This version was pushed to npm by hargasinski, a new releaser for async since your current version.
[![Dependabot compatibility sc...
Bumps async from 2.6.3 to 2.6.4.
Changelog
Sourced from async's changelog.
v2.6.4
Fix potential prototype pollution exploit (#1828)
Commits
c6bdaca Version 2.6.4
8870da9 Update built files
4df6754 update changelog
8f7f903 Fix prototype pollution vulnerability (#1828)
See full diff in compare view
Maintainer changes
This version was pushed to npm by hargasinski, a new releaser for async since your current version.
[![Dependabot compatibility sc...
What are you trying to do?
Dagger should be capable of loading a file into a docker container without having to mount a file system e.g. directory or work with a secret.
The equivalent in docker would be a docker run -v /path/file:/path/file image command.
@aluzzardi @jpadams FYI
Why is this important to you?
Currently reading in just a file is not trivial to do as the #Mount definition's contents field is not capable of working with a value that is a string e.g a f...
For password storage i really would like to see passwordstore (https://www.passwordstore.org/)
From discord:
I'm not seeing any tests (.cue, .bats) in dagger.io/dagger or dagger.io/dagger/core like we have in universe.dagger.io packages. I often look to those for example usage. Was looking just now to answer a question from user about core.#Export
From @aluzzardi
We should probably follow the same structure in both ... core predates universe, we improved the organization of tests but never backported old tests
This is for better visibility into the contents of tag.
Signed-off-by: Helder Correia
BREAKING CHANGE: don’t use dagger.#Address.
Related to #1997
Signed-off-by: Helder Correia
Four comments in a row say jenkins. Can we please search and simply upvote previous comments?
What are you trying to do?
Add pre-commit support for CUE / dagger
https://pre-commit.com/#supported-languages
Why is this important to you?
No response
How are you currently working around this?
No response
What is the issue?
https://docs.dagger.io/1200/local-dev
0.2.4 listed in examples, would be ideal if this was latest release (0.2.6 when this was written).
Could this be automated easily/reliably?
Hello,
this project looks very interesting, however, I am using nix to ensure the environment is accurate so there is no need for docker here. I was wondering if there is any action to run commands locally, I saw you can execute commands with client.commands but I don't think this was its intended use case (for starters, it won't output stdout/stderr if the command fails).
Thanks!
Vault integration
We use vault to provision our secrets. I think it would be cool to have an integration with dagger.
Related to #1997
Signed-off-by: Helder Correia
What is the issue?
I have overridden the go image used by the go.#Test action, to use a custom private image. Like this:
go.#Test & {
package: "./..."
source: _source
go.#Container & {
input: _goImage.output
command: {
flags: {
"-count": "1"
"-race": true
}
}
}
}
But when I execute my action, the official hub image is still pulled.
And this is a problem for me on gitlab because I reach the docker hub quota faster. And I think it...
The idea is to have go.#Test.packages that can accept either a string, or an array of string so we can do
go.#Test & {
packages: "./..."
}
go.#Test & {
packages: ["./pkg1", "./pkg2"]
}
Pros
- match the
go testbetter (we can use multiple packages)
Cons
- can confuse the user (is it a string? is it an array?)
Defaulting to 0o600 makes the file inaccessible to core.#Exec actions
running with a user field.
Ideally #WriteFile should support user/group in addition to
permissions.
This adds a new task type called AsyncExec which has a similar interface
as Exec, but unblocks once the exec has started rather than waiting for
it to complete. A separate type, StopAsyncExec, can be used to stop it
explicitly. If it isn't stopped, then it will be killed once the dagger
client shutsdown.
This is intended for creating ephemeral services used by other tasks in
the DAG, such as a DB against which tests can be run in different tasks.
AsyncExecs cannot output state and ...
I see that https://github.com/dagger/dagger/pull/751 added support for v0.1 pipelines but it doesn't seem to be supported anymore.
Is anyone working on it? Else, I'm willing to pick it up.
What are you trying to do?
I'm using Github Codespaces to write contributions for the Dagger repo, but the default Codespaces environment is general purpose and so isn't tailored for this specific repo. It would be useful to have a fixed Codespaces configuration for this repo for repeatable dev environments on any branch.
Why is this important to you?
I can easily work on this repo without having to make sure I have my dev environment set up correctly. Additionally every branch I w...
Signed-off-by: Berry Phillips
Closes #2216
The configs are auto-generated by Visual Studio Code and I have added additional configuration to support the basic needs of this repository. I added a section in the FAQ for this. I don't know if that's the best place or if there should be a dedicated doc for this 🤷🏻♂️
Testing
Spin up a new Codespace from my branch and ensure the following:
- Visual Studio Code loads without errors or warnings
- The
daggerandcuecommands are...
What are you trying to do?
I'm building a system.
Because CUE is awesome, I want this system to use CUE.
Because Dagger is awesome, I want the people building this system to use Dagger to build it.
Because I am awesome, I want both my users and developers to have a great DevX. This means I'd like characteristics like:
- the ability to sit in the root of the project and use the project with commands like
./bin/fooandcue def .:my-cool-project - the ability to sit in the ...
What about Manage packages using the package manager? It's the next logical step to Create your own package (Develop a new CUE package for Dagger).
I'll write both.
Note: Using the package manager can be used standalone if you're reusing packages from others, but there's no sense in creating a package for yourself without using the package manager ...
The Dagger Core Concepts > Dagger Actions page shows a hello world example dependent on two packages (main + hello) but this is confusing if the reader doesn't understand how packaging works. https://docs.dagger.io/1221/action
Packaging has yet to be explained: #2220. We should avoid showing this too early in the documentation.
The Dagger Core Concepts > Dagger Actions page shows a hello world example dependent on two packages (main + hello) but this is confusing if the reader doesn't understand how packaging works. https://docs.dagger.io/1221/action
Packaging has yet to be explained: #2220. We should avoid showing this too early in the documentation.
What is the issue?
From the repository I was trying to create a new project by following https://github.com/dagger/dagger/blob/v0.2.6/docs/learn/1003-get-started.md, thanks to @jpadams for pointing to the updated articles, however, the current articles does not cover the instructions to create a project from an empty directory as the deprecated article did.
One option here would be add a "your first project" or something to the Getting Started or Guides section, with the same intent...
What are you trying to do?
Currently for Dockerfile actions and the tty output, we've "hacked" an improvement to better display error messages here https://github.com/dagger/dagger/pull/2188. However, in order to have a "proper" solution for this, we'd need buildkit to return some metadata on it's SolveStatus here (https://github.com/moby/buildkit/blob/master/client/graph.go#L49) so we can get more contextual information about where events are coming from. After brainstorming this with @...
my vote for Azure DevOps as well.
What are you trying to do?
Back in the 0.1 days, you can input the entire config file into data as structured data:
dagger input yaml parameters -f app.yaml
Here is the full example: https://github.com/hongchaodeng/ai-demo/blob/main/app.yaml
It will automatically converts to a CUE struct which can then be used in latter actions.
But now all you can do is to input ENV style string input. This is very cumberson.
Why is this important to you?
No response
...
I was confused by this FAQ until I realised it had misleading code. This is a tiny PR to fix the misleading code.
What are you trying to do?
I have exposed Buildkit as TCP service in a remote machine. It's public internet so I am setting up mtls + certs. Like this:https://github.com/moby/buildkit#expose-buildkit-as-a-tcp-service
But the docs did not mention anything about how to set certs on client side (Dagger). Is it supported yet?
Why is this important to you?
No response
How are you currently working around this?
No response
What is the issue?
I cannot build example todoapp. Maybe because I'm in private network (not reachable to any public DNS)
Log output
~/github.com/dagger/pkg/universe.dagger.io/examples/todoapp$ dagger do build
11:33PM INF upgrading buildkit have host network=false version=v0.10.1
WARN[0008] commandConn.CloseWrite: commandconn: failed to wait: signal: terminated
WARN[0008] commandConn.CloseRead: commandconn: failed to wait: signal: terminated
11:33PM INF upgrading bui...
This PR is an adaptation to the new dagger release of the Ansible package proposed in this PR.
What is the issue?
Looks like this for me on mobile safari:

Log output
No response
Steps to reproduce
No response
Dagger version
na
OS version
ios 14.2
What is the issue?
Users often use field names like source and config that are the same as fields inside of definitions. Users aren't sure to describe what's going on:
Whenever you're using the same name as key and value, there's a potential for some weird assignment error I don't quite understand.
This can create an issue...
_image: docker.#Dockerfile & {
source: source
}
that can be fixed like this:
_image: docker.#Dockerfile & {
"source": sour...
Adds documentation for podman and kube-pod to operator-manual. Resolves #1959
Signed-off-by: Jonathan Dickinson
Bumps sass from 1.50.0 to 1.50.1.
Release notes
Sourced from sass's releases.
Dart Sass 1.50.1
To install Sass 1.50.1, download one of the packages below and add it to your PATH, or see the Sass website for full installation instructions.
Changes
Embedded Sass
The JS embedded host and the embedded compiler will now properly avoid resolving imports relative to the current working directory unless '.' is passed as a load path.
Fix a bug in the JS e...
Disclaimer: I'm not really sure about where to add those files (I've never written CUE before) and I'll be happy to move them around if required.
What is it?
I've tried my best to use the alpine package as a template for this debian package.
Why?
I've missed it like 10 minutes after I started tinkering with Dagger
What is the issue?
When an image is pushed to harbor via dagger, it will not show up in its GUI

Log output
This moves the go unit test from the Makefile to the dagger Plan. The issue was the GCC dependency and CGO. I added build dependencies to the base image, I was tempted to add a packages key to go.#Container but I don't want to leak alpine-specific package names in the higher api (we could technically build Go apps without Alpine). Also I think it makes sense to have access to the build packages in a container image that's only used for building.
What are you trying to do?
Hashicorp Vault is a wildly popular secrets store.
Ex:
vault read -format json
Why is this important to you?
No response
How are you currently working around this?
No response
What are you trying to do?
Use a private docker registry instead of docker hub for all images.
Why is this important to you?
We have a corporate Artifactory implementation which proxies all docker images through a private registry. like
myregistry.company.com/alpine:3
which actually proxies the image via docker hub.
Currently, universe packages such as Alpine and Nginx uses hardcoded docker hub registry like
docker.#Pull & {
source: "index.docker.io/alpine:\(v...
So we can see/grep more clearly what is the issue from the CI log.
What is the issue?
When you use, like in gitlab documentation example, the dagger cache arguments buildkit throw an error related with multiple cache exports.
Log output
WARN[0000] local cache import at .dagger-cache not found due to err: could not read .dagger-cache/index.json: open .dagger-cache/index.json: no such file or directory
WARN[0000] local cache import at .dagger-cache not found due to err: could not read .dagger-cache/index.json: open .dagger-cache/index.json: no...
What is the issue?
The link to #Scratch in this file is broken.
I can fix it, but should it be changed to 'https://github.com/dagger/dagger/blob/main/pkg/dagger.io/dagger/values.cue' or 'https://github.com/dagger/dagger/blob/v0.2.4/pkg/dagger.io/dagger/types.cue'?
Those are the files it is present in.
Signed-off-by: Helder Correia
Basically adding the official rust image to universe actions.
(I will sign the commits once I've squashed them).
Signed-off-by: Andre Passos
What is the issue?
When running dagger do on a directory with no actions it will crash the CLI with a seg vault.
Log output
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xfa7903]
goroutine 1 [running]:
go.dagger.io/dagger/plan.(*Action).FindByPath(0x12347c9, {{0xc0004e62c0, 0x1, 0x0}})
/home/kjuulh/git/github/kjuulh/dagger/plan/action.go:34 +0xa3
go.dagger.io/dagger/cmd/dagge...
What are you trying to do?
Several things:
- Test Dagger against custom builds of
buildkitd, including local changes needed for debugging issues (i.e. https://github.com/dagger/dagger/issues/449) - Test Dagger against different configurations of
buildkitdwithout having to impact my existingbuildkitdspun up automatically by Dagger. I.e. I might want to test against different executor backends (runc vs. containerd) or with an empty cache. - Test complicated workflows like st...
follow-up #2161
forgot to also filter out commandConn.CloseRead in previous PR: https://github.com/dagger/dagger-for-github/runs/6092884799?check_suite_focus=true#step:3:14
/opt/hostedtoolcache/dagger/0.2.7/x64/dagger do test
time="2022-04-20T10:01:52Z" level=warning msg="commandConn.CloseRead: commandconn: failed to wait: signal: terminated"
10:01AM INF actions.test.script._write | computing
10:01AM INF actions.test.image._dag."0"._op | computing
10:01AM INF actions...
What is the issue?
When exporting a file using the instructions in our docs, if the file is larger than 16 MB than you get an error.
As pointed out by @marcosnils, this appears to be a limit hardcoded by the Buildkit client here.
In general, while we could make that limit configurable, it's still problematic in that this approac...
What is the issue?
The handling-ouptuts only showcases how to handle text files through the contents: string CUE field. This has some limitations and could generate confusing errors. We should improve this guide and add a section about how to export binary data to the client FS following @jlongtine suggestion here https://github.com/dagger/dagger/issues/2248#issuecomment-1104474027
Closes #2168
Signed-off-by: Helder Correia
We need a deprecation policy for changes to CUE packages.
The idea is to avoid breaking configs as much as possible, so if there's something that can be done (like renaming fields, e.g., https://github.com/dagger/dagger/blob/main/pkg/dagger.io/dagger/compat.cue) to ease the transition then we should do it.
I'm thinking about adding attributes to fields (e.g., @deprecated()) so we can spit out warnings when loading the plan. I know attributes are frowned upon, but I think it's an ok us...
Changes
Resolves: #1951
- Add
#Kubectl - Add
#Apply - Add tests for both
Test
URL
dagger do -p ./apply.cue test apply url
[✔] [✔] actions.test.apply.url
[✔] actions.test.apply.url ...
I am sending you 1π! Pi is a new digital currency developed by Stanford PhDs, with over 33 million members worldwide. To claim your Pi, follow this link https://minepi.com/wuhh123 and use my username (wuhh123) as your invitation code.If 1Pi=100000$ today, how would you arrange your digital assets??
And I will not hesitate to use 20% to buy a car and a house, and then use 30 to invest, and the remaining 50% will continue to hold #PiNetwork until it is 10 times more and then make other plans.
What is the issue?
When a bash action fails, there is a chance dagger will wipe a bunch of files, including git related files, It usually renders the git repo unusable, requiring a clean clone.
The set of deleted files is not always the same and not always are files deleted. In the following screenshot I ran the action 3 times, but only the third time the files were deleted:
 could look something like:
$packageName = 'dagger'
$fileType = 'ps1'
$url = 'https://dl.dagger.io/dagger/install.ps1'
Install-ChocolateyP...
What are you trying to do?
When running dagger do in a terminal, the verbose usage output often will push the important information of what dagger actions are available off the screen. Some of the options displayed are experimental or will be seldom used. Those options should be revealed by running dagger do -h or dagger help do.
Example of desired behavior:
helloworld-dagger-jenkins ➤ dagger do git:main
Execute a dagger action.
...
Handles the action flags parsing separately so we don't have to call
Parse() multiple times on the main FlagSet as it has some issues with
StringArrays as described here https://github.com/spf13/pflag/issues/244
Signed-off-by: Marcos Lilljedahl
Bumps react from 17.0.2 to 18.0.0.
Release notes
Sourced from react's releases.
18.0.0 (March 29, 2022)
Below is a list of all new features, APIs, deprecations, and breaking changes.
Read React 18 release post and React 18 upgrade guide for more information.
New Features
React
useId is a new hook for generating unique IDs on both the client and server, while avoiding hydration mismatches. It is primarily useful for component lib...
Signed-off-by: Jeremy Adams
Quick fix for FAQ link URLs that currently have /faq in them, which is causing broken links. This commit removes that string in the URL.
Resolves #1351
Missing docs.
Signed-off-by: Helder Correia
This attempts to validate plan concreteness (e.g. missing fields) before
execution using some heuristics.
- Recursively walk the entire tree (avoiding definitions and optional
fields) - Scalars (string, bool, etc): Make sure they're concrete, or have
default values, or is a reference - Core types (FS, Secret, etc): Make sure they're references
- Core actions (e.g. core.#ReadFile): validate, but skip generated
fields
This is a simple fix for the issue of logs being duplicated when an
export is performed. The issue is caused by Buildkit's behavior of
"backfilling" newly connected clients on the progress so far of vertices
referenced by their build. This addresses it in the simplest way
possible by just filtering out progress log events from these separate
builds.
This works but is fragile. It works because we currently always set
Evaluate to true when running solves, which means that any progress ...
- Update Jenkinfile
- Embed youtube video tutorial
What is the issue?
Many users have difficulties to understand input and output concept and that lead them to issues they do not really understand.
We should write a page in core concept category to explain how you can link action together through input and output.
We should also explain when use docker.#Build and when not.
And also explain how create dependency between actions that not necessary has input field : link docker.#Push and docker.#Pull for instance.
Command added to Makefile + ci.cue to output last docs ID used. I got tired of searching it manually
Signed-off-by: guillaume
Doc explaining how to install/update dagger/external packages.
This is the first one of my serie on the subject. I reduced the scope to avoid losing people along the way.
Signed-off-by: guillaume
What is the issue?
The statement "You can extend your script by wrapping it, as-is, into a DAG. This allows you to start using Dagger right away, and worry about rewrites later." is interesting but there's nothing to back it up. I'm skeptical that wrapping a complex bash script as-is into a (single?) DAG would offer benefit but I'd value an example being included in you docs.
As a startup founder building a reasonably complex cloud-native app that's c...
@jpadams . Do you think it's possible to get a higher resolution on the YouTube video ? Right now we can't go up to 480p. Thanks
_Originally posted by @slumbering in https://github.com/dagger/dagger/issues/2268#issuecomment-1106140226_
Declaratively
You can do that declaratively already.
dagger.#Plan & {
client: {
filesystem: "./app.yaml": read: contents: string
}
actions: {
_params: #Parameters & yaml.Unmarshal(client.filesystem."./app.yaml".read.contents)
test: #Echo & {
input: _params.metadata.name
}
}
}
Full plan
package main
import (
"encoding/yaml"
"dagger.io/dagger"
"universe.dagger.io/alpine"
"universe.dagger.io/docker"
)
dagger.#Plan & ...
This allows project update to download .tar.gz modules from an HTTP server. The module name is derived from the host and path portions of the URL. The fragment portion of the URL is used to define the actual download path. For example, https://github.com/dagger/dagger#/archive/refs/tags/v0.2.7.tar.gz results in the github.com/dagger/dagger module name and https://github.com/dagger/dagger/archive/refs/tags/v0.2.7.tar.gz download URL.
Support for providing an authentication header ha...
What is the issue?
Currently content is centered around a helloworld plan, but heading on doc says that the CI-specific examples continue the local example of tododapp.
This exposes the LLB pull policy to core.#Pull. This allows the build script to explicitly indicate whether a new image should be downloaded. Only preferLocal is tested, as the other two options are not deterministic. Example:
core.#Pull & {
source: "myimage:latest"
resolveMode: "preferLocal"
}
The three options are default, preferLocal, and forcePull.
Signed-off-by: Jonathan Dickinson
Bumps google.golang.org/grpc from 1.45.0 to 1.46.0.
Release notes
Sourced from google.golang.org/grpc's releases.
Release 1.46.0
New Features
server: Support setting TCP_USER_TIMEOUT on grpc.Server connections using keepalive.ServerParameters.Time (#5219)
Special Thanks: @bonnefoa
client: perform graceful switching of LB policies in the ClientConn by default (#5285)
all: improve logging by including channelz identifier in log messages (#5192)
API Cha...
What is the issue?
Seems that dagger is crashing on dereferencing Secrets in certain cases.
Consider the below code example and stack trace.
It's my first day with dagger and I like it a lot so far :hear
Log output
panic: not properly initialized (state: unprocessed, value: )
goroutine 97 [running]:
cuelang.org/go/cue.makeValue(0xc000071f50, 0xc00338cb40, 0x0, 0xc002835200, 0x3, 0x3)
/home/runner/go/pkg/mod/github.com/dagger/cue@v0.4.1-rc.1.0.20220121023213-66...
What is the issue?
Add example with this change: https://github.com/dagger/dagger/pull/2122#event-6411429502
here: https://docs.dagger.io/1203/client#environment-variables
What is the issue?
Should we add this comment and update+do pattern to all CI examples as a best practice until more package/dependency management changes land?
https://github.com/dagger/dagger/blob/main/.github/workflows/todoapp.yml#L75-L78
What is the issue?
A dagger client running in parallel with another one (i.e. multiple invocations of dagger do that are talking to the same buildkitd at the same time) can see logs meant for the other client if the two share any LLB vertices with equal digests (which includes both the vertex itself and all its ancestors).
This is a bug in Buildkit where it deduplicates the execution of exactly equivalent vertices, but in doing so also deduplicates any metadata associated with those...
Bitbucket Pipelines - I have lots of clients using this
- The goal is to port the bats integration test suites to the current CI dagger plan
- Once this works and is reliable, the next step will be to not rely on
parallelanymore and let buildkit parallelize bats test suites
What is the issue?
When there is an entrypoint set on a base image, bash.#Run ends up with invalid arguments (bash cmd and arguments are appended to the existing entrypoint).
Instead it should always set an entrypoint to /bin/bash to work with all kind of base images.
Log output
No response
Steps to reproduce
No response
Dagger version
dagger 0.2.7 (18c19174) darwin/arm64
OS version
macOS 12.13.1
Bitbucket Pipeline docs say they do not allow privileged mode.
https://support.atlassian.com/bitbucket-cloud/docs/run-docker-commands-in-bitbucket-pipelines/
A potential workaround would be to use Bitbucket Runners and self-host the build machine, at which point you have total control over it, though you do lose the ephemeral aspect. I'm going to try that for some of our projects.
AWS CodeBuild/CodePipeline
This significantly reworks how modules are downloaded. There are now different strategies for downloading modules.
- Git: downloads with git and maintains the old behavior
- Github: downloads using a .tar.gz from github. The API is used to find the latest tag
- HTTP: Example,
https://github.com/dagger/dagger#/archive/refs/tags/v0.2.7.tar.gzresults in thegithub.com/dagger/daggermodule name andhttps://github.com/dagger/dagger/archive/refs/tags/v0.2.7.tar.gzdownload URL. Everythi...
This pull request fixes the contributing link in the README.md. The contributing guide has been moved to the documentation website by https://github.com/dagger/dagger/pull/2134
Signed-off-by: kevinpollet
Encounter this issue while building Dagger from source for our GitHub Action in https://github.com/dagger/dagger-for-github/pull/53
#10 8.698 go: downloading github.com/klauspost/compress v1.15.1
#10 8.699 go: downloading github.com/containerd/ttrpc v1.1.0
#10 9.890 go: missing Git command. See https://golang.org/s/gogetcmd
#10 9.891 error obtaining VCS status: exec: "git": executable file not found in $PATH
#10 9.891 Use -buildvcs=false to disable VCS stamping.
#10 ...
Resolves #2285
Signed-off-by: Vasek - Tom C
It was really painful to mount a simple file using type: fs because it creates some verbose intermediate step.
With this update, it is not possible to directly mount a file as string.
Signed-off-by: Vasek - Tom C
Signed-off-by: hardy4yooz
spike for #2163
Now will automate to fetch dependencies if not exists, like go did.
Now could show clear errors why contents is not set
11:20AM FTL system | failed to execute plan: task failed: actions.k3s.amd64._airgap._export._kubepkg_spec_json_file: kubepkg.json: WriteFile contents is not set:
actions.k3s.amd64._airgap._export.spec.spec.manifests.registry.deployments."container-registry".spec.template.spec.containers.0.image: invalid interpolation: unresolved disjunction "latest" | string | "93f3e3d" (type string):
components/kubepkg/registry.cue:43:21
...
support kustomize and apply resource.
What is the issue?
There is a problem with vars in docker mount.
The idea is that a split of variables in docker mount causes dagger do build to failed
$ cd doesnt-work
$ dagger do build
Log output
2:11PM FTL failed to execute plan: task failed: actions.build.container._exec: invalid secret at path "actions.build.container._exec.mounts.\"ssh Known Hosts\".contents": secret is not set
Steps to reproduce
$ cd doesnt-work
$ dagger do build
```...
What are you trying to do?
In https://github.com/dagger/dagger-for-github/pull/53 we discussed the option to have snapshot binaries so we avoid building Dagger from the source through a Dockerfile in the action which could potentially cause ecosystem fragmentation.
Why is this important to you?
For users that want to use bleeding edge Dagger features in their CI pipelines without having to wait for a release and/or fork the code themselves
How are you currently working aroun...
What is the issue?
https://github.com/dagger/dagger/pull/2261 broke flag validation for dagger do (while fixing another issue created by changing cobra flag parsing). We should work to enforce flag validation again.
Log output
No response
Steps to reproduce
No response
Dagger version
dagger 0.2.7
OS version
macOS 12.3
Summary
When specifying a plan (dagger -p) by its absolute path, I get an error instead of successfully loading the plan.
Details
What I did
This checks out the dagger source code (which contains a valid plan at the root) and tries to use it.
cd /tmp
git clone https://github.com/dagger/dagger
dagger -p /tmp/dagger do --help
What I expected to see
$ dagger do --help
Usage:
dagger do [flags]
Options
Available Actions:
version...
$ dagger do -p ./plan/do/do_flags.cue test --help
Usage:
dagger do [flags]
vs
$ dagger do -p ./plan/do/do_flags.cue test
failed to load plan: "actions.test.message" is not set:
./plan/do/do_flags.cue:21:3
./plan/do/do_flags.cue:25:4
Usage:
dagger do [flags]
Bumps cypress from 9.5.4 to 9.6.0.
Release notes
Sourced from cypress's releases.
9.6.0
Released 4/25/2022
Features:
Now you can easily test multi-domain workflows by using the experimental
cy.origin() command. This feature allows you to test
across different origins or domains within a single test. This experiment was
designed to work side-by-side with the cy.session()
experimental feature. You can turn on use of this command by setting the
experim...
Signed-off-by: Erik Sipsma
Without this change my PR CI runs are getting errors like these: https://github.com/dagger/dagger/runs/6164267748?check_suite_focus=true
Improve error messages when pointing to an invalid structure reference
Core actions cannot be nested under other core actions because of CUE flow limitations.
As an example:
actions: foo: core.#WriteFile & {
_xxx: core.#ReadFile & {
}
contents: _xxx.contents
}
In this case, actions.foo._xxx is nested under actions.foo and is silently ignored. The result will be a confusing non-concrete error contents: _xxx.contents (since _xxx.contents will never be filled by the runtime).
We should scan for nested tasks and fail with ...
Example:
dagger.#Plan & {
actions: _image: core.#Pull & {
source: "alpine"
}
actions: test: core.#Exec & {
input: actions._image
args: ["ls"]
}
}
Here I used actions._image instead of actions._image.output.
This is the error I received: failed to load plan: actions.test.input.$dagger: field not allowed: fs:
This is very confusing.
Related to #1426
Reverts dagger/dagger#2120
# 11:32PM FTL system | failed to execute plan: invalid reference format
This change replaces the use of @@- for tracking
which cue fields progress status updates from Buildkit should be logged
with. Now, the ProgressGroup metadata field is used to track the
component part (i.e. cue field) and the vertex name can just be the name
again.
This fixes the issue where Dockerfile builds showed up under the
"system" group. It also is more performant as statuses don't all need to
be parsed anymore.
The only exception that remains are the progress logs writte...
There was a typo in Sets env var on push to main on condition statement.
Branch was checked with github.base_ref == 'main' but the correct condition
was github.ref == 'refs/heads/main'
CI should no works on main and in PR
Related to: #2305
Tested on: https://github.com/TomChv/jsonrpc2/runs/6173846049?check_suite_focus=true
Signed-off-by: Vasek - Tom C
I hit this issue when I was manually testing #2294.
For more details, see : https://github.com/dagger/dagger/issues/1728#issuecomment-1109727011
By adding a condition when maxLines goes negative, I didn't hit that issue anymore.
Resolves: #1728
Signed-off-by: Vasek - Tom C
Revert #2289
To ignore an entrypoint from image config, just override with an empty entrypoint. Don’t move the command there.
Signed-off-by: Helder Correia
Related: https://github.com/dagger/dagger/issues/1371
Instead of extendings #Push, adding new task #PushManifestList for creating the manifest list
Refs:
What are you trying to do?
Speaking with @helderco he came up with the idea of having a convenience way yo reference the last action output from a docker.#Build steps since it's mostly likely that all docker.#Build actions are followed up by a #Subidr or #Readfile to validate or export contents out of it.
This also goes in line with some of the comments in #1993 and with other convenience features proposed like #1993
Example:
Replace this:
dagger.#Plan & {
cl...
This excludes build(deps-dev) in addition to build(deps) commits
from the changelog. deps-dev affect yarn (package.json) dev
dependencies (i.e. the docs website)
What is the issue?
feat: is not listed currently in commit message prefixes:
Add the following prefixes to your commit message to help trigger automated processes1:
docs:for documentation changes only (e.g.,docs: Fix typo in X);test:for changes to tests only (e.g.,test: Check if X does Y);
chore: general things that should be excluded (e.g.,chore: Clean up X);website: for the documentation ...
Bumps sass from 1.50.1 to 1.51.0.
Release notes
Sourced from sass's releases.
Dart Sass 1.51.0
To install Sass 1.51.0, download one of the packages below and add it to your PATH, or see the Sass website for full installation instructions.
Changes
Potentially breaking change: Change the order of maps returned by map.deep-merge() to match those returned by map.merge(). All keys that appeared in the first map will now be listed first in the same order...
seems aligned with
https://docs.dagger.io/1227/contributing/#3-update-your-pull-request-with-latest-changes
cc @aluzzardi @helderco @gerhard
[dagger/dagger] Issue opened: #2317 🐞 "client\.platform\.os" is not set when trying to run dagger do
What is the issue?
I have no made any changes to my project for a week and it seems something may have changed in the meanwhile. Where the pipeline was working before it fails with the same error both locally and in Github.
I have seen that there have been some changes to when the plan should abort here https://github.com/dagger/dagger/pull/2302, perhaps my plan should never have been working in the first place. If this is the case i'd appreciate some pointers in what i did wrong as ...
We've encountered a few issues with upstream CUE, and have some enhancements we'd like to help contribute, as well. This issue is intended to catalog, discuss, and suggest potential solutions for each of these.
Issues
- https://github.com/dagger/dagger/issues/2182
- https://github.com/cue-lang/cue/issues/1647
- https://github.com/dagger/dagger/issues/1867
Enhancements
Before this, a secret which ended up being set to an empty string would
still be "redacted" using strings.ReplaceAll, which has the (surprising)
behavior of putting the replacement chars around+between every char in
the string being replaced.
This meant that if you ended up with an empty secret, then all your logs
would look like this***.
This change just skips redacting if the string is "". I also considered
whether it should be an error for a secret to be an empty str...
Signed-off-by: Helder Correia
This is a workaround to prompt users to run project update when a version mismatch of stdlib/universe is detected.
The workaround should go entirely away once we have proper package management.
For now, this writes dagger's binary version inside cue.mod/pkg//version.txt whenever we dagger project update, and checks if the version matches upon dagger do.
Example:
$ dagger do test
5:06PM WRN system | A new version of package "dagger.io" is available, please run `dagger proj...
Revamp OpenTracing coverage in order to make it easier to troubleshoot performance issues.
late to the party, I tried to search around before commenting but haven't managed to find a confirmation one why or the other so:
since safety is an explict, important property shouldn't dagger encourage pinning to sha rather than tags? (git) tags are mutable and what commit they point to can be changed and if that's done by malicious actors we all know the results
Yes, absolutely. When I talk about version pinning I mean pinning by digest, for the reasons you mentioned.
great, the thought occurred to me while going through the docs and seeing:
# To pin external dependencies, you can use 'project update github.com/[package-source]@v[n]'
in the integrating with github actions example
Signed-off-by: Marco Abis
What is the issue?
You get unhelpful error messages for uninitialized state!
Log output
panic: not properly initialized (state: unprocessed, value: )
goroutine 88 [running]:
cuelang.org/go/cue.makeValue(0xc00007fea0, 0xc00127aa20, 0x0, 0xc000000a91, 0x70d88d, 0xc0010be6a0)
/home/runner/go/pkg/mod/github.com/dagger/cue@v0.4.1-rc.1.0.20220121023213-66df011a52c2/cue/types.go:668 +0x137
cuelang.org/go/cue.Value.LookupPath(0xc00007fea0, 0xc00104fcb0, 0x0, 0xc0010b...
we have a PR coming in the GA repo that allows building from source by pinning to a commit URL https://github.com/dagger/dagger-for-github/pull/53. Should be merged soon, we just need to refine some details there.
What is the issue?
What is the issue
I tried dagger locally.
I was following the CI/CD in your local dev and got the following error
failed to load plan: "client.env.APP_NAME" is not set
Usage:
dagger do [flags]
Flags:
--cache-from stringArray External cache sources (eg. user/app:cache, type=local,src=path/to/dir)
--cache-to stringArray Cache export destinations (eg. user/app:cache, type=local,dest=pa...
What are you trying to do?
Since we have some custom dagger logic to validate the plan correctness, just doing a simple cue eval might not be enough to make sure that our plans are correct. This helps in the case where you're refactoring things and making changes that don't actually require any action to be executed each time.
This would be analogous the compilation steps in compiled languages. In the context of developing my plan, I would probably want to just verify the plan an...
An experimental alternative to the official yarn package. This is based on my work spinning out and cleaning up our todoapp example. For now, that work is happening on a personal repo. This package is extracted from that repo, with some light clean up + tests.
I think a command to introspect the plan would be very useful (e.g. similar to terraform plan).
This would:
- Load and validate the plan
- Print the DAG and its dependencies
This would help:
- Navigating the plan:
dagger do --helpkinda does that, but it's one dimensional - Figure out action dependencies
- Potentially output different formats (e.g.
dotfile use with graphviz)
cc @dagger/maintainers thoughts?
Signed-off-by: Andrea Luzzardi
(work in progress)
dagger do build
[+] [+] actions.build.go.container [✔] actions.build.go.container 0.6s
[✔] client.platform 0.0s...
This adds a group counter used to mark log groups as completed.
The problem is when having actions.test._a and actions.test_b, as
soon as one completes it will mark the entire actions.test as
completed.
This can be repro'ed using our own CI (e.g. dagger do test)
What is the issue?
Not everyone will know that universe.dagger.io/x (in golang x way) means experimental pre-universe packages that are contributed by the community and not yet fully supported by Dagger as a universe package.
What is the issue?
Tutorial. How to turn a "makefile" into flat dagger plan and then refactor for reuse.
Show progression of simple translation, then go to progressively better structures for reuse/testability/etc.
Talk about tradeoffs involved in more abstraction. How to avoid pitfalls. Talk about user personas and how to create actions and plans that serve their needs: ops, devops, devs, app owners, etc.
What is the issue?
confusion today around core.#Source and client: filesystem for some users.
Can augment existing content and perhaps create blog.
https://docs.dagger.io/1222/core-actions-reference/#core-actions-related-to-filesystem-trees
https://github.com/dagger/dagger/blob/main/pkg/dagger.io/dagger/core/fs.cue#L7-L18
https://docs.dagger.io/1226/coding-style/#dont-inline-scripts
Before this change, we were using code from the buildx repo that
silently removed GHA from cache options if the GHA token and/or url were
not set. This made it very non-obvious that a mistake was being made,
with the only evidence being that cache import/export just never ran.
This commit updates to use the buildctl code for parsing cache options
(which is better since it is tied to the version of buildkit we are
using, unlike buildx). We need to layer the GHA token+url checks on top
...
After the changes introduced by sipsma in
https://github.com/dagger/dagger/commit/86e798a36bc93d19ac33631d0cb466ab771fa164
Dockerfile logs are now displaying correctly and don't require the
system hack. Additionally, I'm removing the CanTransition method and
going back to the previous behavior since it's not required anymore and
it also introduces a bug when displaying logs for actions that contain
hidden sub-actions.
follow-up https://github.com/dagger/dagger-for-github/pull/56#issuecomment-1111730526
cc @sipsma
Signed-off-by: CrazyMax
“system” fonts matches what the current OS uses, so it can be a comfortable look.
Reduce main container width to improve readability
Signed-off-by: user.email
What are you trying to do?
I'm testing out using Gitpod to write contributions for the Dagger repo, but the default Gitpod environment is general purpose and so isn't tailored for this specific repo. It would be useful to have a fixed Gitpod configuration for this repo for repeatable dev environments on any branch.
Why is this important to you?
I can easily work on this repo without having to make sure I have my dev environment set up correctly. Additionally every branch I work on ...
Instead of continuing with the now deprecated docsearch-scraper, we should instead migrate to DocSearch, as mentioned in this blog post: https://docusaurus.io/blog/2021/11/21/algolia-docsearch-migration
These are the next steps that I can see:
- [x] Apply for DocSearch → https://support.algolia.com/hc/en-us/requests/491210
- [x] Open a new PR which shows our DocSearch migration intent in our public
- [ ] Update support request with PR details
- [ ] ...
My expectation is that we will...
Signed-off-by: Berry Phillips
What are you trying to do?
We currently have a script that updates our dagger version in our docs instructions but it's not part of our release process. We should ideally try to make our docs depend on hardcoded versions as least as possible and, if not possible, make the release process update docs automatically.
Why is this important to you?
Currently we're having weekly releases and some docs get outdated and cause issues for new users since some instructions are still refer...
Another manual update until #2351 lands
Signed-off-by: Marcos Lilljedahl
Signed-off-by: Berry Phillips
Closes #2347
This environment includes all Gitpod supported languages and tools, as well as some additional terminal tools that are popular.
I went back and forth on using the full base image vs. the slimmer Go image. The full image contains all supported languages and tools - including Docker (see here) - whilst the Go image contains just Go. Using a custom Docker file to install Docker ...
If an error happened, the buildkitd logs could be helpful in debugging.
Signed-off-by: Erik Sipsma
Trying to debug the failed to execute plan: error detecting platform failed to list workers: Unavailable: connection closed before server preface received error we've been getting.
I'd like to run cue eval in a test.bats instead of dagger "do" ... since some universe.dagger.io/x packages need services that we don't run in CI (e.g. kubernetes). Thought that was a good suggestion from @marcosnils do cue eval check versus running 0 tests.
Signed-off-by: Jeremy Adams
Bumps go.opentelemetry.io/otel/sdk from 1.6.3 to 1.7.0.
Changelog
Sourced from go.opentelemetry.io/otel/sdk's changelog.
[1.7.0/0.30.0] - 2022-04-28
Added
Add the go.opentelemetry.io/otel/semconv/v1.8.0 package.
The package contains semantic conventions from the v1.8.0 version of the OpenTelemetry specification. (#2763)
Add the go.opentelemetry.io/otel/semconv/v1.9.0 package.
The package contains semantic conventions from the v1.9.0 ver...
Bumps go.opentelemetry.io/otel/trace from 1.6.3 to 1.7.0.
Changelog
Sourced from go.opentelemetry.io/otel/trace's changelog.
[1.7.0/0.30.0] - 2022-04-28
Added
Add the go.opentelemetry.io/otel/semconv/v1.8.0 package.
The package contains semantic conventions from the v1.8.0 version of the OpenTelemetry specification. (#2763)
Add the go.opentelemetry.io/otel/semconv/v1.9.0 package.
The package contains semantic conventions from the v1.9.0...
Bumps github.com/moby/buildkit from 0.10.1 to 0.10.2.
Release notes
Sourced from github.com/moby/buildkit's releases.
v0.10.2
https://hub.docker.com/r/moby/buildkit
Notable changes:
Fix possible corruption of records created by Merge and Diff steps after a daemon restart moby/buildkit#2796
Commits
9d2c9b2 Merge pull request #2829 from tonistiigi/merge-diff-restart-fix-v0.10
1b0cc23 cache: release parents if load fails
7c61efb cache: set all merge+di...
Bumps go.opentelemetry.io/otel from 1.6.3 to 1.7.0.
Changelog
Sourced from go.opentelemetry.io/otel's changelog.
[1.7.0/0.30.0] - 2022-04-28
Added
Add the go.opentelemetry.io/otel/semconv/v1.8.0 package.
The package contains semantic conventions from the v1.8.0 version of the OpenTelemetry specification. (#2763)
Add the go.opentelemetry.io/otel/semconv/v1.9.0 package.
The package contains semantic conventions from the v1.9.0 version of ...
Bumps go.opentelemetry.io/otel/exporters/jaeger from 1.6.3 to 1.7.0.
Changelog
Sourced from go.opentelemetry.io/otel/exporters/jaeger's changelog.
[1.7.0/0.30.0] - 2022-04-28
Added
Add the go.opentelemetry.io/otel/semconv/v1.8.0 package.
The package contains semantic conventions from the v1.8.0 version of the OpenTelemetry specification. (#2763)
Add the go.opentelemetry.io/otel/semconv/v1.9.0 package.
The package contains semantic conve...
Signed-off-by: Jeremy Adams
Problem
- Good:
dagger donow checks for missing values before running an action, which saves me time by catching errors early. - Bad:
dagger dochecks for missing values in all actions, even those I am not currently trying to run. This wastes my time, by forcing me to complete values that I don't care about.
Additional notes:
- Actions can leave incomplete values intentionally. Thanks to the missing value check, this becomes the equivalent of a mandatory command-line param...
Problem
When an action uses a client's environment variable as its default, then dagger do will incorrectly fail at the validation stage ("xyz not set").
NOTE:
- If the action references the client's env variable directly (not as a default value), then the problem does not occur
- If the action uses a default value other than the client env variable (ie. a string literal, or reference to a concrete string), then the problem does not occur
Details
What I did
1....
Argo stack (workflows, events and pipelines)
Bumps cross-fetch from 3.1.4 to 3.1.5.
Release notes
Sourced from cross-fetch's releases.
v3.1.5
What's Changed
chore: updated node-fetch version to 2.6.7 by @dlafreniere in lquixada/cross-fetch#124
New Contributors
@dlafreniere made their first contribution in lquixada/cross-fetch#124
Full Changelog: https://github.com/lquixada/cross-fetch/compare/v3.1.4...v3.1.5
Commits
c6089df chore(release): 3.1.5
a3b3a94 chore: updated node-fetch ver...
What is the issue?
We appear to be hitting some sort of limit/throttling with GHA as many PRs are getting timeouts while trying to export cache, especially when they are running in parallel with one another. This needs to be fully confirmed as the only error message we get is maximum timeout reached from this line, which is not especially descri...
On the Getting Started article CI/CD in your local dev, running the git clone command on Windows may yield a Permission denied error (it did for me). I appended a short note to the tip under that command telling the reader to run their terminal with elevated privileges.

to gather resources, invite people to join in and add their own
though it might be too soon in which case just reject the PR
Signed-off-by: Marco Abis
This will fetch the version from https://dl.dagger.io/dagger/latest_version and template it in all doc pages, on deploy.
Resolves https://github.com/dagger/dagger/issues/1854
Resolves https://github.com/dagger/dagger/issues/2205
Resolves https://github.com/dagger/dagger/issues/2351
[dagger/dagger] Pull request opened: #2370 feat: Allow marking \`client: env\` variables as optional
Why
A default empty string may not be enough if the variable can be defined but empty from the host. No option for secrets. This provides a solution to both.
This has been requested a few times.
What
Allow marking an environment variable from the host as optional.
How
client: env: REGISTRY_TOKEN?: dagger.#Secret
Example
dagger.#Plan & {
client: env: {
// load as a string, using a default if not defined
REGISTRY_USER: string | *"_token_...
Overview
In #2024 I pushed a temporary quick fix for #1867, this is an attempt to recover a proper type for that field.
Problem
The idea seems sound in CUE but it's not working in dagger. There's two issues at play here. Just as in the first iteration of #2024, this:
- Fixes #1867, e.g., when using CLI inputs or
--with - Breaks if not with empty disjunctions on the secrets
Test
Check the...
Signed-off-by: Andre Passos
@shykes I still need to write tests to this change. However a first feedback would be appreciated since I am moving the validation from the all plan to the action being executed.
Signed-off-by: wangwei
What are you trying to do?
From Discord about experimental Universe test
If we want people to use them, I think we should maintain awareness as to whether they are actually working. IMO we should enable tests and then if there's severe stability issues we could fallback to running the tests but making them only be advisory and not blocking merges. Just my two cents
The purpose is to split dagger universe test and experimental universe test into two jobs.
So tests will run as a...
Before this, there was a race condition where parallel dagger clients
could race while checking+starting buildkitd, which sometimes lead to
one removing the buildkitd container created by the other.
Now a lock file is used to ensure the process of checking+starting
buildkitd is transactional.
This doesn't fix the case where dockerd is remote and clients are
running on parallel machines, but that's more obscure and much tougher
to fix as dockerd doesn't appear to have any mechanisms...
What are you trying to do?
Ideally dagger can support secrets found in a secret manager, eg. GCP secret manager or AWS
Why is this important to you?
No response
How are you currently working around this?
No response
This packages is fairly similar in interface to the alpine package.
Some specific features of this over a standard ubuntu install:
- Configured to cache packages
- Stores apt cache in cache mounts
- For the purposes of installing packages specified, it undoes some of
the built-in apt configs that help keep the image smaller since these
are not needed when using cache mounts and messes up the cache. - Some optimizations so that
apt-get updateis only run when the apt
...
Inspired by yarn and npm.
What if, in addition to dagger do , we could also type dagger for actions that don't clash with built-in command names?
dagger do deploy --prod
dagger deploy --prod
The inspiration comes from yarn/npm which do the same:
yarn run build
yarn build ## build is actually not a yarn command
This would take one step further the "action inputs as flags" initiative: the entire command becomes user configurable.
The downside is clash with built-...
Hi,
Ive been working on some documentation as per my discussions in https://github.com/dagger/dagger/discussions/2085.
I wanted to put an unfinished version out to the community to make sure im on the right track and not going to spend a lot of time going in the wrong direction.
The problem im trying to solve with these docs:
- When I started using Dagger I found it easy to get up and running with the demo project. Then to move from there to converting my CI flows I found the docum...
What is the issue?
The dagger 0.2 docs have a section about handling secrets here: https://docs.dagger.io/1204/secrets. However, this page doesn't mention anything what using dagger.#Secret actually enables and what properties this entails.
Is my data encrypted?
How are secrets secure?
How can I guarantee that only specific actions can access secrets?
I think it'd be a good idea to provide a bit more in-depth detail about what secrets are and how Dagger handles them internally...
A basic AWS Codebuild was possible using a build task configured with the aws/codebuild/standard:5.0 image and the following Buildspec:
`version: 0.2
phases:
pre_build:
commands:
- pwd
- curl -L https://dl.dagger.io/dagger/install.sh | sh
- ls
- ./bin/dagger version
build:
commands:
- ./bin/dagger project init
- ./bin/dagger project update
- ./bin/dagger do build`
What is the issue?
When I run action with log-format plain, we get strange output (maybee bad encoding somewhere):
REPO_USERNAME= REPO_PASSWORD= OCP_USERNAME= OCP_PASSWORD= dagger do lint --log-format plain --no-cache
1:49PM INF actions.lint._dag."0"._dag."0"._op | computing
1:49PM INF client.filesystem."./".read | computing
1:49PM INF actions.lint._dag."0"._scripts | computing
1:49PM INF client.env | computing
1:49PM INF client.env | completed duration=0s
1:49PM INF a...
Resolves #1823
Resolves #2196
Why
The fact that you can't use a dynamic path in client: filesystem has come up a lot.
What
Allow overriding client: filesystem path in the action's field, using the CUE path as a default.
How
Simply using the CUE path as a default. Added a file lock to avoid race conditions to allow multiple actions to the same path.
Example:
client: {
env: KUBECONFIG: string
filesystem: kube: read: {
path: env.KUBECONFIG
co...
Problem
When a plan is split across multiple files, it fails incorrectly with input validation errors ("xxx not set"). The same plan, when combined into a single file, works fine.
Details
Dagger version
$ dagger version
dagger devel (ff0beef6) linux/amd64
What I did
- Setup a new project to reproduce
cd $(mktemp -d)
dagger project init
- Add repro config
cat > foo.cue < bar.cue <<-EOF
package main
import (
"dag...
On the Getting Started article CI/CD in your local dev, running the git clone command on Windows may yield a Permission denied error (it did for me). I appended a short note to the tip under that command telling the reader to run their terminal with elevated privileges.

Signed-off-by: Gyen Abubakar
From https://github.com/dagger/dagger/issues/1351, didn't rebase after https://github.com/dagger/dagger/pull/2321.
Signed-off-by: Helder Correia
What are you trying to do?
I want to enable use cases such as test runs to connect to a test database without requiring the user to know the IP of the running test database. They should be able to connect to it as a named service, such as test-db.
Why is this important to you?
It will ease the use of sidecar or other similar use cases.
How are you currently working around this?
No response
After #1510 I started including docs in feature PRs:
The problem is that you'll have new feature documentation published after merge, but the feature itself won't be available until the next release, unless you build from main locally.
We can just not include the new page in the sidebar, but sometimes we want to update an existing page. Example:
One possible soluti...
Doesn't allow to send unknown flags to do command.
Fixes #2297
Signed-off-by: Marcos Lilljedahl
Related to: #2313
Signed-off-by: Vasek - Tom C
Signed-off-by: Joel Longtine
Bumps @docusaurus/core from 2.0.0-beta.18 to 2.0.0-beta.19.
Release notes
Sourced from @docusaurus/core's releases.
2.0.0-beta.19 (2022-05-04)
:rocket: New Feature
docusaurus-theme-classic, docusaurus-theme-common
#7178 feat(theme-classic): extensible code block magic comment system (@Josh-Cena)
#7007 feat(theme-classic): code block showLineNumbers (@lex111)
#7012 feat(theme-classic): show blog sidebar on mobile (@...
What is the issue?
@sipsma recently merged (https://github.com/dagger/dagger/pull/2214) an initial implementation to allow Dagger to run async tasks which opens the door to do some very neat things like running DB's or any other type of dependency to run e2e pipelines in Dagger. This feature has some caveats mentioned in #1258 and #2389 that we should provide initial basic documentation to avoid unnecessary issues about things that we know we're working on. I guess the important thing to...
Creating this as an epic to track known limitations and possible improvements around the core.#Start features.
Known Issues:
- [ ] Explicit Dependencies
- Ordering tasks to run after an async exec starts is not robust. The trick used in the tests and my current use cases only works when adding creating a dependency ...
Speeds up CI considerably.
What is the issue?
I'm trying to delete a sub-directory by using core.#Copy, but it fails when marking the sub-directory as excluded.
Log output
9:14AM FTL failed to execute plan: task failed: actions.syncK8sRepo.copy: failed to copy file info: failed to chown /var/lib/buildkit/runc-overlayfs/snapshots/snapshots/48/fs/test-dir/another-dir: lchown /var/lib/buildkit/runc-overlayfs/snapshots/snapshots/48/fs/test-dir/another-dir: no such file or directory
Steps to repr...
Handles the website and rootfs separately to improve performance when
performing dagger do build
Closes #2399
Signed-off-by: Marcos Lilljedahl
Bumps @docusaurus/core from 2.0.0-beta.18 to 2.0.0-beta.20.
Release notes
Sourced from @docusaurus/core's releases.
2.0.0-beta.20 (2022-05-05)
:bug: Bug Fix
docusaurus
#7342 fix: avoid flash of page scrolling to top on refresh (@slorber)
#7329 fix(core): inject docusaurus version into SSR as local (@RDIL)
docusaurus-theme-classic
#7341 fix(theme-classic): properly highlight code block line numbers (@Josh-Cena)
...
Even though we export to GHA using per-test scopes, there are often
multiple invocations of dagger do within a single test, each of which
will use the same export target and thus overwrite each other's cache
manifests.
This meant that we would pay the price to export cache (quite expensive
for large blobs), eat up our bandwidth limit uploading that cache
(causing more throttles) and then never actually reuse the cache
because the manifest got overwritten.
For one example, the ./co...
What are you trying to do?
I want to set the hosts in a docker.#Run, but it is unfortunately not exposed because _exec is not mutable from the outside and therefore core.#Exec.hosts not editable.
Either delegate hosts from docker.#Run to _exec or make _exec publish and therefore accessible from outside. I personally prefer the second one to comply with CUE and make everything extendible.
Why is this important to you?
Realize commands like `docker run --add-host=host.docker...
A quick update for everyone since this was the most upvoted feature: we have prioritized work on this, development is underway :)
What are you trying to do?
Remove files, similar to how I can make files and dirs with core tasks. Rm is a supported FileOp type in Buildkit, so not much effort needed in Dagger.
Why is this important to you?
Users needed it here, had to resort to workaround (that turned out to have a buildkit bug anyways): https://github.com/dagger/dagger/issues/2401
How are you currently working around this?
No response
[dagger/dagger] Issue opened: #2409 ✨ Support for getting a \`Mount\` after execution of an \`Exec\`
What are you trying to do?
In Buildkit, you are able to mount a filesystem in an ExecOp, make changes to it in the exec and then get the new updated contents after the Exec (at which point it can be used as any other LLB state). E.g.
// mnt will have the contents of busybox plus /foo
mnt := llb.Image("alpine").Run(
llb.Shlex("touch /mnt/foo"),
llb.AddMount("/mnt", llb.Image("busybox")),
).GetMount("/mnt")
The same should be true of Dagger's core.Exec. FS m...



