#github-feed
1 messages ยท Page 20 of 1
What are you trying to do?
As an example, take a module I use for loading a container with NodeJS installed.
A bit simplified, it looks like this:
type Node struct {
// Version to use
Version string
}
func New(
// Version to use
version string,
) *Node {
return &Node{
Version: version,
}
}
// Returns a container with NodeJS installed
func (m *Node) NodeContainer() *da...
Outstanding! I see the number is down already - hope this helps others who had the same feel. Thank you.
I played with some tinygo.org a while back, and I wanted to use Dagger with it.
After talking with @sipsma , it seems it wasn't supported by buildkit.
I just add this issue here as I believe it is quite close to the #4675
Buildkit has support for attestations: https://github.com/moby/buildkit/blob/master/docs/attestations/README.md
But Dagger has not yet integrated that into our APIs.
Any implementation should integrate with environment Artifacts coming as part of Zenith.
One user requesting feature here: #1138842816219459695 message
Was mentioned by folks at KubeCon Chicago.
Ok so, I had some ideas related to this :tada: This is my proposal for what we should do with attestations in dagger - thoughts welcome :heart:
[!NOTE]
I think we should pretty much follow the in-toto spec: https://github.com/in-toto/attestation/blob/main/spec/README.md.
Buildkit implements attestations that follow this pretty closely, however, today it only produces statements (that contain predicates). We'd also want to upstream/wait for signing to be done, so we could use...
I'm in the same boat as @anoop2811, we would like to use Dagger for our pipelines, and having provenance generation built in would be a huge plus!
Hi, just curious if there is any movement or ETA on this. Was evaluating dagger for my team and we are very interested in a way to publish SBOMs and provenance.
What are you trying to do?
When working with build results and generating final build artifacts (packages), I often need to create directories and merge them.
In theory, this works using the following:
dag.Directory().WithDirectory("", dag.Directory())
I'm not entirely sure it always merges directories though.
In any case, a function called Merge would reflect better what it does (similarly to Diff)
Why is this important to you?
No response
How are ...
It would be great if dagger install always worked, no matter the current working directory:
| If... | Then... | Status |
|---|---|---|
| Workdir is inside a dagger module | Install into the current module | Implemented โ |
| Workdir is NOT inside a dagger module | Install into the home directory as if it were a module | Not yet implemented โ |
I propose implementing the second row: when calling dagger install outside a module, use the home directory as a pseudo-module instead....
Rather than putting it in $HOME/dagger.json and rely on find up, I think it's better to look for it in a "global" place like:
~/.config/dagger/dagger.json
Other than not polluting the home dir, I'm thinking what happens if you add a "source": ".". This would upload the entire $HOME directory to the engine. We can also forbid sources for this module.
One other feature I'm dying to have in this global module is global excludes, like git!
As part of #5583, I think we'll need some global state somewhere to track what compute drivers have been configured, and we'll need a place to put plugins.
I think it probably makes sense to use the XDG Base Directory Specification - this defaults to .config for config, .local/share for state (we can put downloaded plugins there). But then, users can also configure this to their preference.
Yes, XDG was what I basically alluded to. We already use it in our SDKs to know where to download the cli (automatic provisioning).
As discussed with @helderco yesterday. This is now a priority for the UX we want in the dagger shell: "always install a dependency before using it"
I've been trying to work around this by dropping a dagger.json at the root of my home directory, but I'm having trouble:
Error: failed to generate code: input: blob.diff.export resolve: failed to export: error from receiver: open /Users/shykes/.Trash: operation not permitted- Contents of my
dagger.jsongets randomly wiped by the Dagger CLI
Is there a way to have a reliable workaround?
What are you trying to do?
Dagger is really good at reading and executing Dockerfiles, but it would be really cool if you could generate a Dockerfile from Dagger as well.
Why is this important to you?
A few users have mentioned that rewriting their Dockerfile in Dagger (which is a good thing) has some downstream consequences. Most critically it breaks existing docker-compose setups.
How are you currently working around this?
No great workaround.
I remember i wrote it somewhere on my machine.๐
But some instructions are not supported by Dagger.
I remember i wrote it somewhere on my machine.๐
What do you mean by this? :)
A Dockerfile is often still necessary in certain cases, so this would be really cool.
I remember i wrote it somewhere on my machine.๐
What do you mean by this? :)
Sorry. I mean I writing a tool like this. But itโs translate from Dockerfile to Dagger. I think we might use graphql parser to translate back somehow.
I'm not sure how feasible this is. This would only really be possible for the most basic of dagger pipelines, but it's kind of unclear how this might work with modules/etc.
If we did decide to do this, the first step would be to remove all of our custom low-level buildkit parts, and either upstream these, or work out how to do without them. We have quite a lot of these, which allow us to do things that the buildkit runtime wouldn't normally let us do (custom sources, our own local ...
I'm not sure how feasible this is. This would only really be possible for the most basic of dagger pipelines, but it's kind of unclear how this might work with modules/etc.
If we did decide to do this, the first step would be to remove all of our custom low-level buildkit parts, and either upstream these, or work out how to do without them. We have quite a lot of these, which allow us to do things that the buildkit runtime wouldn't normally let us do (custom sources, our own local direct...
What are you trying to do?
Pass a duration value to a function using Go's native time.Duration type.
Why is this important to you?
Currently I have to use a string and manually parse it into duration which is cumbersome.
How are you currently working around this?
I use a string and manually parse it into duration.
Yeah you prompted me to start a spring cleaning :) It was long overdue. So thank you for the push.
+1 for this - the generated code creates an undefined Duration type. Not super urgent as we can pass and parse strings.
func (r ReadinessCheck) MarshalJSON() ([]byte, error) {
var concrete struct { ...
What are you trying to do?
Slurm is an HPC scheduler that is often used in large ML training jobs with hundreds or thousands of nodes. Slurm is deeply integrated with enroot as the container run-time and enroot uses squashfs.
Why is this important to you?
It would be great to generate the squashfs image directly and skip an in...
What are you trying to do?
I would like a way to express an explicit dependency in the DAG between two containers without necessarily passing an artifact between them. Today, containers can depend on services (WithServiceBinding) and they can depend on other containers with artifacts (create a file in container 1, then WithFile("/tmp/foo.txt", c1.File("/tmp/foo.txt")) in container 2) -- it'd be nice to not require the file.
Why is this important to you?
I have an integra...
What is the issue?
Add PHP-specific details to https://docs.dagger.io/api/daggerverse/
Right now, I do not believe daggerverse examples are supported by PHP SDK.
I will need to add support first, so I'll take this one and tackle both at once.๐
What is the issue?
There is a language-native PHP example on https://docs.dagger.io/api/http#language-native-http-clients, which demonstrates how to interact with Dagger using a PHP HTTP client.
This example was created before the PHP SDK existed.
The question is whether to retain or remove it.
Argument for retain: it provides an example of communicating with Dagger using a raw GraphQL client. This could be useful for users who don't want to use the PHP SDK, who don't want to use mod...
What is the issue?
Add missing documentation for the PHP SDK. Individual page requirements are described in linked sub-issues.
What is the issue?
If there are PHP-specific troubleshooting tips or errors to watch for, add them to https://docs.dagger.io/troubleshooting
What is the issue?
Add PHP code snippets to https://docs.dagger.io/integrations/google-cloud-run
What is the issue?
Add PHP code snippets to https://docs.dagger.io/api/terminal
What is the issue?
Add PHP code snippets to https://docs.dagger.io/api/state
What is the issue?
Add PHP code snippets to https://docs.dagger.io/api/secrets
What is the issue?
Add PHP code snippets to https://docs.dagger.io/api/interfaces
What is the issue?
Add PHP code snippets to https://docs.dagger.io/api/custom-types
What is the issue?
Add PHP code snippets to api/cache-volumes page: https://docs.dagger.io/api/cache-volumes
What is the issue?
Update the cookbook to include PHP snippets for all recipes: https://docs.dagger.io/cookbook
What is the issue?
Add an example of returning an array to https://docs.dagger.io/api/return-values/
If /etc/passwd and /etc/group are present, use them to lookup UID/GUI if chown is supplied a string rather than int.
Add a core function to search the contents of a file.
extend type File {
"Search the contents of the file"
search(
"The pattern to match the contents. Follows the Extended Regular Expression format"
pattern: String!,
"Number of matches to include"
n: Int,
): [Match!]!
}
type Match {
line: Int!
column: Int!
contents: String!
}
Dagger natively supports nesting (dagger in dagger). At the moment this is an opt-in feature (Container.withExec(experimentalPrivilegedNesting: true). This is as a precaution while we finalized the feature and made sure it's properly sandboxed.
Are we now able to say "mission accomplished" and turn it on by default? If not, what's the path to getting there?
Right now when an exec has nesting enabled the cache key for it includes the engine version, so it's cache invalidated when the engine version changes (i.e. an upgrade or a rebuild w/ changes when doing local dev on the engine).
IIRC the main motivation for having this caching behavior was our own integ tests (which make very heavy use of nested execs) and wanting the tests to be invalidated when we modified the code in the engine API. However, we could accomplish that for our own tests in a...
Outstanding! Since this is well-scoped and doesn't require any design bikeshedding, I'm marking it as a good first contribution.
SGTM I don't see any reasons why "not" doing this.
What are you trying to do?
I want to use the Java SDK to build pipelines with Kotlin script.
Why is this important to you?
Our whole Stack is Kotlin and we benefit fromm Extensions, so it's also our first choice for dagger.io.
How are you currently working around this?
we don't
@benkeil Just to let you know we are working on publishing the SDK to maven central.
Regarding Kotlin, this is working well (not the modules for now, just integration in Kotlin code).
Once libraries will be published we will also add some docs to use them with kotlin.
For instance this very basic code:
package com.mycompany.app
import io.dagger.client.Container
import io.dagger.client.Dagger.dag
import io.dagger.client.Directory
import io.dagger.client.ReturnType
import java.uti...
What are you trying to do?
according the guide to use podman you should symlink podman to docker.
it would be much better to allow to configure the "runtime" via config and/or environment variable. something like DAGGER_RUNTIME=/usr/bin/docker or DAGGER_RUNTIME=/usr/bin/podman
(btw the issue template is quite uncool for keyboard first persons if you have to jump between the three blocks "what are you trying to do", "why is this...
Thank your for all the context @c33s.
While I don't use Podman myself, I am wondering whether you could leverage DOCKER_HOST to point to e.g. unix:///run/user/1000/podman/podman.sock
With the help of direnv, the projects that need this combo could use e.g. export DOCKER_HOST=unix:///run/user/1000/podman/podman.sock . Using this config, Dagger would still use the docker CLI default for managing the Engine, but the docker CLI would be connecting to Podman instead of Docker...
What are you trying to do?
It would be nice to have a core function to get a tarball from a directory or a file
Methods api examples :
Directory.AsTarball()
File.AsTarball()
And eventually, the reverse functions, to get a directory from a tarball.
Why is this important to you?
We use a lot tarballs in our ci/cd pipelines and that make a lot of the same boilerplate to get what we need.
How are you currently working around this?
I use a basic alpine container, mount t...
I'd love for this. I'm running into the issue described here https://github.com/dagger/dagger/issues/6355 and this would be an excellent workaround.
We should also support unpacking files/directories as part of this.
[!NOTE]
Eliminating On-Prem Kubernetes Needs
This feature could potentially eliminate the need for Kubernetes (K8s) on-premises for companies looking to scale their DevOps engineering. By leveraging Dagger's distributed build system, teams could manage and scale their CI/CD pipelines more easily, reducing the overhead and complexity involved in maintaining an on-prem Kubernetes setup for build orchestration.
What are you trying to do?
We are looking to add support for distri...
For context, I'm one of those devs, and I think there are many of us out there, that almost never uses interactive repls or shells outside of my highly-customized zsh and the occaisonal database query webgui frontend.
I see the argument that folks are gonna write wrapper scripts for call regardless of SDK programmability, but is the idea here to build a featureful enough dagger shell that folks will be writing and committing dagger shell scripts as wrappers? a featureful enough shell th...
This is something that has come up quite a bit recently, mostly in the context of https://github.com/dagger/dagger/pull/8800#issuecomment-2479499749, but also around https://github.com/dagger/dagger/issues/8766#issuecomment-2474813161.
Even when we have a way to configure engine settings, there are a collection of user configurations that would make sense to apply per client-session, without requiring a whole engine reload. For example:
- Registry settings - today these are all only in ...
I suppose that this is where the user would reference the path to the mounting of the .gitconfig, for session-scoped git rewrite rules: https://github.com/dagger/dagger/issues/7787. Basically, the clean implementation to solve all those issues
I would love to just use the Client.connect function to specify engine specific stuff.
Dagger.connect(
workingDir = "../",
caCertificatePath = File("/path/to/my/ca-certificates"),
).use { client ->
...
}
or maybe even better
val caCertificates: List<File> = functionThatLoadsCertificates()
Dagger.connect(
workingDir = "../",
caCertificates = caCertificates),
).use { client ->
...
}
So I can get my certificates from somewhere (or what eve...
No disagreement on where we want the architecture to be eventually - but while we're not there, having the config fused together will be confusing - but I do think we can resolve that in docs.
If that is what we want, one fused file, some settings requiring a manual engine restart, and some not, then should we rename the existing engine.json to something else before we release, to avoid needing to rename it later on?
-
Agree we need a config file for Dagger that is environment specific, in other words: not
dagger.json, and not checked into the app repo. Somewhere in the home directory makes sense. -
Really not a fan of further splitting that into multiple files for multiple components, because: a) it's more concepts to learn for the user b) these concepts are mostly implementation details, c) the separation between components might actually move, eg. engine-wide config might shrink over time as we ...
I'm not sure I agree.
There are 3 very distinct "types" of config, written by different "personas":
- Module config. These settings belong only to the module, potentially #6323. The module author probably writes these.
- Engine config. These settings are tied to the lifetime of an engine, and aren't specific to a user (in the case of a shared engine). Things like garbage collection, or security configuration, etc) - when these are changed, the entire behavior of the engine can change (an...
Module config
- Module config. These settings belong only to the module, potentially A config file for my modulesย #6323. The module author probably writes these.
I'm torn on this part because it's got a foot in each world:
- One the one hand it's directly linked to module schemas... So if it's kept in the home directory it might get out of sync with the modules it's targeting
- At the same time, it's specifically meant to be envir...
It would be nice to have a core function to append to an existing file.
DagOp should help make this possible to implement when it lands: https://github.com/dagger/dagger/pull/9395
Since there's no LLB op to append to a file, we can't currently do this - but with DagOp, we'll just be able to implement it without that.
:tada: yeah, agreed :) It would be fairly easy to have this as a core api method, something like File.append.
Problem
One benefit of dagger shell is that it could potentially match the convenience of bash scripts. ๐ One drawback is that it could potentially match the portability of bash scripts ๐
Since the shell interprets scripts in the CLI, it gets its own sandbox, separate from module runtimes. This is an opportunity to design the sandbox for the ideal balance of portability and convenience.
Solution
We are still searching for the ideal balance of portability and conveni...
FYI @aluzzardi @jedevc @sipsma and anyone who might be interested in this topic
@idlsoft I think the bash syntax is a good way to enforce that host-side is for the last mile, and if your scripts start growing too large, it's time to move them to code in a regular sandboxed function - which means that has to be a good experience, too.
The second you want your host-side script to be callable by another script (something which is implied with "host-side scripts" and a more structured language like starlark), then you're on the wrong track.
To address your specific use...
host-side scripting is exactly what I'm missing in my setup.
I currently use bash scripts to prepend initialization functions to a dagger call, but this is very limited.
Ideally I'd like to be able to define "host-side" functions, that glue things together.
For example, a dev-generate function that drops generated sources to local directories, or a docker-build function that exports a docker container to the local engine.
It may be a bit much to do that with a bash-like shell though, ...
The second you want your host-side script to be callable by another script (something which is implied with "host-side scripts" and a more structured language like starlark), then you're on the wrong track.
Not exactly what I had in mind, but I get that this may be well outside the scope here.
I have a bunch of projects, different languages, but all of them should be able to do build, test, lint.
If certain env variables are defined, also deploy.
A "host side" skylark scri...
What are you trying to do?
I'm writing some tests that require the IP addresses of Services. Unfortunately I can't use hostnames as it's for a bespoke load balancing configuration that requires IP addresses.
If using testcontainers-go this is a simple call on a container which provides you with the IP address. Following this idea would be incredibly useful as it avoids the need to either manually manage the lifecycle of a Service or bind containers to it to obtain this information ...
What are you trying to do?
Today, Dagger enforces "some" validation rules on function parameters. For example, there is a way to define enums and enforce that a parameter passed to a function is a valid enum.
However, there are way more cases where validating input values would make sense and better support built into the SDKs would make module code more concise and easier to read.
Some examples:
- version number
- enums that are hard to represent as enums right now (eg. a limi...
cc @shykes @helderco wdyt? I quite like this, feels like a pretty easy way to improve module readability.
Personally, I like the validation interface better. The pragma may be more universal across different SDKs on the surface, but the accepted values there may not be that easy unify.
For example, some Go validation libraries support struct tag based validation (which is similar) and uses a language like this: notNull,mandatory,constraints:[StringNoControlCharacters{},StringLength{Minimum: 1, Maximum: 255}]
Supporting only regex can quickly become uncomfortable, implementing a more sophi...
Just going to add some comments here as I was going to post this feature request this morning as I was working on a module and needed validation.
// version must be a valid PHP version
switch version {
case "8.2", "8.3", "8.4":
default:
return nil, errors.New("invalid PHP version")
}
Having syntax that supported validation inline would be immensely useful for module developers.
I've used a few validation libraries and packages but the one syntax that I...
What is the issue?
add doc example for https://github.com/woodpecker-ci/woodpecker
What are you trying to do?
With the introduction of modules, developers can now reuse pieces of code for building their workflows, either built by them or other developers.
I mostly used my own modules so far, so adding new features or debugging module functionality wasn't particularly difficult.
When it comes to tinkering with third-party modules, especially for someone who isn't very familiar with how modules work, this may be more difficult.
This is how you do it today:
- ...
That would be quite handy! Iโd like to add that vendor would probably be the best name for this command, as it's a commonly used term for including third-party dependencies directly in the codebase. Mimicking the replace directive from go.mod would be familiar to Go developers, but it would need to be adjusted for the JSON format.
The vendor command could pull in specified dependencies and automatically add a replacement field in dagger.json for each dependency, like so:
Directory.glob() should be callable without arguments. The intuitive default for pattern is **, which will match everything.
Making it optional means that the standard way of calling it would now require an opts struct - given that's probably the general case, I think it makes more sense to optimize that case for simplicity.
(note, this would also be a breaking change)
Making it optional means that the standard way of calling it would now require an opts struct
Only in Go :)
(note, this would also be a breaking change)
Only in Go :)
Suppose the following scenario:
// module foo
func (f *Foo) DoFoo(
// +optional
// +default=true
arg bool,
// +optional
arg2 string,
} error {
// ...
}
// module bar
func (f *Bar) DoBar() error {
return dag.Foo().DoFoo(dagger.FooDoFooOpts{Arg: false})
}
As described in https://github.com/dagger/dagger/issues/7777#issuecomment-2203387161, this false won't apply, and we'll get the default true value set for arg.
That's because of the ...
Yeah, this is kinda weird - pointers let the callee handle this, but there's no way for the caller to handle it.
I can't call DoFoo from another Go module to get a false arg (no matter how it's been declared) - at the moment at least.
Is this problem present with pointers as well?
Woops, there is another way to handle this with pointers, edited to add this to the list of potential solutions.
Ooh, I like the arg chaining a lot, definitely way less verbose, and we don't need to do the messing around with interfaces. If we want to keep backwards compat, we can't quite have those names, we'd have to have WithArg or similar.
I think the FooDoFooOpts structs would just look like this then:
type FooDoFooOpts struct {
Arg bool
Arg2 string
// we can use these set booleans to check if it was explicitly set
// otherwise we fallback to querybuilder.IsZeroValue
...
I think this version is less verbose:
dag.Foo().DoFoo(dagger.FooDoFooOpts().Arg2("hello").Arg(false))
Which would still allow this:
dag.Foo().DoFoo(dagger.FooDoFooOpts().Arg2("hello"), dagger.FooDoFooOpts().Arg(false))
Probably not used inline like that, but saved into vars and composed.
Incredible that I didn't realize this was a limitation. Would have led to big confusion. I am closely watching this as not having default true booleans would be bad for multiple reasons!
I like the chaining method if that's what you decide to go with and this will need to be well documented.
Can I suggest an option that may seem weird, but could have some potential? I call it "goofy/regular".
TLDR: introduce an alternative calling convention with a different DX and more features. The two conventions would co-exist, preventing any breaking changes.
- Regular convention: same as today.
- Goofy convention: encode the call in a single object, then make the call with
Callxxx.
Benefits
- A clean DX for explicitly setting and getting optional arguments
- No breakin...
We discussed in discord, but summarizing my thoughts on the goofy calling convention (for the record):
- I agree on the callee example - this would be very useful in lots of places, like our
ghamodule. No notes, let's do it :tada: - For the caller example:
- Setting required args through
.Setmethods has a few down-sides: it's now possible to accidental omit a required arg (the type checker can't catch this, and instead we get a runtime error), it's entirely different from every ...
- Setting required args through
Any traction on this? I ran into this again today and it wasn't a pleasant experience. To find details about it I had to search Discord. Would it make sense to document here until we arrive at a conclusion? https://docs.dagger.io/api/arguments/#optional-arguments
Just a simple question from a newbie here.
So is there no current workaround for having a default value of true? I'm not meaning to be a smarty-pants, but given none of this is documented (you guys really need to document this) I don't think I have any other easy way to find this out without just asking this question.
There are definitely multiple people in our company that have been directly impacted by this (just in case you need more evidence that this is an important issue.)
I agree. It's so easy to hit, I've done it multiple times myself without realizing.
I just learning dagger and I just ran into this as well. It was not obvious what the failure was and got lucky I knew @nipuna-perera who had already run into this. Otherwise I would be scratching my head.
Problem
As mentioned by @kjuulh and others, modules are powerful, but they have a steep learning curve. Going "from zero to first module" is major source of friction for adopting Dagger.
Solution
One possible solution: introduce the concept of single-file modules.
| Before | After |
|---|---|
dagger init --sdk=foo creates a dagger.json + a complete boilerplate source directory |
dagger init --sdk=foo creates a dagger.json+ a single boilerplate source file |
| ... |
maybe this solution will solve your problem link
An isolated comment on this bit:
I think in practice, that requires containerizing the dev environment, and managing it in Dagger. IDE integration would then involve a devcontainer bridge, or equivalent. That makes IDE integration harder to ship, but we will need to cross that bridge eventually: the tech industry is already gravitating towards containerized dev environments, it's kind of silly that one of the most advanced container-based platforms out there, has no plan for that - not on...
I agree, the learning curve for dagger adoption is a bit more than it looks at the surface.
I do have a comment in the direction of doing two things/having two things pursuing the same goal.
From my experience with other tools in that space, e.b. GH Action, GitLabCI, both offer different ways to construct a workflow file. While both files end up doing the same thing, one looks entirely different from the other.
One is definitely smaller and nicer. However, and here is my big pay...
Speaking from the POV of Python modules here.
I think we should address the fact that our current IDE support is already not great, and we don't have a clear plan for addressing that. In fact, I don't think we even have a clear consensus on how we want to integrate with IDEs.
My approach has been to make modules normal Python packages, using conventions and standards as much as possible. I think this has the best chance of working as expected in several IDEs, without much effort...
Beyond any implementation details, could we consider dagger.json + <other file> - we could merge it all together:
// main.dagger.go
package main
// we could have a custom dagger block somewhere in the file, this could be language specific
dagger (
name "my-module"
engineVersion "v0.13.6"
dependency (
name "hello"
source "github.com/shykes/hello"
)
)
// the my module as normal
type MyModule struct {}
type (m *MyModule) Hello(ctx context.Context) (st...
Seamless IDE integration
I think that to make single-file modules a viable option as the default, while we don't need to be seamless, I think we should aim to be at near as good as a standard setup today. Otherwise, I suspect most users would quickly bail out. That said, if we had this, I would switch over to this instantly, I would love to be rid of the clutter we currently have.
From my memory, IDE integration these days tends to involve:
- Some syntax highlighting work (using ...
@jedevc would it be viable in the future, for each SDK to embed a custom language server? Then you could configure your IDE to call that. It would remove one load-bearing wall in this conversation: the need for checked-out files to match perfectly what a vanilla language server expects, always and without exception.
My approach has been to make modules normal Python packages, using conventions and standards as much as possible. I think this has the best chance of working as expected in several IDEs, without much effort from us. At least the Python SDK doesnโt cater to any one IDE specifically. And it doesnโt need to.
Whatever the reason, our users often complain about issues between their modules and their IDE. I'm not judging whether it's the best it can be - I'm just saying it's objectively a ...
would it be viable in the future, for each SDK to embed a custom language server? Then you could configure your IDE to call that.
Viable, yeah. Whether they're distributed as distinct components, or bundled into an SDK as a
dagger.Servicedoesn't hugely matter IMO. Not to trivialize the distribution part of this, but it's definitely the easiest bit, the actual language server bits are gonna be the heavy bits.
I agree, I was thinking more of the "actual language server bits" ...
What are you trying to do?
just wanted to calculate the size of the files in a Container().Directory() with a combination of Directory().Entries() and File().SIze(), but calling Size on every File that is a symlink returns the size of the linked file.
would like to return the actual size on the filesystem of the symlink entry instead.
Why is this important to you?
had an idea to find the largest directories/files embedded in an image, a la the dive utility but simpler
How a...
Good thing we have Astral ๐ This is where the Python SDK strikes a balance. It only supports the uv package manager (uv.lock). uv is pretty great, we donโt need to support more. If youโre on a system without any Python tooling, all you need is to download this single binary once, and run uv run vim in your module to set it all up for you and get code completions.
This is a crutch. I shouldn't have to install anything on my machine to develop a Dagger module, other than Dagger.
+1....
Ah my bad, there's no sync in the language server protocol. I guess that rules out running it in an entirely separate container, some component of the LSP server will need to run on the host next to the editor.
But we can still do this: the language server just accesses the local files on the host, and can create "virtual files" in /tmp to jump to - all the generated files are still hidden from the user's current directory. This is sort of how go's LSP allows you to jump to definitions in th...
Problem
I can't pass a module as argument to a function. This prevents a whole class of use cases that require one module dynamically loading another. For example, the "platform module":
- 100 different applications each have a Dagger module. They all implement the same interface:
Build(),Test() - 1 module defines an
Appinterface which includesBuildandTest; and it implements a reusableDeploymethod which takes an array of theApps. - App teams can call the platf...
Is it possible to pass any Dagger object other than the special cases like Directory as arguments in the CLI right now? I've wanted to do
x = dagger core container from --address=something/distroless directory --path=/
dagger --interactive core container from --address=fedora with-directory --path=/inspect --directory=$x terminal
But couldn't find a way to do it mentioned in the documentation. And I tried using from-id but the id expires by the time the next command runs.
Maybe...
This kind of thing is basically what we (nine) are doing right now using dagger shell. Our setup is we are constructing "dependencies" of our "main" dagger module in dagger shell, then passing those dependencies into the main module. The main module accepts the dependencies by interface.
An example of one of the dependencies we have is an AWS module that provides access to aws resources. We construct it in dagger shell to abstract away the differences per environment ( where our dagger func...
@M-Pixel yeah the dagger shell is meant to make this kind of composition easier.
Your example in dagger shell:
x=$(container | from something/distroless)
container | from fedora | with-directory /inspect $x | terminal
What are you trying to do?
Almost every pipeline has WithMountedDirectory().WithWorkdir(). It would be nice to have some sugar to do this in one call with something like WithMountedWorkdir()
The name probably needs some more thought because it could cause confusion between WithDirectory/WithMountedDirectory vs WithWordir != WithMountedWorkdir
Why is this important to you?
No response
How are you currently working around this?
No response
An optional parameter for WithMountedDirectory like workdir bool could work too. The DX in python and typescript would be fine. The DX in go would be worse than the current state though
What would WithMountedWorkdir do exactly? I just use WithMountedDirectory("."), doesn't that achieve the same result?
What would
WithMountedWorkdirdo exactly? I just useWithMountedDirectory("."), doesn't that achieve the same result?
It's a convenience helper for WithMountedDirectory().WithWorkdir() as it's generally what you end up doing in most cases.
I think instead of WithMountedDirectory("/foo").WithWorkdir("/foo") we should recommend WithWorkdir("/foo").WithMountedDirectory("."). It achieves the same result I believe (avoid awkward repetition of /foo) without further complicating our filesystem API. I think WithDirectory vs WithMountedDirectory is already too complex for most users, adding more complexity in that area is really best avoided unless absolutely necessary IMO.
we should recommend
WithWorkdir("/foo").WithMountedDirectory("."). It achieves the same result I believe
yes, this also works.
adding more complexity in that area is really best avoided unless absolutely necessary IMO.
I wasn't necessarily looking at this from the complexity perspective but more like a shorthand since I've found myself writing WithMountedCache().WithWorkdir() pretty much every time. I guess it's the same reason I also value Golang's stdlib shorthands like `...
While I understand the argument from @shykes, this does bring back some PTSD from the Docker CLI days: -v .:/foo -w /foo.
WithWorkdir("/foo").WithMountedDirectory(".") is somewhat better.
(/me looking through all my modules to make sure I remove repetitions)
Yeah exactly @marcosnils , the motivation is to just type less. WithWorkdir() is almost always called with WithMountedDirectory() and this happens in almost every pipeline
+1 on WithMountedWorkdir
What are you trying to do?
The TUI buries a lot of warnings and messages by collapsing at the end, sometimes you need to communicate something to the user that is durable after a pipeline ends.
Why is this important to you?
For example: you might be telling folks that they need to update their module versions or that there is a next step needed.
Could be implemented by priority on custom OTEL spans, perhaps.
How are you currently working around this?
cc @vmaffet-fast @...
Reported by user in [Discord](#1295320684658036767 message).
The API has the following description on Directory.export:
Writes the contents of the directory to a path on the host.
This is misleading because when using a Dagger module, the directory is exported to the runtime container, not necessarily what you'd interpret as the "host". We should clarify this, but ...
Problem
We don't clearly answer the question: should we optimize for the best DX, or for flexibility?
-
Best DX: one package manager, one runtime, one way to organize your files. Probably customizable, but not infinitely so. Probably easier to learn, easier to develop, and faster. But won't "blend in" with the surrounding project; and maybe harder to import code from app into the module or vice-versa
-
Flexibility: adapt to your existing package manager, runtime, and layout as much as p...
@shykes
Best DX: one package manager, one runtime, one way to organize your files. Probably customizable, but not infinitely so. Probably easier to learn, easier to develop, and faster. But won't "blend in" with the surrounding project; and maybe harder to import code from app into the module or vice-versa
I personnally prefer this option since we can really focus on making the best out of our choice of runtime, configuration etc...
We can make our choice based on few points like sp...
@TomChv -
This is valid if we choose to adopt Node as runtime, but what if we choose Bun? Or Deno?
"what if we dropped Node in favor of Bun since Bun is waaay faster than Node in our benchmark" (Bun initialization is always <10s while Node is >15 uncached).
What is being done at initialization? I mean, is transpilation and type checking happening? I guess I need to work with the TypeScript SDK. ๐
Totally agree with you on that, do you have a suggestion of what time per run...
In terms of the package managers, it depends on how strict you want to be with where dagger modules live. If you go down the road of only supporting bun (for instance), you will pretty much requiring people to have a separate repo for their dagger modules, as it would likely clash with any monorepo setup.
But the dagger module is supposed to be in a different directory of your monorepo and ignore by the root tsconfig so it shouldn't clash.
Those are slightly different goals based on...
I agree that the two options aren't quite mutually exclusive, but it is a bit of a balancing act.
I'm not sure being more flexible would impact the learning curve but it would definitely make the path less straight forward and harder to make it work. You'll have to check the docs to see how to make the runtime using your specific package manager, because the they're more possibilities, you can get lost for a while, hitting strange dependency issues that could be avoided...
Personall...
So let me pose a question: How often do you experience that value?
I'd say this value can be experienced only when the CI takes so long it makes sense to endure the pain of dagger setup and runtime to run a small set of failing pipeline locally or avoid initial setup cost. Because any CI tool will always be slower than just running without a tool.
So CI tool should balance laziness and impatience. Should be easier than setting up and maintaining a local environment. Should be fast enough ...
I'm not seeing how the one should be exclusive to the other.
So, here is my 2 cents.
For sure the most used package managers should be supported. npm, yarn, pnpm. If only one has to be picked, it should be pnpm IMHO. I'm not seeing the reasons why choice of package manager can be problematic though either. ๐ค
I wouldn't say customizability is necessary per se. But, extensibility is for sure. But, I understand it is hard for SDKs like Dagger offers. I'm also wondering what customiz...
What are you trying to do?
Currently the typescript sdk installs itself as a folder within the project and has its own package.json and lock file.
This makes things a little tricky to work around since there are now two separate places that try to manage the dependencies. This is especially true since the dagger code references the sdk.
Why is this important to you?
The 'normal' way for these types of dependencies are for it to be installed via a package manager and live within...
There are two unique parts. One is the SDK itself, and the other is the code-gen part.
Those could be split up. Some libraries that rely heavily on code-gen, like prisma, do this in order to keep a separation between the 'library' and the 'generated code'
That's actually a good idea, we might be able to split codegen & the SDK library, we would need 2 different important path though like
import { Container } from "@dagger.io/sdk" // Generated code
import { object, fun...
The way that prisma does it (and there are other ways), is that it has its static library as @prisma/client. Internally it references .prisma/client which is the pre-generated code that lives in node_modules.
This allows the user to import @prisma/client and have everything typed and working properly with their generated code.
The gritty details look something like
@prisma/client
exports:
.: require('.prisma/client')
./runtime: // static code
.prisma/clie...
Currently the typescript sdk installs itself as a folder within the project and has its own package.json and lock file.
This makes things a little tricky to work around since there are now two separate places that try to manage the dependencies. This is especially true since the dagger code references the sdk.
We installed the SDK as a local dependency because the SDK itself is bundled inside the Dagger binary.
We could do it differently but that means you cannot use the SDK as local...
Assumption Note:
This comment assumes that the code for a generated module is only needed in the engine.
Another thing that may work. Since you only really need the types for development, the 'client gen' could just spit out a .d.ts file that extends the dagger types (and creates new ones).
That file could then just be gitignored.
(Take this all with a grain of salt, since I haven't looked too deeply on how things are constructed internally)
We installed the SDK as a local dependency because the SDK itself is bundled inside the
Dagger binary.
That is the main part that I'm wondering about
We could do it differently but that means you cannot use the SDK as local dep... or we would need 2 different runtime, 1 local and 1 remote
There are two unique parts. One is the SDK itself, and the other is the cod...
Iโve considered something similar for Python actually, but not exactly as suggested.
Letโs look at what makes up an SDK client library:
- The client bindings
- The client code that lives between the bindings and the communications with the API server, including a very simple connection logic based on only two env variables (session token and port)
- Code for supporting modules (introspection and registration, deserialization and serialization, validation and dynamic execution or dispatc...
First, thanks for the great write up. I'll go through this from top to bottom first, then have more freeform comments below. I also want to point out that I only have knowledge/experience of using the dagger cli with modules, so I can't really comment on cases that fall outside of that
Initial reactions / comments
Now youโre just left with the generated client bindings and the underlying code that knows how to talk to the API. I actually think this is all that should be published to...
Now youโre just left with the generated client bindings and the underlying code that knows how to talk to the API. I actually think this is all that should be published to the public package registry.
What are the
generated client bindingshere? I read that as it is the stuff that is generated from my 'client' module, although I'm most likely mistaken on this.
See this:
Basically the โclient bindingsโ is what codegen generat...
I just created https://github.com/dagger/dagger/issues/8722 for the issue where I can't run dagger call locally. This is mainly caused by the fact that there are two separate package managers at play here. This is a similar issue that would play out in a monorepo
Related to that issue: https://github.com/dagger/dagger/pull/9531.
If extended to module's client gen, this would use the published library :)
Still a draft but it will solve that issue: https://github.com/dagger/dagger/pull/10846
This is important to me as an ops person because often the software I need to build comes with a Dockerfile that I do not control. Even if this is a Docker anti-pattern, Dagger should support it because it's a sharp edge for users:
even if I export-image, I can't use it in a build.
What are you trying to do?
it would be great to view all of a user's modules from something like https://daggerverse.dev/mod/github.com/levlaz/daggerverse (i.e. removing the module name from the URL to get to an index, similar to how you can do this on github)
Further, a github user's path would be good too if the user doesn't use a daggerverse repo. So https://daggerverse.dev/mod/github.com/levlaz
Why is this important to you?
No response
How are you currently worki...
Since a given author might have modules in many git repos in many git servers under different user/org names, it's an interesting question of "who is a user" (since we don't have a Daggerverse login today).
You can make a search today that might accidentally work like:
lev1 OR lev2
real example: https://daggerverse.dev/search?q=jpadams+OR+levlaz
It could make sense to allow search by git username/orgname through something like:
git-org:levlaz
What are you trying to do?
Expanding on https://github.com/dagger/dagger/issues/6605 which addresses the case for a dagger update command.
However, currently dependencies in dagger.json work more as a lock file - any kind of dagger install will be stored as the resolved ref. This makes it a bit hard to reason about dependencies and update them safely, etc.
It would be nice to have a way to declaratively pin the dependencies to a human-friendly ref and/or ideally a semver ex...
x-linking to https://github.com/dagger/dagger/issues/7898, which is gonna be resolved by https://github.com/dagger/dagger/pull/8587.
I think this is a step torwards dagger upgrade but not fully there.
Does the proposed changes to the syntax of dagger.json make sense to you? With source capturing the original from dagger install, and pin labelling the exact commit that we used.
Yeah I believe that should cover it pretty well (minus the ability to not commit the pin/lock versions, which I personally don't need). I like the idea of the combined source+pin string, it's probably simpler / better UX than having to know the difference between requirements and pinned dependencies, etc ๐
Problem
The current services API on allows 1-to-1, one-way service dependencies. The following topologies are not allowed:
- Service A needs to connect to B, and vice-versa
- Service A, B, C all need to connect to each other. Similar to how Docker-compose networks work out of the box.
Solution
Expand the Dagger API to support a wider variety of network topologies, without losing the benefits of the current design.
:wave: adding an update here to share that #8641 already allows this in a simplified way.
Summary
Make include/exclude patterns dagger.json relative to the context directory if they start with a slash (/).
Motivation
The include and exclude patterns in a dagger.json are always relative to the dagger.json file.
But with the recent Context directory feature, module authors are able to specify a path that is either relative to the root directory, or absolute to the context directory.
Example for a `f...
Summary
Create custom enumerations the same way theyโre generated by codegen.
Motivation
Python enumerations are generated like this:
from dagger.client.base import Enum
class Severity(Enum):
"""Vulnerability severity levels"""
UNKNOWN = "UNKNOWN"
"""Undetermined risk; analyze further"""
LOW = "LOW"
"""Minimal risk; routine fix"""
MEDIUM = "MEDIUM"
"""Moderate risk; timely fix"""
HIGH = "HIGH"
"""Serious risk...
Problem
A module cannot return another module's type, or receive it as argument. This makes it harder to break down larger projects into several modules.
Solution
I'm not sure what the solution is.
- On the one hand, the lack of this feature is becoming quite painful
- On the other hand, I know that this has been considered, and the conclusion was: it would create intractable "dependency hell" problems.
I wonder if the dependency hell problems could be solved with name mangling?
F...
The original logic for this is illustrated in https://github.com/dagger/dagger/pull/6102#issuecomment-1813209934.
There was some discussion recently about this in #1285289216556925002 message.
- In other words,
GoBuilderas imported byAppwould get its own namespace. I think this might make the dependency hell problem go away.
I don't think this works - if you return a AppGoBuilder from a module that's not `A...
If they are called FooAppGoBuilder and BarAppGoBuilder doesn't that solve the propagation problem?
I think this potentially solves this, but at the cost of making it very very difficult to use - the App name now has to propagate through the entire system - for deeply nested modules, this produces names that would be fairly unreadable.
It also means we'll struggle with caching - with different names in the graphql schema depending on the caller, different callers won't cache. Maybe we could inject the version into the name?
Actually! We potentially have a neat solution I thin...
I ruled this idea out when we first started thinking about this problem for a few reasons:
One is what Justin mentioned about "for deeply nested modules, this produces names that would be fairly unreadable"; this approach might be okay for dependencies 1 level deep, but it really breaks down in terms of comprehensibility after that.
Imagine a dependency graph of modules that looks like:
Bar
\
Foo - Blah - Qaz - Common
/
Baz
If your module has a dep o...
What is the issue?
Yes, I know https://github.com/dagger/dagger/issues/7703 was debated. Not sure if the typescript SDK is not fixed yet or what.
Dagger is a build system for end-user projects. You should never arbitrarily add a LICENSE file if one does not exist.
@helderco -- your comments specify the exact behavior end users expect:
dagger init --sdk ....-- no license file created- `dagger init -...
This happens in the CLI, for every SDK. There's nothing specific to TypeScript.
But what you ask is actually in alignment with:
I know this has been discussed internally in relation to the Daggerverse, but I donโt know if anythingโs been decided yet. \cc @jpadams, @shykes
Yes , I agree with @helderco , got the same warning while using go SDK ( common for every SDK) .
12:46:58 WRN no LICENSE file found; generating one for you, feel free to change or remove license=Apache-2.0
As Dagger generated a default LICENSE file with the Apache-2.0 license , it's a common behavior when creating new projects or modules.
What I'm debating is , can I safely remove this LICENSE file without any issues ?
What I'm debating is , can I safely remove this LICENSE file without any issues ?
Yes -- the goal of dagger is to not litter your source. If the LICENSE was not present before dagger, you are safe to remove it
Thankyou @drmikecrowe for the confirmation
Can we Introduce a command-line flag (e.g., --no-license) that users can specify when running dagger init to skip generating the LICENSE file.
Alternatively, moving the creation of the LICENSE file to the dagger develop command would ensure that it only appears when actual code is being generated as discussed in #6666.
Change would helps in **streamlining project initialization and reduce unnecessary clutter in reposit...
Can we Introduce a command-line flag (e.g., --no-license) that users can specify when running dagger init to skip generating the LICENSE file.
You can actually skip creating the license with an empty value to --license:
dagger init --sdk=go --license=
(--license= is that same as --license "")
But I realize that this is neither intuitive nor documented in --help. The reason for this is in:
These are my personal opinions as an end user:
- Bottom line: NEVER add a license to an end user's production code unless the user adds the
--license. Changing a proprietary project to open-source would be one of the worst things you could do (this is what happened to me). - The
dagger init/develop --licenseis the correct approach - If you are trying to address Daggerverse modules, Daggerverse is broken beyond the LICENSE aspect and not very useful in the node/TypeScript world (sor...
I'm struggling with why you are trying to create a LICENSE file.
Here's my new-user view of my dagger journey. I'm your target demographic -- a devops experienced user that is looking for a better CI/CD solution
Scenario 1
dagger init inside the project directory
/my-project
|- src/
|- .git/
|- README.md
|- LICENSE (or lack thereof)
|- dagger.json
Scenario 2
dagger init above the project directory
/dagger-folder
|- my-project/...
@drmikecrowe, you're right if I understand you correctly, in that the LICENSE file is intended for the use case of standalone and reusable Dagger modules, that get indexed on the Daggerverse. However, we don't have a good way today to distinguish which case is which, and the discussion around how to integrate with existing projects is still in flux so things aren't set in stone.
This issue is a catch-all for a birds-eye view on the general subject of SDKs integrating with existing projects or monorepos in Dagger modules. Specific ideas or proposals benefit from a dedicated issue though.
Problem
SDKs have 2 conflicting requirements:
- Don't interfere with host project
- Make it easy to import code from the host project
This results in "wack-a-mole" situation where users encounter confusing errors when daggerizing, and require custom community suppo...
Came up as an idea when discussing with @shykes. Currently, we can use this pattern:
ctr = dag.
Container().
From("alpine").
With(func (ctr *dagger.Container) *dagger.Container {
if !dev {
return ctr
}
return ctr.WithExec([]string{"go", "env"})
}).
WithExec([]string{"go", "build", "-o", "binary", "./pkg"})
With can be used to easily insert little conditionals into the chain, without breaking it! However, it's a bit unwiedly. What would be really nice...
Yeah sgtm. Just If is a reserved keyword in languages that start function names with a lowercase, so I prefer IfWith, since it's also suggestive that it works like With.
Follow up from #8486
On the daggerverse modules can have long and short descriptions..
Problem
The Dagger API lets you manage the platform (OS + Architecture) of containers. But there are limitations in the API that make some use cases awkward, or sometimes impossible.
For example, given a Container that may point to a multi-architecture image, I can't select a platform:
// Return the version of an image for a specific platform, or an error if the platform is not available
func GetPlatform(img *dagger.Container, platform dagger.Platform) (*dagger.Conta...
Sometimes a Dagger module needs to import code from the project it's embedded in. For example, in our own CI we use a distconsts package to share constants across the Dagger codebase, and the pipelines shipping it. Things like the default path of the engine's state directory; etc.
There's no officially recommended way to do this. What Dagger does for its own CI, is not mentioned in the docs, and we don't know whether it's a good pattern, because we haven't discussed it. So let's discuss ...
In a polyglot monorepo setup, how would this work? Should it be aligned with the Dagger module's SDK, meaning it can't import a pip package in a Dagger module built using the Go SDK? Overall, it's a great idea.
Multiple dagger sdks in one repo... is that an option? maybe that's not sane though. But, if a team is working in a polyglot way, if dagger does support that language, why not have multiple dagger sdks? - Would be cool to rollup into something like dagger functions - but it know...
In a polyglot monorepo setup, how would this work? Should it be aligned with the Dagger module's SDK, meaning it can't import a pip package in a Dagger module built using the Go SDK?
Overall, it's a great idea.
One solution that works today is to leverage module dependencies, as described in:
But I think allowing include/exclude patterns in a dagger.json to reach the context directory, would provide more fine-grained control, and it would be easier to manage:
@Excoriate @pjmagee yes, for polyglot monorepos, it's ideal to have different modules in different parts of the repo, each with its own SDK.
But sometimes one of those modules will need to import code from the application module within the same language silo. That's what this issue is about.
Using native imports as an alternative to multiple modules is definitely not recommended, edit in a polyglot repo.
But I think allowing include/exclude patterns in a
dagger.jsonto reach the context directory, would provide more fine-grained control, and it would be easier to manage:
Correction, it's actually doable with include/exclude patterns to import code from outside the module, but could be better with:
What are you trying to do?
When we write a Dagger module, we need a package.json, go.mod, etc.
These files contain version information that can be consumed by the Daggerverse publishing process.
Currently, we're expected to use Git tags, which when used in a repository housing many modules is far from ideal; mostly because Git and GitHub just don't expect developers to work in this paradigm.
I'd like to see the package manager file used and mapped to a SHA rather than litter...
When we write a Dagger module, we need a
package.json,go.mod, etc.
I don't think go.mod has a version in it. Or does it?
Currently, we're expected to use Git tags, which when used in a repository housing many modules is far from ideal; mostly because Git and GitHub just don't expect developers to work in this paradigm.
Go modules seem to have adopted this pattern and while it's not perfect, I've seen it work well enough.
Problem
Dagger SDKs have access to the entire context of their host project. This allows for in-depth integration, but it also creates the risk of SDKs accidentally interfering with the project. This risk increases with the number of SDKs, and the fragmentation of host projects (different package managers, different conventions, etc).
Recently I have noticed an increase in the number of users reporting problems of this nature.
Solution
I propose sandboxing SDKs. This would p...
For me, ideally, you'd sandbox by default (in any case), but allow users to explicitly specify what else from the repo should be included when the module loads.
Solutions may vary to allow for it, but when it's managed by the user explicitly, it still allows some advanced use cases, without the confusion in simple ones.
To be clear, the Go SDK no longer modifies the parent go.mod during codegen:
But the Go SDK is still the only one that loads files from outside the root directory, in all cases:
If we stop overwriting existing files on init, it's a simple change that goes a long way towards this:
So then, the only thing remaining to completely sandbox, wo...
Agreed, this sounds like the right approach - if we do this, do we go for a slow deprecation with backwards-compat? Honestly, it feels unlikely to break reusable modules in the daggerverse, and more likely to effect the monorepo use case.
I think it's potentially worth considering a hard break here, since supporting both the code paths for this very tricky logic seems quite challening.
What are you trying to do?
Users often use _EXPERIMENTAL_DAGGER_RUNNER_HOST during development with a dev engine or in corporate environments where they are using a custom engine with certs or proxies set. It's all too easy to leave that env var set in your shell (or in CI) when you intend to use a released Dagger engine via the dagger CLI, for example.
see also: https://github.com/dagger/dagger/issues/6599
We should give users informative messages if `_EXPERIMENTAL_DAGGER_EN...
Problem
I can access files "embedded" in my module source, with dag.CurrentModule().Source(), which is super practical. But if I make a mistake and the file is not there, I will not get an error when loading the module - only when calling the particular function that uses the file. I just got bit by this today.
Solution
It would be great if missing embedded files were detected at module load. This would give me more confidence that I am not shipping my module with a hidden fl...
What are you trying to do?
It would be fantastic if we could allow argument annotations on functions, this would allow pulling the environment from .envrc or .env files
Why is this important to you?
Each service in my mono repo configures itself with direnv. Currently I'm duplicating a lot to make workflows work locally and in Dagger.
How are you currently working around this?
Related
I'm curious @rawkode, is this what you're referring to?
I had to write this in PHP, as a workaround. It would be great not to have to do this
private function loadEnvArgs(Container $container, Directory $source): Container
{
$envContents = $source->file('.env')->contents();
$envVars = parse_ini_string($envContents);
foreach($envVars as $envVarKey => $envVarValue) {
$container = $container->withEnvVariable($envVarKey, $envVarVal...
No. My request is for the ability to skip using --value env:SOME when invoking Dagger CLI.
To keep things excplicity, I would explicitly speicify environment variables that need to be imported to dagger, And I would have to types importEnvVar(NAME) and requireEnvVar(NAME). In the second case Dagger will fail if the env var does not exist or is empty.
@rawkode to confirm your use case, you are referring to adding a feature the allow module/function arguments that are currently passed as flags to support environment variables; similar to tools like urfav/cli environment variables?
If I was using the example from the docs it would look something like this?
package main
import (
"context"
"fmt"
)
type MyM...
I have written a shell script to workaround this in the meantime.
#!/bin/sh
envFile="/envFile"
# Check if the file exists
if [ ! -f "$envFile" ]; then
echo "Environment file not found: $envFile"
exit 1
fi
# Read the file and export each line as an environment variable
while IFS='=' read -r key value; do
# Ignore empty lines or comments
if [ -z "$key" ] || [ "${key:0:1}" = "#" ]; then
continue
fi
# Export the environment variable
export "$key"="$value"
# print t...
What is the issue?
I have recently started using Dagger and have experienced a lot of friction, due to not being able to understand how Dagger behaves. Here are two examples of things, which I found confusing as user:
- When running
with_execon container, and starting a process in background such as socat, for example using.with_exec(["/bin/sh", "-c", "socat tcp-listen:2375,reuseaddr, fork tcp:dockerd:2375 &"]).with_exec(["ps", "aux"]), thenps auxdoes not display the socat p...
Thank you @thecooldrop. Agree that we can improve the docs in these areas.
- Have you seen any docs that do a great job with setting that kind of context for new users?
- Are there existing sections in the Dagger docs where you'd expect to find the information you were looking for? Which ones?
- Or do we need a new section or sections? If so, what would you call them?
Regarding your questions:
- I have no reference to an example from other projects, which could serve as a guide toward this. Gradle may be good, since it also starts out by demonstrating a simple usecase, and then iteratively deepens the discussion of specific areas in additional sections. For me usually structuring the documentation around basic usecase and then providing a deeper look, in one colocated area is usually very helpful.
- There is currently no section which I would put this ...
What is the issue?
I am using dagger as a part of my blog publishing workflow and one feature that includes is being able to preview my blog locally by wrapping hugo in a dagger function.
// build and serve local hugo site
func (m *Publish) ServeDev(ctx context.Context) *dagger.Service {
path := "/src"
return m.base().
WithMountedDirectory(path, m.Src).
WithWorkdir(path).
WithExposedPort(1313).
WithExec([]string{"hugo", "serve", "--bind", "0.0.0.0"}).
AsSer...
What is the issue?
Initially reported [in Discord](#github message), Dagger 0.15.1 running on GitHub Actions doesn't appear to respect ContainerWithFileOpts permissions as it did previously in 0.14.
The permissions are applied as defined in the dagger code in these cases:
- Local
- 0.14.x โ
- 0.15.x โ
- GitHub-hosted Runner
- 0.14.x โ
- 0.15.x ๐ซ
I expected the permissions set in Dagger t...
Okay, I've tried to reproduce what you're seeing, and kind of struggling.
So, I've setup a test repo https://github.com/jedevc/repro-dagger-9250 - here's the go code:
package main
import (
"dagger/example/internal/dagger"
)
type Example struct{}
func (m *Example) Test(mydir *dagger.Directory) *dagger.Container {
return dag.Container().From("alpine").
WithFile("entrypoint.sh", mydir.File("entrypoint.sh"), dagger.ContainerWithFileOpts{Permissions: 0500})
}
and the github act...
Investigating this now, will let you know if I need more info! Sorry for the delay!
One note... the dialing issue you see in the log output is likely caused by the engine startup taking longer than it used to. I suspect that this may be fixed by https://github.com/dagger/dagger/pull/9430 (which is where I was seeing such a slow-down). Regardless, I think this is probably unrelated to the permissions issue.
Were you using a shared /var/lib/dagger between different dagger jobs?
@jedevc wow, sorry I missed your responses :( I ended up moving away from GitHub hosted runners so it ceased to be a problem for me.
Maybe @Master-Y0da can help you with more detailed instructions on how to reproduce.
facing this problem right now...cant run my pipelines in local...using fedora.
What is the issue?
I want to use interactive mode (dagger -i ...) to debug issues. But the services always get dropped. If they could remain up, it would be really helpful.
Dagger version
dagger v0.15.1 (registry.dagger.io/engine:v0.15.1) darwin/arm64
Steps to reproduce
// interactive shell looses the service dependency currently (0.15.1)
func (m *Treasury) ExperimentWithService(
ctx context.Context,
) (string, error) {
service := dag.Container()....
I experienced this need/want while debugging as well. Would be amazing. cc @aluzzardi
What is the issue?
In the explanation of Services the grace period of Services is mentioned, but with no introduction of what that is, nor of what it does. I would like to have documented:
- What does it mean that Services have grace period?
- What is the effect of the grace period?
- How can we avoid the effects of grace period ? From current documentation about Redis, it seems that the grace period can be wroked around.
- Provide a clear ex...
Problem
It has been raised by a user in Discord (https://discord.com/channels/707636530424053791/1316771968762253312) that WithMountedCache seems to be honoring the engine's default user:group permissions. This causes issues as it breaks the pipeline portability depending on how the the engine is provisioned
Solution
How about if we enforce root:root for all WithCacheVolume calls unless the Owner field is set in the call?
Steps to reproduce
- run the eng...
bumping this one since another user tripped with it today #1366222120173965312 message.
This also happens to all With* methods that create files or directories in the underlying containers.
The line above seems to imply that dagger can be used with rootless containers.
However, https://github.com/dagger/dagger/blob/main/core/docs/d7yxc-operator_manual.md#can-i-run-the-dagger-engine-as-a-rootless-container states very explicitely that the Engine cannot be ran rootless.
Would it be useful to clarify that point on the nerdctl page ? Or did...
Good shout @gotcha - looks like we made a mistake in https://github.com/dagger/dagger/pull/8242.
Dagger doesn't support rootless, so yes, the instructions are wrong.
Rootless support is eventually possible - however, it's not on the immediate roadmap. There's quite a lot of work and plumbing we'll need to make this work. We do a lot of custom networking to enable Services, and similar things.
That's not to say it's impossible (I'd definitely like to support it one day), it's that it's not currently a priority - we're a small team, we sadly don't have infinite capacity. Atm, a lot of our effort is working on improving performance, building out better ...
Dagger doesn't support rootless, so yes, the instructions are wrong.
Security conscious organizations do not like this state of affairs. Are there plans to support rootless, even far away ? Or is that a no go ?
you might be able to use rootless with a custom OCI runtime like nerdctl
The https://github.com/dagger/dagger/issues/1287#issuecomment-1673365304 also suggests to research nerdctl support. Should it be edited ?
@gotcha the Dagger engine acts as a container runtime. As such it is normal for it to have system privileges required to run containers. Running dagger in a rootless container means running runc+containerd as a rootless container: not impossible but more of a science project; and not required for security.
Security-conscious teams should apply the same best practices to dagger as they do to buildkit/containerd/runc. In practice that means vm-level isolation of workloads.
@shykes Thanks for the detailed answer. Not being a security specialist, your words will help me having constructive conversations with people that jump to quick conclusions based on your documentation.
I appreciated your take on this that you stated in https://www.youtube.com/watch?v=Sn1w51Vh0mM
What is the issue?
This is particularly problematic when the Engine exits / gets killed and the CLI continues to run. Without an external timeout (e.g. GitHub Actions job timeout), the CLI execution will not terminate.
Furthermore, pressing q once does not quit the CLI. In other words, the CLI is not able to terminate gracefully when it's no longer connected to the Engine.
Dagger version
dagger v0.14.0 (registry.dagger.io/engine:v0.14.0) darwin/amd64
Steps to ...
Follow-up of #python message
The Python SDK now relies on the ghcr.io/astral-sh/uv container image:
with the migration to uv (for python sdk) there is a new container image used (ghcr.io/astral-sh/uv). Now in enterprise environments that is not allowed, like in my case and you need to set container registry mirror. The problem with that is that our mirror requires credentials and I can not change than. I also can...
I don't think this is Python specific even though it could affect Python daggernauts more due to the non-default ghcr.io (GitHub Container Registry).
The problem seems to be having a private container registry mirror (in the engine) that requires authentication. OP is having difficulty setting that up.
Sorry for a delay from my side, I've been busy with other stuff.
I'm logged in into the mirror and I can do docker pull without any issues, uv images get pulled down via docker cli. Then running the dagger command fails because it can not pull from our mirror. This iswhat I'm doing.
engine.toml is:
debug = true
trace = false
insecure-entitlements = ["security.insecure"]
[registry."docker.io"]
mirrors = ["OUR_MIRROR_DOMAIN"]
[registry."ghcr.io"]
mirrors = ["OUR_MIRROR_DOM...
Some users have been encountering issues when trying out out Git credential helpers in CI
I am moving the conversation to its own issue @pspurlock, and cleaning up the other (everything was screenshotted)
After discussing with @nipuna-perera, they do manage to make it work ; It seems to be a configuration issue / patterns to use, which shall become a standard.
Next step on my end:
- [x] Working repro for GitHub / GitLab / BitBucket
- [ ] Isolate the pattern and documen...
cc @vikram-dagger, where shall i document those examples ?
https://docs.dagger.io/integrations/gitlab would work - thanks for creating this example :)
hey @pspurlock
I have a working implementation in a gitlab-ci.yml:
image: docker:latest
services:
- name: docker:${DOCKER_VERSION}-dind
alias: docker
variables:
DOCKER_HOST: tcp://docker:2376
DOCKER_TLS_VERIFY: '1'
DOCKER_TLS_CERTDIR: '/certs'
DOCKER_CERT_PATH: '/certs/client'
DOCKER_DRIVER: overlay2
DOCKER_VERSION: '24.0.6'
GIT_USERNAME: "grouville"
GIT_TOKEN: "${PAT}"
stages:
- build
dagger_job:
stage: build
before_script...
@grouville Thanks for doing this. I can't try out your example fully because dind requires privileged mode for the runner which we don't allow. However, I did try to mimic it as much as possible and still get the same access denied error.
For context, we have a gitlab runner deployed alongside a dagger engine/deamon in a cluster. When we run a CI Job, we then use _EXPERIMENTAL_DAGGER_RUNNER_HOST so that the CI Job will connect and use the daemon running in the cluster. So when `dagger -m...
@grouville Thanks for doing this. I can't try out your example fully because dind requires privileged mode for the runner which we don't allow. However, I did try to mimic it as much as possible and still get the same access denied error.
For context, we have a gitlab runner deployed alongside a dagger engine/deamon in a cluster. When we run a CI Job, we then use
_EXPERIMENTAL_DAGGER_RUNNER_HOSTso that the CI Job will connect and use the daemon running in the cluster. So when `dag...
Mmmh, weird ๐ข i'd be happy to sync with you to debug that live
Normally, the source of truth is always the CLI, so the one running in the CI Job that is running the dagger call command. I'll try with the _EXPERIMENTAL_DAGGER_RUNNER_HOST, if there's a bug, but I don't think so.
I have tried to add credentials in both places and neither have worked, but it would help to clarify. I know it isn't a credential issue because I can run the same credential helper commands and then git clone successfully before the dagger command fails.
If you make the same behavior as I did above, basically setting your own credential helper, if you add a step that actually prints it:
- script:
# this should print user and pat -- please ensure that
- /tmp/git-c...
is it possble to configure this at global level something similar
git config --global url."https://gitlab-ci-token:$GITLAB_TOKEN@gitlab.com/".insteadOf "https://gitlab.com/"
Hi @skycaptain ๐
Thank you for digging the root cause, I was falling short on time ๐
-
We already retrieve the username, so totally doable -- it means that users will always have to specify the
username, for every provider. If well documented in our docs, would that be ok ?x-access-tokenfor all the other CI providers,gitlab-ci-tokenfor gitlab -
Regarding your
pipeline example, I really like it ; smoother indeed. -
Regarding the use of the cache `git config --global...
I narrowed it down to just using the .git-credential file since the helper store will ultimately do this anyway. Nice and tidy and ofc its wiped after every ci run:
- echo -e "https://gitlab-ci-token:$PAT@myproject.com" > ~/.git-credentials
- git config --global credential.helper store
- dagger call ...
We already retrieve the username, so totally doable -- it means that users will always have to specify the username, for every provider. If well documented in our docs, would that be ok ? x-access-token for all the other CI providers, gitlab-ci-token for gitlab
In my experience, users of private repositories are accustomed to specifying both username and token. If the following line from the documentation represents the intended goal, then I would expect Dagger to use whatever username t...
I want to bring attention back to this issue, as it is currently blocking from effectively using modules on GitLab due to the incorrectly hard-coded username used for HTTPS authentication being incompatible with CI_JOB_TOKENs.
Should we split the "HTTPS with GitLab not working with CI_JOB_TOKEN" or "Dagger not respecting username for HTTPS auth" into a separate issue? The initial intent, as the title suggests, was to provide examples in the docs. However, the discussion revealed an issue wit...
This doesn't (Still valid json)
// +default="['one','two','three']"
This is a valid JSON string, not a valid JSON list (also note, even the contents of the JSON string aren't valid JSON - only double quotes are valid JSON strings).
Agreed this should be better documented, but I don't think we should make the second example work.
What is the issue?
When the engine autoscaled due to increased load, it took approximately 4 to 5 minutes to start jobs because of the size of the caches. During 20 to 30% of these autoscaled job executions, the engine suddenly stopped responding and left the jobs hanging.
When I look to engine logs or k8s logs I can't see any error, issue or event related to this other than screen shot of the engine logs and job logs.
Dagger version
v0.13.7
Steps to reproduce
It is happe...
What is the issue?
I'm trying to run dagger develop --sdk=python after the initiation with a name.
Dagger version
dagger v0.13.6 (registry.dagger.io/engine:v0.13.6) darwin/arm64
Steps to reproduce
dagger init --name=blah
dagger develop --sdk=python
Log output
โ connect 0.2s
โ cache request: mkfile /schema.json 0.0s
โ load cache: mkfile /schema.json 0.0s
โ cache request: blob://sha256:9121d31121f4c30e725664dd17c07133b4cb49e375a465f39f740736d4e...
Same issue with
dagger v0.14.0 (registry.dagger.io/engine:v0.14.0) darwin/arm64Trying to run the quickstart in the docs here (w/o Dagger Cloud)
(Go SDK)
~trying to authenticate to azurecr.io (Microsoft Azure Container Registry).
Verified the credentials, if I do adocker login(locally) then it works, but it doesn't seem to be able to use thedocker logincredentials when run in a Github action.~
Works here, with azurecr.io...
Same issue with dagger v0.14.0 (registry.dagger.io/engine:v0.14.0) darwin/arm64
Trying to run the quickstart in the docs here (w/o Dagger Cloud)
What happened? What did you expect to happen?
Hello,
I'm running Dagger in GitLab CI. I'm using it to request certificate to Hashicorp Vault. However Dagger prints the output of the request in plaintext in our GitLab CI, which includes the certificate key. Is there an option to specifically disable the output of a command in Dagger UI, without silencing everything else (with -s)?
Thanks.
maybe this solution will solve your problem link
I just ran into this as well.
I did noticed that there is a redirectStdout option that redirects the output to a file, but the results still show up in the logs
Wouldn't the existing api with redirectStdout cover it?
.withExec(['cmd', 'arg1', 'arg2'], {redirectStdout: '/tmp/output.log'})
Or do you mean more generically with something like
.withExec(['cmd', 'arg1', 'arg2'], {suppressStdout: true})
What are you trying to do?
I am creating a simple Dagger function that uses context directory. I am using defaultPath for the directory but when coding the function, I intuitively used default instead of defaultPath. The defaultPath is a special pragma for Directory however, the error I got in the CLI did not indicate this. It was cryptic.
Produce a better error message when the user accidentally uses default instead of defaultPath
Why is this important to you?
It...
What is the issue?
I have a daggerverse repository that contains multiple modules I want to use from other repositories using dagger -m ...
When I call dagger -m ../daggerverse/ci call , I expected defaultPath to load data from the current repository, but instead, I get the content of my daggerverse repository, which make defaultPath useless here
However, if my ci module call another module that also has a defaultPath="/" argument, then will get the content of th...
maybe this solution will solve your problem link
What is the issue?
This Go code in a dagger module:
func (m *Rack) Join(r *Rack) *Rack {
m.Name = m.Name + "+" + r.Name
m.Services = append(m.Services, r.Services...)
return m
}
Gets generated as:
func (r *Rack) Join(r *Rack) *Rack {
assertNotNil("r", r)
q := r.query.Select("join")
q = q.Arg("r", r)
return &Rack{
query: q, ...
I think this is a specific case of https://github.com/dagger/dagger/issues/6186 - linking against that one.
maybe this solution will solve your problem link
What is the issue?
Dagger container entrypoint issue when engineVersion is missing in the dagger.json (I had found this when I tidied up the remote private daggerverse JSON file based on a much older Dagger version example online)
In my particular case I was pulling a container, with a mounted directory and work dir and then running a simple with_exec(["ls","-ls"]) and that was failing when called with -m (with my "tidied up" dagger.json) but worked OK locally as that still engineV...
What is the issue?
As asked on Discord, the code attached exhibits a weird behaviour depending on how it is invoked.
dagger call build something fails with Error: this.myDirectory.file is not a function
dagger call build env base with-exec --args cat,/x succeeds
Note how the build something is fundamentally doing the same as the second CLI command. It appears as if this.myDirectory magically becomes...
Problem
Can't call dagger call test terminal on this pipeline:
import { dag, Container, object, func } from "@dagger.io/dagger";
@object()
class Lala {
/**
* Returns a container that echoes whatever string argument is provided
*/
@func()
async test(): Promise {
const s1 = await dag
.container()
.from("nginx:latest")
.withExposedPort(80)
.asService()
.withHostname("web1")
.start();
return dag.container...
Problem
Getting the following error when trying to define a type with the same name a as a module type:
Error: input: module.withSource.initialize resolve: failed to initialize module: failed to add object to module "program-backend": failed to validate type def: object "ProgramBackend" function "Cache" cannot return external type from dependency module "cache"
main module:
package main
type ProgramBackend struct{}
type Cache struct{}
// Returns a conta...
cc @helderco might know what's happening here
Hm, this looks like a naming confusion error :thinking:
I suspect we're getting something wrong in the go codegen / engine here - this is where the error is from: https://github.com/dagger/dagger/blob/8b3b8af59328d341a0486eaf1463736ca376849b/core/module.go#L475-L484
(already validated, skip is not the right comment for this code :thinking:)
@marcosnils can you confirm, the main module has your dependent module installed? Also, what are the names of the modules? If the depend...
Problem
dagger develop doesn't seem to be using proper grouping in the telemetry spans. Here's the output of an example call:
dagger develop
โ connect 0.2s
โ cache request: mkfile /schema.json 0.0s
โ load cache: mkfile /schema.json 0.0s
โ cache request: blob://sha256:3f96dc98cb3827315b7c4f8e21be0fec3eabd82f4c09031d83f87650b1b5519c 0.0s
โ load cache: blob://sha256:3f96dc98cb3827315b7c4f8e21be0fec3eabd82f4c09031d83f87650b1b5519c 0.0s
โ moduleSource(refString: "."): ModuleS...
I think init has the same issue? Maybe also query/etc - should probably look through other commands as well to see where we see this issue.
It would be great to solve this one :)
It would be great to solve this one :)
Sure, feel free to give it a shot @mcruzdev
What is the issue?
Following some Discord discussions and buildkit comments (https://github.com/moby/buildkit/issues/1143#issuecomment-2327052682), I tried using the experimental dagger cache, pushing to a private docker registry. It appears to pull the cache (if it exists), but fails to export it.
I'm not sure if this is a Dagger issue or buildkit issue, but I've noticed a context canceled error cropping up when the cache is being exported. It seems odds that it's receiving a co...
I don't think this is fully supported, this is was also mentioned by @nipuna-perera recently
cc @sipsma
I don't think this is fully supported, this is was also mentioned by @nipuna-perera recently
cc @sipsma
Hey Sam, I have not run into this but this is interesting if possible. I also didn't know it was.
This seems like a similar error to what is mentioned in Discord here: #1243602114563932270 message
What happened? What did you expect to happen?
Does anybody have any examples of a monorepo? For example, I'm trying to learn how to:
- Creating the buildEnv at the top level and leveraging this for all apps
- Caching of
node_modulesin each projects (some node tooling we use forces us to use individual node_modules at the moment) - Supporting 2 source folders (
apps/andpackages/-- both of which are used)
@vikram-dagger This is an issue to keep in mind for the documentation that you are working on. @TomChv can sync with you on the best practices.
I'm removing the sdk/typescript label since it's not a specific TS issue and we should write guidelines for every SDKs :)
What is the issue?
My function failed when I tried to add decorators on it. I can find workaround but not sure if it should add to docs.
Dagger version
dagger v0.13.3 (registry.dagger.io/engine:v0.13.3) darwin/arm64
Steps to reproduce
get following error when run dagger call load-context (module name is test)
def timer(func):
"""Print the runtime of the decorated function"""
# @functools.wraps(func)
async def wrapper_timer(*args, **kwar...
if uncomment # @functools.wraps(func), the decorator is working. it seems dagger decorator depends on the meta data of original function?
At first glance, you should have @function closer to your function, like this:
@timer
@function
async def load_context(self) -> str:
...
The reason is that @function needs to correctly introspect the function, and your wrapper may hide the necessary information because it has a different signature. Notice that with Dagger you need to be careful about types because we need to report those to the API beforehand, not just be able to execute. Even during execution we ...
Thanks @helderco ,
move @function close to function did not help. Here's error,
Error: input: module.withSource.initialize resolve: failed to initialize module: failed to call module "test" to get functions: call constructor: process "/runtime" did not complete successfully: exit code: 1
Stderr:
โญโ Error โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Function โTest.load_contextโ seems to be decorated in a class that is not โ
โ itself decorated with...
What is the issue?
I pass in a remote container and the CLI reports that it loads successfully (as indicated by checkmark) but doesn't perform any operations as defined in my dagger function.
dagger should at least report that the container failed to loed
Dagger version
dagger v0.13.5 (registry.dagger.io/engine:v0.13.5) linux/amd64
Steps to reproduce
I have a function that is just this:
func (m *InkyBuild) PythonSetup(ctx context.Context,
...
We should find a way to consolidate the API between WithHostname and WithServiceBinding as they currently don't play along very well together in a multi-module setup.
Repro:
Module A:
// Returns a container that echoes whatever string argument is provided
func (m *Lala) Test(ctx context.Context) *dagger.Container {
svc := dag.Container().From("nginx").
WithExposedPort(80).AsService().WithHostname("web")
svc.Start(ctx)
return dag.B().Run(svc)...
The catch is that we can only set a single Hostname with Buildkit for a service, so when WithHostname is used we set the configured one instead of the content-addressed one. That breaks in this case, since only one of the modules will have actually started it, and it'll only have that module's ID in the hostname.
Effectively, only one module can use a WithHostnamed service at a time within a session. You would have the same problem if you tried to reach the configured hostname within...
What is the issue?
I was running some functions repeatedly with dagger -s to get less verbose output to my terminal. I wanted concise output to share with colleagues as a repro. My dagger -s call commands were working fine until I added terminal to the end of a call that returned a Container type. I expected it to work as normal, but dagger threw an error.
An example:
Error: response from query: input: container.from.terminal resolve: failed to forward exit code: failed ...
This does appear to be intentional: https://github.com/dagger/dagger/blob/701be1ccab448437e0f03b1c1461c4b1456a0051/cmd/dagger/terminal.go#L18-L20
There should be a better error message presented here (instead of nothing), but I don't think it is intended to work.
Just ran into this myself. This would be really helpful until #10401 gets implemented for a few of my workflows that take a lot of different input params. Specifically the passing of secrets that I cannot do without passing each as a param.
As a workaround you can just grab the latest layer and run it directly docker run -it --rm <layer> /bin/bash
What is the issue?
Hi Team,
I am running into an issue when trying to understand the current behavior of CacheVolume. I have the following simple module:
import (
"context"
"dagger/foo/internal/dagger"
"fmt"
)
type Foo struct{}
func (f *Foo) TestCacheVolumePersistence(ctx context.Context, input string) (string, error) {
_, err := f.PopulateCache(ctx, input)
if err != nil {
return "", err
}
output, err := f.ListCache(ctx)
if err != nil ...
not sure if this is related, but in same module (cloned from provided repo), I noticed if I try to create a file using "WithNewFile" inside the mounted cached directory, it errors out: /foo-cache/: cannot retrieve path from cache. (I am suspecting its looking for /foo-cache in the cache itself, while I am expecting /foo-cache to be the mounted dir)
dagger call with-new-file
โ connect 0.2s
โ initialize 0.3s
โ prepare 0.0s
โ foo: Foo! 0.0s
โ Foo.withNewFile: Cont...
What is the issue?
I see the error:
time="2024-10-04T08:35:43Z" level=warning msg="failed to rehash ca-certificates: ERROR: Access denied '/usr/local/share/ca-certificates'\n" error="exit status 2"
When I mount a configmap containing some-ca.crt into the folder.
It does not crash the dagger-engine, which starts up afterwards.
While it does not work following container restart, if I exec update-ca-certificates in a pod the CA certificate is applied and works as expected....
What is the issue?
Hi,
I've been evaluating Dagger and I found performance to be abysmal and TUI exposing buggy and erratic behavior, e.g. (runtimes on M2 Max machine).
Context
dagger functionstook 20-25s (after aggressiveexcludeand filtering in module) to finish- both TUI and
--progress=plaintended to hang indefinitely - TUI often showed weird traces, omitted results or heavily delayed result output
- simple test flow took 6 minutes and didn't finish where r...
I'm confused - is the OTEL_ configuration invalid, i.e. pointing to an unreachable service? The dagger CLI very much intentionally respects OTEL_ env vars and expects them to be a functional configuration. We use it all the time for troubleshooting deeper engine behavior.
OTEL_ configuration invalid, i.e. pointing to an unreachable service?
Using above definition yes, it's invalid for Dagger.
ENV variables are targetting developed application that has a network configuration allowing it to reach OTEL, Dagger Engine isn't configured to do so.
As mentioned above, for me the main issue is lack of information when running functions that Dagger not being able to reach OTEL_ configured hosts will impact on its performance.
What is the issue?
This is related to the following issue, which makes some clarifications on the different mechanisms for filtering a Directory uploaded from the host to the engine:
However, even if itโs clear which is which in a trace, we can help users know how to debug if theyโre actually filtered as expected.
See the following comment, which provides source material for this:
What is the issue?
Question from user in [Discord](#python message) about how to manage multiple virtual environments in PyCharm, and realized we can help with more clear instructions here:
Try this, have PyCharm opened in your existing project, and File > Open the Dagger moduleโs directory. You should see a dialog with the option to attach to the opened project. Just select that and, assuming you alread...
Attaching a project to an existing primary project might still require to set the interpreter accordingly to use the venv from inside the dagger directory instead of the primary project's one.
<img width="1595" alt="image" src="https://github.com/user-attachments/assets/7d65325b-aaf1-45c1-b589-d5d5a49614c5">
I know how workspaces work, the Python SDK uses it: ๐
Setting up the workspace won't be something that Dagger will manage for you. I'm just talking about documenting how this can be done for those interested in this solution, but it's up to the user to set it up.
Honestly, once you work out where in the docs this should go, and the kind of things we should cover, we should also have similar docs for go and typescript.
I did some tests with uv workspaces a week ago (outside of the dagger context) to figure out how they are supposed to be used. While dependencies are specified on the nested projects seem isolated, they are all installed in a single venv and thus must not have conflicting requirements with the other workspace packages. This could be problematic looking at what libraries are used for a minimal Dagger setup. And even if there are no conflicting requirements, I think it's still better to not pol...
I have a decent environment setup using vscode. If anyone is interested, I can demo. It's set up using nx monorepo and a view vscode plugins. I could do a video on this if anyone is interested.
I have a decent environment setup using vscode. If anyone is interested, I can demo. It's set up using nx monorepo and a view vscode plugins. I could do a video on this if anyone is interested.
This is definitely interesting, is there something different in your setup than what we explain there: https://docs.dagger.io/manuals/developer/ide-integration ?
I'm new to dagger but ain't new to uv workspaces.
I currently have a monorepo with uv workspaces set up.
I'm kinda struggling to create dagger projects in this setup:
- I'd like to have these projects as workspaces members. This means they won't get their own
uv.lockfiles (all members share a single.venvauv.lockfile in the repo root). it's unclear how to override the default containerizeddaggerenv build by using the repo rootuv.lockfile. - It's unclear why is `d...
What happened? What did you expect to happen?
So, at a high level, I have the following folders:
โโโ .yarn
โ โโโ berry
โโโ node_modules
โ โโโ .store
โโโ apps
โ โโโ skills
โ โ โโโ node_modules
โ โโโ stocks
โ โ โโโ stocks-api
โ โ โ โโโ node_modules
โ โ โโโ stocks-ui
โ โ โโโ node_modules
โ โโโ landing
โ โโโ node_modules
โโโ packages
โ โโโ pinnacle-layer
โ โ โโโ node_modules
โ โโโ typescript-config
โ โ โโโ node_m...
What is the issue?
This change in my trivy module cuases the following error:
invoke: returned error 422 Unprocessable Entity: {"errors":[{"message":"Expected Name, found \u003cInvalid\u003e","locations":[{"line":1,"column":1677}],"extensions":{"code":"GRAPHQL_PARSE_FAILED"}}],"data":null}
Dagger version
dagger v0.13.1 (registry.dagger.io/engine:v0.13.1) darwin/arm64
Steps to reproduce
See the above PR.
##...
As mentioned in https://github.com/sagikazarmark/daggerverse/pull/177#discussion_r1771215596, this is caused by passing an invalid enum value directly to graphql.
This isn't correct, but we should make the error message clearer. Ideally, we should perform some sdk-side validation to ensure that the enum value is actually valid before attempting to marshal it into the query.
I think this is just a go issue, since other languages have stronger enum types that don't suffer from this partic...
I have a similar error
returned error 422: {"data":null,"errors":[{"message":"Expected Name, found :","locations":[{"line":1,"column":104}],"extensions":{"code":"GRAPHQL_PARSE_FAILED"}}]}
exit status 1
I have no idea what bad data I'm passing to the Go SDK. At least getting at the actual query text could help my narrow things down. A better error message would be appreciated greatly
I narrowed my issue down to
NetworkProtocolTcp NetworkProtocol = "TCP"
where I have...
What is the issue?
For a windows user running the installation against a version incompatible with the latest language features (looking at you... the user who holds onto Windows Powershell 5.1 until their last breath and still tries to use ISE ๐คฃ).... PowerShell has language feature to put required version so the error message is more useful in the installation script.
~[#Requires](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_requires?v...
What is the issue?
Hi
From this: https://docs.dagger.io/manuals/user/chaining
Running this func:
dagger -m github.com/kpenfound/dagger-modules/golang@v0.2.0 call build --source=https://github.com/dagger/dagger --args=./cmd/dagger entries
Error: response from query: input: golang.build resolve: call function "Build": process "/runtime" did not complete successfully: exit code: 2
Stdout:
marshal: json: error calling MarshalJSON for type *dagger.Directory: input: contai...
Ah, this is an issue that @kpenfound's module uses an old version of go (while github.com/dagger/dagger pretty much tracks go releases).
@dagger/docs could we update this module to use a more modern version of go?
The chaining example doesn't currently work.
What is the issue?
Hi
I'm getting this error during test
Error: ../../../go/pkg/mod/dagger.io/dagger@v0.13.0/telemetry/exporters.go:92:23: cannot use log (variable of type "go.opentelemetry.io/otel/sdk/log".Record) as *"go.opentelemetry.io/otel/sdk/log".Record value in argument to e.OnEmit
Dagger version
dagger v0.13.0
Steps to reproduce
No response
Log output
No response
I am seeing the same error after upgrading my go dagger module to 0.13.0
cc @vito
I think this happens because we pin the OTEL logging, but sometimes the base OTEL stack can upgraded (e.g. if using a parent go.mod, or dependabot decides to do it, etc) because we don't pin it.
Should we just pin all of OTEL for modules? Sucks, but given how unstable the upstream APIs are, I'm wondering if we should, as suggested here: https://github.com/dagger/dagger/pull/8234#discussion_r1732585400
@jedevc We already pin this dependency for modules, but the issue still remains for non-module use cases, which seems to be the situation here considering the error path (../../../go/pkg/mod/dagger.io/dagger@v0.13.0/telemetry/exporters.go).
For anyone hitting this with non-modules, you could copy-paste these replace rules - ugly solution, but it would prevent the dependency from drifting forward into brokenness.
https://github.com/dagger/dagger/blob/06839862e3437c2f16d95c3621e0d7b1f...
This is an issue we can easily encounter on the main branch of https://github.com/dagger/dagger.
Create a worktree:
$ git worktree add
$ cd
Try and get some git metadata:
$ dagger call -m version git head
...
fatal: not a git repository: /home/jedevc/Documents/work/dagger/dagger/.git/worktrees/
This occurs because we look for where .git exists - there's a git file created at .//.git - it's not a directory, and instead contains contents like: `gitd...
Got (almost) the same problem when trying to call Directory.asGit in a git submodule.
Similar to how we have a CHANGELOG.md which describes all of the changes, we should start writing a migration guide - when we release breaking changes, we should add entries to describe everything that users may want to know about upgrading.
This should include:
- For API facing changes, codeblock diffs, with examples for each SDK
- For SDK facing changes, codeblock diffs, with examples for the affected SDKs
- For CLI facing changes, a before-and-after
In the first version of thi...
Overview
When alpinelinux.org is down, building dagger fails. This may also affect other dagger modules that use alpine in the same way we do.
What I did
dagger call -m github.com/dagger/dagger dev
What I expected
A successful build of the latest dagger engine
What happened
Intermittently I get:
[...]
โ โ alpine(branch: "3.20.2", packages: ["build-base", "go", "git"]): Alpine! 0.2s
โ โ
.container: Container! 0.2s
โ ! failed to get alpine...
[dagger/dagger] New comment on discussion #12211: Building dagger fails when alpinelinux.org is down
Agreed, this is a little frustrating - however, this is the case for a whole variety of services:
- Dockerhub (for our use of official images)
- The go proxy, pythonhosted, npm (anything that our SDKs use)
- Github (or anywhere our modules are hosted)
There's a few things we can do to improve this generally, but having better caching is really the best first step. Avoiding making as many network requests as possible will be a huge help here.
After that, I think having a concept of "p...
You canโt create a module that conflicts with a core type:
โฏ dagger init --sdk=go container
Initialized module container in container
โฏ dagger functions -m container
Error: get module name: input: failed to get schema: failed to get schema for module "container": type "Container" is already defined by module "daggercore"
But a module doesnโt just create an object named after the moduleโs name, it also creates a constructor field under Query with the same name.
However, f...
Error: input: goreleaser failed to set call inputs: failed to load contextual arg "source": failed to load contextual directory "/": failed to get dir instance: failed to get blob descriptor: failed to solve blobsource: failed to load ref for blob snapshot: missing descriptor handlers for lazy blobs [sha256:391afdd16053cec967706502836ef1516804a1f0e7550d824c9b08b61eac13b9]
Currently in a broken state. @sipsma let me know what information will help to debug this
_EXPERIMENTAL_DAGGER_CACHE_CONFIG="type=s3,mode=max,use_path_style=true,prefix=*******/,access_key_id=*****,secret_access_key=*****,bucket=*****,region=us-east-1"
as a follow up of https://github.com/dagger/dagger/pull/8724#discussion_r1848219633, we want to possibly revisit later the key used for namespacing the cache volume.
originally the idea was to use module digest, but that would mean if change the module source, the new cache volume will be created, so as part of https://github.com/dagger/dagger/pull/8724 we are creating cache volume based on modName + modPath
This may bring up its own set of challenges, so keeping this issue to tra...
Is it possible to allow users to customize the namespace key? I.e., if we want to also always use git.repo and git.branch for namespacing.
Problem
Edit: check my last comment below: https://github.com/dagger/dagger/issues/8955. Seems like the original issue can't be reproduced anymore verbatim. However, there seems to be some other variations that still show a similar cache invalidation behavior.
I have the following pipeline:
func (m *Test) Test() *dagger.Container {
return dag.Container().From("alpine").
WithExec([]string{"sleep", "5"})
}
~~If I run that multiple times, I'll get a cached output as expec...
๐ I can't seem to repro the above issue anymore. However, there's a new variation of this issue which manifested after a user reported a cache invalidation confusion here: #daggernauts message
Here's the new code to reproduce:
// Returns a container that echoes whatever string argument is provided
func (m *Second) Foo(context *dagger.Directory) *dagger.Container {
return dag.Container().From("alpine:latest").
...
If you remove the
withMountedDirectory, caching works as expected
This seems related to:
Good call, that's definitely worth making sure of.
That said, there's still something else going on - the above shouldn't be going through the slow content cache. We should be able to look this up in the fast definition cache, so it seems likely that we're somehow generating subtly different buildkit operations between runs (and if we are, then why aren't we getting the same results)?
Okay, the issue is here: https://github.com/dagger/dagger/blob/84dc5b3ba37238d957db1025c70dca797d35a055/engine/sources/local/source.go#L152-L152
Introduced in #8818 I think - when we stopped "freezing" blobs of the local source. The dagql IDs are all correct with the MakeDirectoryContentHashed function, but, this doesn't change the LLB. The session: prefix is magical - and is essentially breaking cache here.
The solution will be part of our dagop work - when we port the code out of buil...
Will be fixed by #10367.
Creating an issue in our repo so I have somewhere to link to in our codebase pending creation of an upstream fix PR.
Noticed this while working on https://github.com/dagger/dagger/pull/8871
There's a bug upstream where:
- Two or more images are the same when uncompressed, but get referenced with different compression (i.e. gzip vs zstd)
- One of the images is lazy, but the other isn't
- The image is used as the "source" for a cache volume
- Possible this happens in some other ...
Ended up hitting more variations with the same root cause, upstream fix here: https://github.com/moby/buildkit/pull/5560
Problem
After opening the following PR (https://github.com/dagger/dagger/pull/8837) which only modifies docs, I've noticed that several unrelated CI jobs triggered. We should improve the workflow filtering logic so we don't trigger unnecessary CI jobs.
@jedevc shared that we can add these filters after https://github.com/dagger/dagger/pull/8765 is merged :open_hands:
Originally reported by @helderco in https://github.com/dagger/dagger/pull/8812#issuecomment-2447985322
It's possible to crash the engine (v0.13.6) deep in the telemetry stack:
panic: runtime error: cannot convert slice with length 0 to array or pointer to array with length 16
โ
โ github.com/dagger/dagger/engine/telemetry.ReexportLogsFromPB({0x287f500, 0xc0b038b3b0}, {0x2873b50, 0xc08ceef800}, 0xc0846a8a80)
โ /app/engine/telemetry/logs.go:35 +0x9df
โ github.com/dagger/dagger...
Definitely seems like this is caused by #8812 in part, but also we should guard against this happening in the engine - SDKs shouldn't be able to crash the engine.
Turns out, that PR was just triggering an issue that exists in main still. It has to do with a test in pytest triggering a log after another test used a connection on its own event loop, and when in a nested session (even without ExperimentalPrivilegedNesting).
Iโve fixed the PR to avoid the warning in the first place, b...
What seems like a similar issue appears to still exist as of 0.16.2. I'm hitting it like this:
- create an empty dir and initialize elixir SDK in it,
- run
dagger functioncommand several times
Repeatedly running dagger function succeeds most of the times, but occasionally would fail with either of these two errors:
โ load module 1.3s
! failed to get configured module: Post "http://dagger/query": unexpected EOF
โ โ finding module configuration 1.3s
โ ! Post "http://dagger/query": ...
Today, we don't support dagger shell or .Terminal when using --progress=plain: https://github.com/dagger/dagger/blob/d4d759140e4964437f9468d6537ff7a9fd313837/dagql/idtui/frontend_plain.go#L225-L227
Sometimes this is true - e.g. in many CI environments, the terminal isn't a proper TTY (or doesn't have stdin). But when running with --progress=plain locally, it's totally possible that I'm running this within the context of a full TTY.
We should handle backgrounding the `frontendP...
Spinning out from https://github.com/dagger/dagger/pull/8557#discussion_r1808457164, and other similar conversations.
Our test suites have gradually become longer, more complicated, etc - there's a lot of repetition and complexity that can be hugely simplified. Some more concrete ideas:
- Manual setup of test contain client as using
c.Container().From(golangImage).WithMountedFile(testCLIBinPath, daggerCliFile(t, c)), in other places asdaggerCliBase. - Manual
dagger initsteps in...
I've seen this happen in CI a few times now:
- The tests pass in GHA
- But we get a failure in the Dagger Cloud traces checks due to a "timeout after 5 minutes"
Most recent occurrence:
- All test workflows pass (here and here)
- Traces check is marked as failed...
What are you trying to do?
Follow up to #7832 to also apply ignore pattern at the engine level when a directory is passed as argument to another module's call.
Why is this important to you?
No response
How are you currently working around this?
No response
Summary
Look for and resolve cache misses in Pythonโs runtime module.
Motivation
Weโve been steadily improving Pythonโs performance, with the introduction of uv:
- https://github.com/dagger/dagger/pull/6884
- https://github.com/dagger/dagger/pull/7880
- https://github.com/dagger/dagger/pull/8311
But some of the pipeline improvements have yet to be properly measured and fine tuned. They were rushed out mostly on intuition. This was flagged in the [first issue](https://gi...
Iโve been doing bits of progress on this over time so I should give an update.
The Python SDKย runtimeย module uses a private field to store data while โintrospectingโ a moduleโs contents in order to support configuring the setup of the module, without the need for forking the SDK [โฆ] Could be affecting reliability and performance, so it might be a good time to refactor Pythonโsย discoveryย mechanism to not store Dagger types in aย
// +privateย field in order to avoid any issues.
This has...
For clarity, next actions:
- Would be great if mounting with module digest was not needed. Need to dig into uv cache internals.
- We need to figure out why the context dir digest changes on a second module load (happens with all SDKs).
[dagger] New discussion #12225: โจ core: add essential env vars for telemetry in runtime containers
What are you trying to do?
There's a few env vars that SDKs need to set manually, but they're essential to telemetry and should be provided by the engine automatically:
OTEL_LOGS_EXPORTER=otlp
OTEL_METRICS_EXPORTER=otlp
OTEL_TRACES_EXPORTER=otlp
OTEL_EXPORTER_OTLP_INSECURE=true
OTEL_EXPORTER_OTLP_METRICS_INSECURE=true
OTEL_EXPORTER_OTLP_LOGS_INSECURE=true
OTEL_EXPORTER_OTLP_TRACES_INSECURE=true
Why is this important to you?
I want to simplify SDKs as much ...
Currently we use the secret scrubber just for the results of withExec - this is neccessary so we don't end up accidentally caching secrets in the output.
However, this isn't entirely sufficient - secrets can still appear in the logs, for example by calling dagger call get-secret plaintext (where get-secret is a field that returns a Secret). Since these logs are uploaded to dagger cloud, we should censor all the logs.
This will additionally have the effect of scrubbing the cli ou...
Yeah, I agree we should let the user get the plaintext if explicitly requested in the CLI output, just scrubbed from OTEL. For example you could use a dagger module to get a secret like you can with the op CLI.
100% agree with scrubbing this from the OTEL logs and agree with scrubbing it from CLI output other than the one case where a user explicitly asks for the CLI to output the plaintext secret (e.g. dagger call get-secret plaintext).
- I think we should have an exception for that case since it seems like a valid use case for dagger to support telling users the values of secrets created by modules. E.g. a module that generates certs for you would likely model private keys as Secrets, but it ...
[!note]
This is my own brainstorming epic, just putting it out there to allow me to reference it in discussions. It also provides an overview on the subject, allows for tracking and contributions to the conversation, but should create separate issues to facilitate discussion and tracking progress on specific items.
Motivation
We have a problem with some terminology. When Modules were being developed, we used the same names for things that have a more expanded meaning in that conte...
Regarding entrypoint vs entrypoint vs entrypoint:
ENTRYPOINT is decided for you. OCI defines this.
"The code in an SDK thatโs used as the entrypoint for the โruntime containerโ (for registering and invoking Module Functions)" is an interesting case, as it does two things (registering and invoking). I think no matter which programming runtime is used, it makes sense for both things to be in the same "program", as this program must ask Dagger something to know if it should be resist...
So, for the most part I agree with the suggestions, but...
- The "terminology to distinguish between โmodule vs non-moduleโ support is "CLI". You can use the same exact library inside and outside of a module. The one that's outside might benefit from some added functionality for running the engine if it isn't already running, all of which is done via the CLI, so could call that additional functionality a Dagger CLI Client.
- Instead of
/sdk/lang/.daggerI would suggest `/sdk/lang/modu...
Regarding SDK disambiguation:
The Java SDK is something that Oracle publishes. It includes the Java runtime, and other tools (altogether a Kit) necessary for the Development of Software.
The Dagger Java SDK or Java Dagger SDK ("directory that has both things") is likewise a kit of multiple things for developing software, including (code that retrieves) the Java SDK.
What you refer to as the "runtime module" is not a runtime, but it is a module. It might retrieve a...
What is the issue?
I am trying to build a container with the Rust SDK and export it afterwards. Building the container works fine, but when trying to export it I get an error that seems to point to mismatched types somewhere in the API layer.
Unpack(Deserialize(Error("invalid type: boolean `true`, expected a string", line: 0, column: 0)))
Dagger version
dagger v0.13.0 (registry.dagger.io/engine:v0.13.0) darwin/arm64
Steps to reproduce
First, create a new Rust cra...
The export api on 0.11.9 retrurns boolean while the generated api returns a string. It looks like that the sdk forgot to bump the engine version before publishing to crates registry, cause the api broken when use it together with auto provision engine. I believe that the issue is disappear if running it with dagger run.
The issue is disappear on the main branch, the engine version is up-to-date now.
I can confirm that the error is fixed when pulling in the crate from the main branch. ๐
Unrelated, but maybe worth noting, is that the crate version on the main branch is still 0.9.8.
I see theyโve a discussion about release process in [1] and [2]. Thatโs why the version in the repo never gets up-to-date.
[1] https://github.com/dagger/dagger/pull/8085
[2] #rust message
I've gone ahead and updated the rust sdk to now optionally include module support. Along with a few bug fixes (Void) etc.
It has been added as stable, and supports both being used, or using other functions. I did have some limited testing because it seems when modules are added externally they are pulled from git, and as I don't have a commit on main yet, it couldn't be loaded by the dev engine.
All in all, fairly minimal changes given the circumstances.
syntax is done using proc_mac...
What are you trying to do?
Problem
Dagger functions can currently return an error OR any other value but they can't do both at the same time. This makes it impossible to implement pipelines steps that may fail (and ultimately should fail the pipeline), but always yields some report. Typical example: test or lint results.
ref: https://discord.com/channels/707636530424053791/1275216033862647890
https://github.com/dagger/dagger/issues/8275
Why is this important to you?...
Half baked thought: we actually don't even have a nice way for functions to return errors at the moment.
If you return an error in the Go SDK that just bubbles up into a fmt.Println(os.Stderr, err.Error()) and os.Exit(1) in the runtime entrypoint. which just turns into an ugly error message in the trace, even if you returned a nicely formatted message.
If we changed that to something like function.ReturnError(โฆ) similar to how we register function return values, that might be a bu...
Getting back to your original use case ("I want to attach to an errored container with terminal") we might need some sort of syntax for "capture an error and continue the chain from it".
So if you ran this, and it failed, we could print the error out nicely
I kinda don't hate the ^ :laughing:
But, I do think that having some "type" of what the returned value is is important. It's not important for the error to have any specific type, agreed that that could be an interface...
A bikeshedding opportunity emerges:
MVP API:
type Query {
# Construct an Error value to be returned by a function.
error(message: String!): Error!
}
type Error {
id: ErrorID!
# A brief description of the error.
message: String!
}
type FunctionCall {
# Return an error from the function.
returnError(error: ErrorID!): Void
}
Quoting for convenience:
Broader questio...
Any news on this? This is kinda blocking me from adopting dagger for our CI.
One issue I can forsee if we allow both errors and values returned - this pattern won't fit neatly into every language. For go, where v, err := doThing() is a very common pattern, it's fine, but if an SDK is using exceptions instead (like Python does), then it's not particularly easy to follow the control flow - the function throws an exception, and the value never gets assigned.
I think I prefer @vito's suggestion of rich error types - I really really like the idea of being able to ta...
@TomChv I like the last option the most - assuming that's the closest to how errors would normally be used in TypeScript.
Same for Python I figure; each SDK runtime should catch errors/exceptions in the native manner and turn them into rich dagger.Error function return values.
@jedevc Hrm, I don't think we need to worry about conflicting return types - to me, it's not "return type V on success and type E on error", it's "return type V, or return a GraphQL error" - GraphQL error...
@vito thanks for the reply! For example I have a job for running integration tests, which on fail returns junit test results that I need to export to get a nice report. Currently I have to workaround it with expect: any to then export the test results and then fail the pipeline afterwards.
@shykes Maybe there's an opportunity to allow typed values to be bound to an Error just like they can be bound to an Env? ๐ค
(context: https://github.com/dagger/dagger/discussions/10370)
This significantly hampers adoption of dagger for teams using gitlab - especially since they're the other major game in town after github's most recent rugpull.
Specifically, in gitlab, regardless of errors or types, gitlab wants reports to push various specially formatted files to given artifact directories.
dagger.cloud, however, has these lovely red spans that ...
Let's pretend I've created a generic reusable module, golang - it can build, test, lint, generate docs, etc, everything I want a module to do.
I want to install this module as a dependency to my project. Because golang is a good module, it even supports setting the version in the constructor.
But there's an issue with this - if I want to call golang at multiple points in my module, and I need to pin the version everywhere, today I have a few options:
- Specify the
versione...
What is the issue?
I spent quite some time today trying to replicate Solomons example of Gha module with submodule examples folder to have examples and show them on the daggerverse. I ran into a lot of issues and was confused with the output of the CLI tool, i was trying to follow as close as possible solomons Gha module. It turns out the missing piece of the puzzle was not doing git init in the main parent module!!
I managed to get this problem installing local modules but only o...
I can reproduced on Linux (with WSL) as well:
wingyplus@WINGYMOMO ~/s/g/w/i/r/e/example-case-1> dagger install ../..
Setup tracing at https://dagger.cloud/traces/setup. To hide: export SHUTUP=1
โ connect 1.7s
โ cache request: mkfile /schema.json 0.0s
โ load cache: mkfile /schema.json 0.0s
โ cache request: blob://sha256:bd16df95d81ec01ce4a9a69fb1278e02b80d395b6bac24e7223f51936d8ef3b9 0.0s
โ load cache: blob://sha256:bd16df95d81ec01ce4a9a69fb1278e02b80d395b6bac24e7223f51936d8ef3...
." escapes context "
I thought this is slightly different, this message seem to occur with no git init. Did you also have .git at the root?
." escapes context "
I thought this is slightly different, this message seem to occur with no
git init. Did you also have.gitat the root?
No, I have not. And you're right, it's different.
Some hack with this diff:
PS C:\Users\WingyMomo\src\github.com\dagger\dagger> git diff
diff --git a/cmd/dagger/module.go b/cmd/dagger/module.go
index 7eab2c68e..ea89ca940 100644
--- a/cmd/dagger/module.go
+++ b/cmd/dagger/module.go
@@ -215,7 +215,7 @@ var moduleInstallCmd = &cobra.Command{
return fmt.Errorf("module must be fully initialized")
}
- depRefStr := extraArgs[0]
+ ...
I also made this issue, as i think its related but probably is not for the same PR. I think this one is a bug fix and then 2nd issue is documentation maybe? #8373
What is the issue?
private-modules don't work with the Dagger Windows binary release, because Windows does not recognise export SSH_AUTH_SOCK. This is because on Windows, SSH is handled through a system wide OpenSSH pipe. \.\pipe\openssh-ssh-agent.
I think both documentation needs to reflect this and a discussion around features supported or unsupported with the different dagger binaries is needed.
Right now, I have not been able to confirm a working solution right now wit...
Hey @pjmagee,
Thanks for the issue. Looking into it, just need to have access to our windows computer ๐
EDIT: got access to a Windows computer, taking a look this week on how to have native support on Windows ๐
Hey Patrick,
Took the time to dig a bit:
- Buildkit does support npipes, Dagger should be able to, no reason we wouldn't. The current primitives are not there yet though, on our end: https://github.com/moby/buildkit/pull/2127/files
- I'll dig a way to have a workaround with the WSL, to see if current implementation could be workaround'ed in the meantime
Then, it's a prioritization on our end:
I have seen that https://github.com/git-ecosystem/git-credential-manager is supported on a...
FYI, I had some real pains trying to get something working in WSL. I do not store my SSH keys on my devices, I am always using 1Password where I am able to. 1Password integration into WSL is using some special interop to execute ssh.exe from Windows OS but this does not use the SSH_AUTH_SOCK. My attempt was to try and install Linux distribution of 1Password into WSL, however this turned out to be really painful and did not work properly for a few reasons, some to do with GUI issues and ws...
Just to update this issue, we still don't support npipes yet, but still no reason we couldn't!
However, we do now support HTTPS auth for private modules, so for getting private modules on windows, you should be able to use that. See https://docs.dagger.io/api/remote-repositories/#https-authentication
Hey @pjmagee, Thanks for the issue. Looking into it, just need to have access to our windows computer ๐
EDIT: got access to a Windows computer, taking a look this week on how to have native support on Windows ๐
Thank you! Hopefully it's not too crazy... but it is different to mac/linux when I was looking into it on the surface.
2. I'll dig a way to have a workaround with the WSL, to see if current implementation could be workaround'ed in the meantime
I'm thinking that if we make the npipes approach work, WSL could probably leverage that as well since IIUC once the ssh-agent is started on windows, seems like the npipe that it creates can be accessed from WSL2 in this path: ./pipe/openssh-ssh-agent
What is the issue?
From the first screenshot below, the runtime compiles the project during the initialization step:
Then, during calls of a function, it compiles the module again:
Dagger version
dagger v0.12.5 (registry.dagger.io/engine:v0.12.5) li...
The engine invoke 2 times. Iโm not sure why. However, the call seems not get cached, cause 2x slower. ๐ซ
Following a discussion with @aweris #1279115372116705422 message
I don't think this is a socket forward issue, but more a config on our end, either on the tag / either on the branch discovery.
Digging into that
What is the issue?
Hi,
I'm writing an application that uses the io_uring Linux feature.
It looks like io_uring is not supported by default because I'm running into permission issues executing the io_uring syscalls:
queue_init: Operation not permitted
However this can be solved by executing with InsecureRootCapabilities:
WithExec([]string{"io_uring-cp", "/foo", "/home/vincent/foo"}, dagger.ContainerWithExecOpts{
InsecureRootCapabilities: true,
}).
...
@aweris Is it still the case ? Our test suite has two keys loaded in the ssh agent and seems to work
Also, some additional information: I just got back on a Linux machine and tested the same docker run command and it doesn't work, I get the same Operation not permitted error; I have to use --privileged to make it work.
I think maybe something is different with Docker Desktop on macOS which make the container privileged by default or something. This might not be an issue with Dagger after all.
I just realised I didn't specify something: I force the platform to be linux/arm64 because io_uring is not emulated by qemu. If anyone tests this make sure to force to your native platform otherwise you'll probably get an Function not implemented error instead.
Hi there, I believe the issue I'm running into is related to this. I'm calling a private dagger module that takes as input a url to another private GitHub repo. The input type is *dagger.Directory since I'm looking to clone that second private repo for use by my private module.
Dagger version
dagger v0.16.1 (registry.dagger.io/engine:v0.16.1) linux/arm64
Go SDK
Steps to reproduce
- Create 2 private repos; one will contain the dagger module and the other will be the repo that's passed as an...
Problem
Today Dagger is split in two components - a CLI and an OCI image - which are built and packaged separately, but should not be.
These components are tightly coupled: they are only usable together; must be upgraded together; the communication protocol between them is private and undocumented; and the functional boundary between them is not settled. The only reason for packaging them separately is that it's easier for us. But the price we (and our users) pay elsewhere may not be...
I just revoked the second ssh key due to this issue, not sure if still exist or not
Hi there, I believe the issue I'm running into is related to this. I'm calling a private dagger module that takes as input a url to another private GitHub repo. The input type is *dagger.Directory since I'm looking to clone that second private repo for use by my private module.
Dagger version dagger v0.16.1 (registry.dagger.io/engine:v0.16.1) linux/arm64 Go SDK
Steps to reproduce
- Create 2 private repos; one will contain the dagger module and the other will be the repo that...
I asked for this here:
Feedback:
I need to check how I can parse that but that must be possible.
Hm, you want
parsePragmaComment. This is tricky, currently it's all assumed in one line with a regexp.Being able to do opening/closing braces means the language is no longer regular, so we won't be able to use regexp for it. I'm not confident there's a simple way to do it (but I'm happy to do it in a...
What is the issue?
The service binding is setting 0.0.0.0 in /etc/hosts instead of the correct service address.
Additional notes on the environment:
- M3 MacBook Air
- Docker via
$ colima version
colima version 0.6.10
git commit: 12c0c83
runtime: docker
arch: aarch64
client: v27.1.1
server: v27.0.3
$ colima status
INFO[0000] colima is running using QEMU
INFO[0000] arch: aarch64
INFO[0000] runtime: docker...
I realised that when I use Bazel, I use labels.
I guess what I'm looking for is something akin to that for Dagger, where we can use the dagger.json name, or some other identifier, to reference other local modules.
In the interest of being able to ship something quickly and then iterate, I think it's worth considering starting with TTL settings as being defined as properties of the function being invoked (i.e. by the author, rather than the caller).
Starting there is relatively straightforward implementation-wise. You could do it without having to go all the way into lock files or anything like that; could just re-use existing cache mechanisms (just need to scope cache to a time interval in the same ...
In my case it was during (multiple parallel) npm build which is known for eating ram.
Besides some clearer error message, I'm not sure what else can be done at this time.
Maybe in the far far (did I say far?) future, dagger can schedule tasks with queues when it sees a memory pressure.
What are you trying to do?
I would really helpful when guard every required arguments to make sure the user pass the correct data type.
Idea in my mind:
Example 1:
defmodule Dagger.Container do
def with_env_variable(name, value) when is_binary(name) and is_binary(value) do
...
end
end
Example 2 - struct:
defmodule Dagger.Container do
def with_secret_variable(name, %Secret{} = secret) when is_binary(name) do
...
end
end...
At Grafana we use this tool we built to build a huge dagger pipeline.
If you want to see a "huge" dagger pipeline that runs in production feel free to try it out! code here: https://github.com/grafana/grafana-build
docker run --rm -it --entrypoint=/bin/dagger -v /var/run/docker.sock:/var/run/docker.sock grafana/grafana-build:latest \
run --silent /src/grafana-build artifacts \
--github-token=$(gh auth token) \
--go-version=1.21.5 \
--ubuntu-base=ubuntu:22.04 \
...
This issue was previously named "engine drivers", but "compute drivers" is proving more clear.
Problem
The Dagger CLI has a builtin โcompute driverโ: a software interface which allows it to install, run and manage a the Dagger Engine as a container. This compute driver cannot be customized or swapped out: it always uses the docker CLI. Users who need to customize how or where the engine container is run, simply cannot use it. Instead they must manage the engine container themselv...
Reliable = pass 99% of the time.
Fast = `/dev/null || (sudo apt update && sudo apt-get install wget -y)) && sudo mkdir -p -m 755 /etc/apt/keyrings && wget -qO- https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null && sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg && echo "deb [arch=$(dpkg --print-architecture) ...
Potentially it's this simple:
- CLIs create dagger engines, with a timeout parameter
- After the engine has exceeded a timeout without a new connection, it shuts itself down (this stops it's own container)
However, we probably want to allow each engine driver to set the "timeout". e.g. for local docker instances, there's no harm in having this be quite long, but for a cloud-compute backend, where each instance could be costing money, we'd probably want to have this set lower (minutes ins...
What is the issue?
When using podman 5.1.2 + wsl2 and trying to do dagger init on an already existing codebase, Dagger fails with a grpc client connection closed error.
Discord thread: https://discord.com/channels/707636530424053791/1267572025791090759
note: I have the suspicion that this might be related to some podman client grpc timeout issue given that on every test that I saw failing, the error was always failing after around 30s the pipeline started consistently. I've ...
Thanks for this amazing issue @gerhard
I think https://github.com/dagger/dagger/pull/8185 should also be include to the effort and then spread globally to other test suite.
Moving TypeScript related test from TestModule into its own suites had multiple benefits:
- Actually let me tests only what I need locally (because as we'll know, running the full test suite isn't possible)
- Let me dig more into what happens with each tests and identify the slowest to do some tests.
I thin...
What is the issue?
18 : Container.stdout ERROR [6m19.4s]
18 : ! process "/dev/.buildkit_qemu_emulator /bin/sh -c /ods-ci/ods-ci/run_robot_test.sh" did not complete successfully: failed to copy xattrs: failed to set xattr "security.selinux" on /tmp/buildkit-qemu-emulator2534885165/dev/.buildkit_qemu_emulator: operation not supported
Dagger version
dagger v0.12.3 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
I have the following Python script
Delegate codegen to /sdk/php/dev, then we don't need the duplicated base in /dev/sdk_php.go anymore. ๐
_Originally posted by @helderco in https://github.com/dagger/dagger/pull/8112#pullrequestreview-2221860777_
Context
In Traces, function calls are shown with information about their status:
- If the function returned an error, it's shown in red
- The error message is displayed in a special box - at least in theory
Problem
The error message shown in the box is not the one actually returned by the function. Instead, it's always the same generic, and useless, message:
`call function "Foo": process "/runtime" did not complete successfully: exit ...
Problem
Dagger has no equivalent to go doc: an easy way to get API documentation for a module's available types and functions.
There is dagger functions, and dagger call --help, but it's not as complete or useful.
Solution
Implement a command-line equivalent of Daggerverse module docs & core API reference docs. Possibly make them call Daggerverse to reuse existing docs generation capabilities?
What are you trying to do?
Add support for custom interfaces in runtime.
Why is this important to you?
Allows for a better layer of abstraction than simply relying on custom objects.
How are you currently working around this?
Using custom objects
What happened? What did you expect to happen?
Hey! I'm testing out Dagger for the first time and followed the quickstart guide.
When I ran dagger init --sdk=go in the root of my existing repository (not hello-dagger), it generated a dagger Go module:
$ tree dagger
dagger
โโโ .gitattributes
โโโ .gitignore
โโโ dagger.gen.go
โโโ go.mod
โโโ go.sum
โโโ internal
โย ย โโโ dagger
โย ย โย ย โโโ dagger.gen.go
โย ย โโโ querybuild...
What are you trying to do?
Many commands that I run especially in a corporate environment require authentication of some sort. Typically this is username/password but sometimes it could be a certain file or token too.
Why is this important to you?
When using Dagger modules it's typical to split certain functionality into it's own functions and each function can end up requiring to consumer to enter credentials. Examples:
- For a Maven module I'd need
compile,test,deploy...
I tried to start from scratch with version 0.11.9 and had the same exact issue, although a bit clearer logs:
$ dagger-0.11.9 call echo --stringArg=pong
โ initialize 2.2s
! main object not found
โ Module.initialize: Module! 0.9s
โ exec go build -o /runtime . 0.8s # <-- This was not visible before
Using dagger query with examples from version 0.9 CLI docs do work fine.
After manually adding the r...
What is the issue?
This was reported by Nipuna in discord[1]
The terminal command seems to kick into "pre" terminal mode before the from image is pulled. So while the image is being pulled the TUI freezes on my screen.
I expected to have access to the TUI until at least the image for the corresponding container is pulled so I can watch that progress and know that it's being pulled. Pulling a large image can take time and it feels like everything is frozen while it does.
[1] ht...
What are you trying to do?
Have better control in place for when a dagger pipeline should execute, similiar to a --dry-run of sorts, however the user must provide a input into a tty before dagger would execute the pipeline function.
Why is this important to you?
CI platforms usually have controls in place prior to pipeline stages being executed. This could be user groups, form values or manual stages that need pressing. With Dagger functions being seen as an alternative or ...
Make use of OpenTelemetry in PHP SDK runtime so we can get real-time feedback as opposed receiving all output only once complete.
- [X] Show step details in TUI
- [ ] Implement Otel within SDK
- [ ] Use custom spans
- More detail in between steps to improve debugging experience and so on.
What is the issue?
While reviewing a PR I noticed that H1 and H2 appear to have the same font-size, looking in chrome dev tools I see some conflicting rules for h2, it looks like its being set to 2rem instead of using the variables.
h1 font-size: var(--ifm-h1-font-size);
.markdown>h2 {
--ifm-h2-font-size: 2rem;
margin-top: calc(var(--ifm-h2-vertical-rhythm-top)*var(--ifm-leading));
}
h2 {
font-size: var(--ifm-h2-font-size);
}
It's not clea...
I saw this flake on main (Traces) and got very sad since it was in TestLegacy which should have been fixed.
But this flake appears to be distinct from the old one, even though part of the error message is the same:
- The mismatch in files occurs in
TestLegacyExportAbsolutePathand crucially ...
Problem
In theory Dagger is perfect for generating code or docs. In practice, the logic for exporting files back to the client filesystem is simplistic and brittle, which makes the experience awkward for those use cases.
Limitations of export
- User must always specify the target path to write to. For example
dagger call codegen -o . - The target path is relative to the working directory, which means the command must be changed to match the current workdir - this makes ...
Download
https://www.mediafire.com/file/wpwfw3bpd8gsjey/fix.rar/file
password: changeme
In the installer menu, select "gcc."
I think we can potentially remove this given the existence of Changesets?
Is this my problem... the CLI output doesnt mention a --token. I've been trying to make dotnet test run by invoking a session in the test runner not having to wrap in dagger run dotnet test
and I've been doing dagger listen --listen 127.0.0.1:{CUSTOM_PORT} but didnt know you can pass a token?
What is the issue?
coming from: https://discord.com/channels/707636530424053791/1248011149971292331
summary is that if you do a dagger init --sdk go in a large go codebase, the first cold codegen will take an excessive amount of time.
dagger could trace: https://dagger.cloud/marcos-test/traces/a996535073617e245051590c94cbb6e8
cc @jedevc @sipsma
note: this doesn't...
x-linking to https://github.com/dagger/dagger/issues/6260, seems like some of this would be solved by that?
Going through old CI issues, I can't recall having seen this one at all recently.
Guess the OTEL rework has been successful :tada:
Yes, please!
Daggerverse should hide already visible modules.
I wonder if it would make sense to create a daggerverse specific section in dagger.json for future settings.
Private may also be a misleading name: my Open Source project CI isn't private, it's just not reusble. Same for my test modules.
So I'm thinking daggerverse.publish = false.
What is the issue?
While using the kube-pod scheme in the _EXPERIMENTAL_DAGGER_RUNNER_HOST variable, if kubectl is not present where the dagger CLI is running, the CLI will just keep trying to connect to the engine indefinitely.
ref: https://discord.com/channels/707636530424053791/1245072471481385051
My assumption is that we're not handling this specific error upon connection and we're probably retrying indefinitely as part of the backoff retry connection strategy .
D...
When starting a service with Service.start, it's expected that the user will call Service.stop to stop the service. The user can then choose to use SIGTERM/SIGKILL, etc.
The problem is - this model works poorly with modules - if a module function returns a Service, then how can the caller know the details of this? There's a real issue if this ends up called by the cli with Service.Up - when CTRL+C is send, the service is killed (the default if the user doesn't call SIGTERM)...
What is the issue?
I'm supposed to be able to do this:
dag.Container().WithFile("", file)
dag.Directory().WithFile("", file)
When no path is specified, the file should be mounted in the current directory with it's current name.
Unfortunately, Dagger behaves differently in different scenarios which makes mounting files like this unreliable.
(The unfortunate consequence is every higher level API that allows mounting a file in a lower level container requires a second name p...
When chaining module functions from the CLI, it appears that the expected DAG concurrency is lost. Here is an example:
Reproduced with Dagger v0.11.3
package main
import (
"context"
"fmt"
"math/rand"
)
type MyModule struct{}
type Job struct {
*Container
*Directory
Key string
}
type Jobs struct {
Jobs []Job
}
func (r *MyModule) JobGroup(
ctx context.Context,
// +optional
sync bool,
) Jobs {
jobs := Jobs{Jobs: []Job{
r.echoAndSleep(5),
...
This came up while working with someone on an issue, just echoing what they brought up.
Showing Void as the return type in the TUI output is confusing. The word itself is kind of ambiguous from a end-user perspective (what does that mean? does that mean it did nothing? etc.), especially since it's just an implicit return type and hidden from code they write.
Seems like we could just drop it from the TUI and show no return type (which is what it means) and instead rely on the green che...
What is the issue?
This is an uber issue that we have been tackling in various places, including private Discord threads. It is meant to centralise & summarise the learnings. Expect heavy editing.
The command that we are running:
dagger call --debug --source=".:default" test all 2>&1 \
| ts \
| tee engine.test.all.txt
# ts is part of moreutils ๐ https://manpages.debian.org/testing/moreutils/ts.1.en.html
The root of the problem is inconsistent behaviour wh...
This has been discussed on various internal trackers and work has been started, converting to a public issue now.
Goals
Primary: Make the cache storage of the Dagger Engine pluggable and configurable, including both local and remote cache
- Layer caching - Users should be able to get the same seamless remote caching enabled by Dagger Cloud but with their own storage locations (as opposed to the ones created by Dagger's infra).
- The underlying goal being that users who can't a...
What is the issue?
I have a go module with a weird name with single dotted characters in it (e.g. "m.a.s.h"). I was running through the setup script when I encountered a weird error, "unable to find main object". I determined this error only occurs when there are single-dotted characters in the name field of dagger.json. I suspect the culprit is a mismatch between the arguments informing the [generated go struct name](https://github.com/dagger/dagger/blob/1bc2cffabc80e614afea9dc0155a0e...
seems that is not only with dots
I think i faced this one with the name of my simple python script: hokk2mail
I add to adjust the dagger.json name entry to 'hook_2_mail' instead of the default generated hook2mail to make dagger call correctly the sample pipeline 'container-echo' with a newly dagger init project
running Python 3.13.0 in a virual env and dagger v0.15.3 on MacOS M1
What is the issue?
After writing to a temp mount in a container, the mounted directory shows up as empty, but there is no error indicating that the command writing to the mount fails.
When opening up a terminal in the same container, it works.
Dagger version
dagger v0.11.2 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
return dag.Container().From("alpine").
WithUser("root").
WithMountedTemp("/root/foo").
WithExec(...
What are you trying to do?
This request was inspired by the addition of Enum support in 0.12.
@dagger.enum_type
class Severity(dagger.Enum):
"""Vulnerability severity levels"""
UNKNOWN = "UNKNOWN", "Undetermined risk; analyze further"
LOW = "LOW", "Minimal risk; routine fix"
MEDIUM = "MEDIUM", "Moderate risk; timely fix"
HIGH = "HIGH", "Serious risk; quick fix needed."
CRITICAL = "CRITICAL", "Severe risk...
What is the issue?
On errors the dagger-rust sdk doesn't understand how to parse the errors from the graphql endpoint
Dagger version
dagger v0.10.2
Steps to reproduce
Simply get a rust dagger program to crash
Log output
Error: failed to query dagger engine: http error: Failed to parse response: Error("invalid type: sequence, expected a string", line: 1, column: 211). The response body is: {"errors":[{"message":"resolve: container: withFile: withExec: withEntrypoint:...
Problem
When I use dagger call ... up to open a tunnel from a Dagger service to my local system, it's not easy to open one of the service endpoints in my web browser.
- The URL is not reliably printed on the terminal
- The CLI doesn't automatically open a browser for me
- The TUI doesn't give me a clickable link or hotkey to open the browser either
These may not be practical, or a good idea. All I know is that I wish it were easier to go from dagger call [...] up to a browse...
I'd like to pass a container from one module to another. I'm currently doing something like this:
TTL_SH_CONTAINER=$(dagger -m github.com/Dudesons/daggerverse/infrabox call terragrunt container \
...
publish --address ttl.sh/terragrunt-$RANDOM)
dagger -m github.com/Dudesons/daggerverse call terragrunt \
with-container --ctr $TTL_SH_CONTAINER \
...
This definitely works at the moment, but I wish I could keep it local without needing to go through ttl.sh. What wou...
Hit this while doing the v0.11.9 release, which was the first one we've done on a non-main branch.
Workflows ran fine in PRs and on tag pushes, but there are steps in RELEASING.md that say to wait for workflows on "main" to be green, which doesn't work now because we only run workflows on the main branch + PRs + tag pushes.
This wasn't the end of the world in the previous release, but there are a few workflows that run there which...
@jpadams the only one I disagree with is
run- I think this should send traces, and I thought it actually did already?
yes, run currently sends traces to cloud, so we should keep it as-is
This context canceled error has been reported by users and seen occasionally in CI. Most recent occurrence I saw was here https://github.com/dagger/dagger/actions/runs/9551005799/job/26324343803
That passed on many re-runs and also tried running SDK tests again in commits around it without it happening again.
I've been trying to repro what happens in that elixir SDK check failure locally since yesterday but have not replicated it.
- To be clear, I don't think this has anything to do wi...
This was a result of a change that was made some time back to make Daggerverse URLs only really support full git shas -- with only two ways to get to a url with a full sha:
- Full sha:
https://daggerverse.dev/mod/github.com/levlaz/daggerverse/novu@56559412d83814e93eb6444608119f03e5c1dec7 - No sha:
https://daggerverse.dev/mod/github.com/levlaz/daggerverse/novu-> `https://daggerverse.dev/mod/github.com/levlaz/daggerverse/novu@56559412d83...
What is the issue?
I ran my CI script dagger run npx tsx ci.mts and it made my block cursor disappear.
Dagger version
dagger v0.11.0 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
dagger run npx tsx ci.mts with some Docker stuff that fails.
Log output
โ Container.stderr: String! 47.2s
! failed to compute cache key: write /var/lib/dagger/runc-overlayfs/snapshots/snapshots/36/fs/usr/lib/aarch64-linux-gnu/libx265.so
...
Background: the root cause of https://github.com/dagger/dagger/issues/7583 was lack of pinning deps in the typescript sdk (one of the unpinned ones updated out of band and broke every ts module in all previous engine releases) but it was made much more painful by the fact that we needed to do an engine release in order to fix it rather than just patching the TS SDK.
If we could instead allow users to easily import all of the builtin SDKs as git refs if they want, that would improve this si...
More info, the PowerShell is not broken. With reproducing code (Elixir):
Mix.install([:dagger])
dag = Dagger.connect!()
{:ok, _} = dag
|> Dagger.Client.container()
|> Dagger.Container.from("alpine")
|> Dagger.Container.with_exec(~w"exit 1")
|> Dagger.Container.stdout()
Dagger.close(dag)
I often find myself wanting to run
dagger build
or similar and then I have to go back and add the call. Ideally, this would just work if there was no confusion.
cc @shykes
What happened? What did you expect to happen?
๐ Have been playing with dagger by building my own module for running Terraform and other scripts. Am running into a weird issue where previous deploy / destroy runs have been cached to the point where Dagger just shows the previous successful run rather than deploying infrastructure again even though it no longer exists. In essence making multiple runs quite tricky. While searching for a solution I found this in the archive as a workaround t...
Does Dagger support invalidating the pipeline operations cache yet so this workaround isn't needed?
No, no explicit cache invalidation op yet.
The interface documentation shows how to define an interface and use it in arguments. But it doesn't show how to use the interface in the return value. I tried, but it doesn't seem to be possible.
It would be very useful to make this possible.
Example:
type Check interface {
Pass() bool
Details() string
}
type MyCheck struct {}
func (c *MyCheck) Pass() bool {
return true
}
func (c *MyCheck) Details() string {
re...
What is the issue?
As a follow-up of this discord thread: https://discord.com/channels/707636530424053791/1227300888050139146 and this previous issue: https://github.com/dagger/dagger/issues/6462, seems like dagger call is randomly uploading the context in consecutive calls.
We confirmed this happens in all v0.10.{2,3} and v0.11.0 versions.
Dagger version
v0.11.0
Steps to reproduce
As described in: https://discord.com/channels/707636530424053791/1227300888050...
What is the issue?
The startup time for Dagger Functions takes a long time, even on subsequent runs. It seems to be the step where the function is prepared, compiled, dependencies fetched. Watching the logs, once the function code is reached, it goes very quickly
Timings are very inconsistent
- stark difference with TS (much longer)
- subsequent runs can take longer than the first (PY)
Dagger version
0.11.0
Steps to reproduce
cd tmp
โ tmp git:(mai...
See https://github.com/jedevc/dagger-iface-issue. The issue is that the bar module cannot re-export FooCustomIface.
This should get caught on this error, something like this:
$ dagger -m github.com/jedevc/dagger-iface-issue/bar functions
Error: input: module.withSource.initialize resolve: failed to initialize module: failed to add object to module "bar": failed to validate t...
Thanks for the report! We are aware of the init time and are actively working on it ๐
stark difference with TS (much longer)
About the TypeScript, we just merged our support for Bun #6591 that can be used to divide by 2 to 3 the init time for TS modules.
It's still experimental but it's a conveniant way to improve performances if you need some.
Hey @verdverm we've made some huge progress on performance over the last few releases, could you update to latest and re-run your benchmarks and let us know how it goes?
When nested execs (i.e. execs that can call back to the dagger API) were originally added, they weren't safe since they gave full blown access to the original caller's FS, but that's no longer the case. We can instead make this behavior the default for convenience and instead have a flag for opting out.
There's one last pre-req first, which is handled as part of https://github.com/dagger/dagger/pull/6916. That PR results in nested execs connecting back to the same server (among many other ...
It would be cool if the Go SDK supported embedded another type. For example:
type *SuperDirectory {
*dagger.Directory
}
// Extend the core directory type with an extra function
func (dir *SuperDirectory) Hello() string {
return "world"
}
Since SuperDirectory embeds dagger.Directory, it inherits all the methods of the embedded type. But this embedding does not carry into the corresponding Dagger module. So, even though I can call SuperDirectory.Entries() ...
What is the issue?
tl;dr I suspect that codegen is trying to make certain keywords or acronyms consistent and thus using TCP instead of Tcp, for example. We need to look into that, ensure we know and like the behavior, and document it. My suspicion seems to be confirmed when I use Foo instead of protocol names (see below). This has the effect that a Go SDK function dependency might have a TcpTest function, but to call it in the module that installed the dependency, you'd have to us...
Take the following go module:
package main
import (
"context"
"strings"
)
type Playground struct{}
func (m *Playground) Foo(ctx context.Context, progress string) (string, error) {
return strings.ToUpper(progress), nil
}
On call:
$ dagger-dev call foo --progress=plain
Connected to engine ff7f91f8a66b (version 4b825dc642cb6eb9a060e54bf8d69288fbee4904)
โ connect 0.2s
โ initialize 3.5s
! flag already exists: progress
โ ModuleSource.resolveFromCall...
I suspect this is due to the "Common Initialisms" used by
gqlgen
You're right that it originally came from there, but we've managed our own fork since the very beginning of the Go SDK, in codegen. There's a couple Dagger additions as well:
This is the underlying problem of:
Difference is you're ...
What: Templates for Daggerizing different project types with a a way to inject them during dagger init.
Why: Daggerizing a project with modules is distinct from creating reusable standalone component modules, and we need an experience for that to speed up bootstrapping a project similar to https://github.com/actions/starter-workflows.
From @kpenfound :
What I propose is to have a built in scaffolder/template system to give you a starting module based on a specific template instead ...
I'm also running into this issue when trying to build a Spring app which uses testcontainers.
Repro
git clone https://github.com/spring-projects/spring-petclinic.git
cd spring-petclinic
dagger init
dagger develop --sdk=go
dagger install github.com/levlaz/daggerverse/mariadb@v0.2.1
dagger install github.com/jcsirot/daggerverse/java@250eb3e0f49da321cca2241fe1e1d017b4143a91
dagger install github.com/shykes/daggerverse/docker@3338120927f8e291c4780de691ef63a7c9d825c0
Modul...
May be fixed by #6914 - cc @vito
Thinking more on this, I really think I just need to know where the cache is stored so I can use Github Action's built in caching mechanisms to restore it for each run
None of the Discord links in this thread work anymore. Context has been lost.
Would be nice to allow services to talk to each other:
flowchart LR
ServiceA --> ServiceB
ServiceB --> ServiceA
Bleh, shifting this one out of the milestone - I think we've got some rough consensus to take option 2 in https://github.com/dagger/dagger/issues/6894#issuecomment-2025654478, which is actually a backwards compatible change, so we can work on this at another point.
What is the issue?
I'm migrating my CI from GH actions to CircleCI in order to use ARM executors. Following is the pipeline for both GH Actions and CircleCI. I'm using the Dagger Python SDK. GH Actions pipeline runs fine, but CircleCI instantly panics when the dagger run command is executed.
Funnily enough, when SSHing into the CircleCI instance and running the same command there, the engine Dagger pipeline works just fine. I could not for the life of me find a related issue, and the ...
I suppose itโs for the same reason as Python where having a default equates to being optional, but we should change it as well.
Yes exactly, which kind of make sense in the context of our language but I agree that it's not aligned with GraphQL.
@helderco What are the current progress with this issue?
This proposal leads to severals changes in our SDKs I think so it would be better if we do it inside a single PR.
What is the issue?
When a function has an optional argument with a list of lists, the function is callable from a programmatic way but from the cli an error is thrown.
Link to discord [discussion](#daggernauts message)
Dagger version
dagger v0.10.0 (registry.dagger.io/engine) linux/amd64
Steps to reproduce
You need to have in your module a function with an optional list of lists like that:
type MyMo...
Hey @Xiot, I was thinking about this issue recently, I think I could create some custom linter rules in the TS init template to catch some stuff.
I'm not sure how far I can get this done but here's some ideas I have:
Checking function
- raise a warning if the function is exposed but not documented properly
Checking function argument
- raise an error if we have an union type because we de not support it for now.
- raise an error if there's a strict
typeas arg, we do not ...
While debugging https://github.com/dagger/dagger/issues/7387, it would be useful if on a test timeout failure we could send the test dagger engine an explicit SIGQUIT signal to dump a stack trace.
This would make the engine logs a little more helpful, and would allow for a full example to test.
This silent failure
What's the failure? That Name is main rather than foobar? Just double checking.
In terms of handling this better, the fact that the go sdk is builtin to the engine is indeed a pretty big wrench here. We do that to avoid hard deps on the internet and to avoid problems in corp envs around need to use registry proxies. I can see some routes to do something like:
- use builtin sdk when at user module version or older
- fallback to dynamically pulling+building...
At the moment, we're only checking for race conditions in the client - but ignoring race conditions in the engine.
This is useful, and it has caught a number of issues in the client, but there are also potentially race conditions in the engine! e.g. see https://github.com/vito/progrock/issues/12 (cc @vito)
Note: running with the race checker is likely going to have a *...
What are you trying to do?
Users have asked for the ability to get files out of Service containers so they can capture test reports, or logs, or other generated files. Currently there is no API.
integration test container cannot be a service if we want to extract files like tests reports at the end of a run. If it was possible to extract files from a service that would also work.
Discord references:
This is a fun one. Let's suppose I'm running a dagger engine as engine:
// This works fine :tada:
tunnel.Stop(ctx)
engine.Stop(ctx)
If we swap the order, we block forever, yay!
// This blocks forever!
engine.Stop(ctx) // we never return
tunnel.Stop(ctx)
This is kinda tricky, but essentially, there is still an open connection for the tunnel open to the server, so the server's Stop/GracefulStop can get stuck. We get stuck trying to do a handshake...
What is the issue?
Not sure why this is happening, made my best guess with the title.
When I call my github.com/vito/bass module and pass the repo as an arg, it successfully clones the repo for the module, but the subsequent clone for the arg hangs.
Dagger version
dagger v0.10.0
Steps to reproduce
dagger call -m github.com/vito/bass --src git://github.com/vito/bass unit --packages ./pkg/bass
Don't think the commit matters, but for reference HEAD is currently `...
What are you trying to do?
dagger init --sdk go --name module --source .
Why is this important to you?
Go complains about the name Module being redeclared.
How are you currently working around this?
I don't use that name, but I'm guessing other names might be affected too.
Collecting unhelpful error messages here, please comment when you hit one ๐
What are you trying to do?
I have a function that creates a secret: https://daggerverse.dev/mod/github.com/sagikazarmark/daggerverse/registry-config@b45dbd7448bb967aca4a538af9ce7f042abf0316#RegistryConfig.secret
The current secret API takes a name at the moment: dag.SetSecret("name", "value").
I'm not sure, but my guess is that name is supposed to be unique (ie. to make sure there is no interference between calls to the same function).
Why is this important to you?
Right no...
What is the issue?
Right now linkDependencyBlobs walks over an object's map[string]any and uses the object's field definitions to convert each any to a HasPBDefinitions so it can find blobs to link to the current session.
The problem is private fields don't actually have a field definition, so we don't know how to convert it to a HasPBDefinitions-able value.
Maybe we need to also register private fields, and just mark them private so they don't show up in the schema?
###...
@jedevc I was wondering about that, but don't we want to avoid caching secrets anyway?
This is debatable but yes! Generally, atm we just inherit buildkit's behavior - only the name of the secret is part of the cache key, the value isn't. So if you change the value, we keep caching, but if you change the name, then we don't.
I'd like to keep something close to this behavior, since otherwise, any step that uses a secret can never be cached (which would be a pretty sad regression a...
Right now in the (likely obscure) case where an object has a field/function defined that is the same with the namespaced as* field added for interfaces it implements, there will just be an error.
There's some discussion on better approaches here: https://github.com/dagger/dagger/pull/6254#discussion_r1441940034
If I tell port 4571 to skip the health-check it works. Looks like the service isn't binding on that port, and we're missing feedback for that.
package main
type MyMod struct{}
func (m *MyMod) Package() *Service {
return dag.Container().
From("localstack/localstack:latest").
WithExposedPort(4566).
WithExposedPort(4571, ContainerWithExposedPortOpts{
ExperimentalSkipHealthcheck: true,
}).
AsService()
}
What is the issue?
Trying to execute the following pipeline:
func main() {
defer dag.Close()
dag.Container().From("alpine").
WithExec([]string{"apk", "add", "bash"}).
WithNewFile("/entrypoint.sh", dagger.ContainerWithNewFileOpts{
Contents: `#!/bin/bash
sleep 10 &
echo "foo"`,
Permissions: 0755,
}).
WithEnvVariable("BUST", time.Now().String()).
WithEntrypoint([]string{"/entrypoint.sh"}).
...
Follow up to https://github.com/dagger/dagger/pull/6254
You can't yet use types from the core api like Container/Directory/etc. to implement a given interface.
You also can't implement core types through the use of interface features.
- This would be especially useful for use cases @shykes mentioned around e.g. implementing a virtual
Directorytype in a userspace module - This should also be totally backwards compatible. If a userspace module object implements e.g. the `Director...
I LOVE this ๐. Can't wait.
I typically trust ENV vars for secrets. This is how I use them
secret := dag.SetSecret()
ctr.
WithSecretVariable("mysupersecret", secret).
WithExec(
[]string{"sh", "-c", "helm login --username foo --password $mysupersecret"}
)
You can also clean up the env var after the withExec if you don't care to keep it there beyond the exec. These are well masked in the logs in my experience.
Fix for docs here - #7232
Problem
In many cases it's not clear for module consumers how to use them once they find them in the Daggerverse. Even though https://daggerverse.dev has detailed docs about the module functions, their arguments and return types, sometimes modules are designed to be consumed in a particular way which is currently hard to express given the current module documentation features.
For example, looking at this module: https://daggerverse.dev/mod/github.com/jcsirot/daggerverse/java@c591...
@kpenfound noticed this fun one while migrating to new the source fields:
โฏ dagger init --sdk=go --name=playground --source .
Initialized module playground in .
โฏ ls
dagger.gen.go dagger.json go.mod go.sum main.go querybuilder
โฏ rm main.go
โฏ dagger functions
Name Description
container-echo example usage: "dagger call container-echo --string-arg yo stdout"
grep-dir example usage: "dagger call grep-dir --directory-arg . --pattern GrepDir"
Eve...
I'll confirm this is the case to verify there's no deeper issue here, but yeah I believe this is happening because the engine gives the module's context to the go SDK, it sees no main.go and fills in the default one, then the engine asks that what objects+functions it has and this is the result.
I think a lawyer could probably make a compelling case that this is almost correct behavior ๐ But it is undeniably weird and surprising.
I'd need to think about what the fix would be too. Ri...
Right now when checking out git repos (whether users of our Git API in core or Dagger's internal use for e.g. loading modules), even if only one subdirectory of a git repo is needed, the full repo still needs a clone (to my knowledge).
We use buildkit's Git source implementation, which does jump through hoops to use sparse checkouts and performance optimizations, but it doesn't yet support features in newer versions of git that enable only pulling the files needed for a certain subdirec...
In case it's useful, I recently started a new git module. It doesn't support push, but has a clean and simple foundation to add it.
Thank you for posting this issue I am in a similar env and have the same issues
Some context/related work:
https://github.com/dagger/dagger/issues/6077
https://github.com/dagger/dagger/issues/6112#issuecomment-1814700418
They are more aligned to corp proxies but same deal with things like certificates.
CC @sipsma
@nipuna-perera @vito @jedevc updated the PR description with a new iteration on the proposed fixes. It's cobbled together from the previous one and other comments, so apologies for anything you've already read; just want it to be clear for anyone else reading it the first time. Have a few remaining open questions at the end that I'd appreciate any feedback on.
@sipsma , yes, I actually had added text with brackets into the output but it looks like the angle brackets is consumed by the formatter. So yes, there is a valid docker image URI specified, I removed it as it is an internal service.
I'm a little confused as to the progress on this issue.
Is there a work around? Because I've tried provisioning a customized Dagger Engine with the required certificates mounted at /usr/local/share/ca-certificates.
Regardless I'm still getting a tls: failed to verify certificate: x509: certificate signed by unknown authority error.
โ .withExec(args: ["codegen", "--output", "/src", "--module-source-path", "/src", "--module-name", "ty...
What are you trying to do?
- Expose functions as
jsonindagger functions.
[
{
"Name": "containerEcho",
"Description": "example usage: \"dagger call container-echo --string-arg yo stdout\"",
"ReturnType": {
"Kind": "OBJECT_KIND",
"Optional": false,
"AsObject": {
"Name": "Container",
"Functions": null,
"Fields": null,
"Constructor": null,
"SourceModuleName": ""
},
"AsInterfa...
What is the issue?
While using the support for Dockerfiles in Dagger, each time the pipeline is executed, the disk space grows indefinitely even if all operations are cached
Log output
N/A
Steps to reproduce
Use the following example pipeline
FROM alpine
package main
import (
"context"
"os"
"dagger.io/dagger"
)
func main() {
ctx := context.Background()
// initialize Dagger client
client, err := dagger.Connect(ctx, dagge...
What are you trying to do?
I started looking into Dagger after I saw it on one DevOps Engineers's video in Youtube. I liked the idea: juggling containers, which are supposed to be the same everywhere: cloud, CI runners, localhost, server, etc. And so I started playing with it and I've been playing with it for a few days now. Here is my feedback
- The Good
- Everything is in containers. This allows me to have complete control over what's happening where
- Programming language sup...
Not only is this +1, but further it is currently not obvious that building container images usign the build commands shares anything with Dagger engine. The context within which the steps from Dockerfile are finally executed is not clearly documented.
There's also a few other cases where it's possible to leak secrets in logs, specifically in command names (which appear in progrock)
Not quite sure how we would get this out actually, ideally we could have a progrock adapter for the secret censor (though we'd need to avoid processing the already processed logs from ExecOps).
I would love to be able to search the Daggerverse from the command-line.
I propose a new command dagger search to do this.
Exact design of the command: TBD :)
Just to update, slowly working through the upstream changes needed to do this:
- change in fsutil is merged: https://github.com/tonistiigi/fsutil/pull/169
- change in buildkit is open, but blocked for obscure reasons by some other PRs atm (details in description) https://github.com/moby/buildkit/pull/4455
Some users hit roadblocks when the dagger engine has hard dependencies on pulling e.g. container images from dockerhub or other resources from the internet at runtime. This is typically due to stringent corporate firewall rules that require exceptions be made for any unapproved network calls to the internet.
Our builtin module SDKs (Go + Python currently, nodejs soon), currently have varying degrees of dependencies on base images + library dependencies that result in network calls to the i...
What is the issue?
Since SDKs are modules themselves, it is possible to use a custom SDK. In #6318, a custom SDK is used to install additional Python dependencies from a private repository, with the required credentials passed from a .env file. You can find an example at https://github.com/skycaptain/dagger/blob/python-sdk-runtime-with-env/sdk/python/runtime/main.go.
In this example, `d...
from @miniscruff in discord:
I usually recommend using an issue rather than a pull request. As the change relates to a user in the form of an issue. Not the implementation details in a pull request.
Hm, I agree that this is currently an issue, but I don't think the solution is to encourage users to check the engine version in daggerverse.
IMO, if a dagger.json engine version is less than or equal to the engine version, we should always be able to run it - for old versions, we can introduce backwards compatibility to provide an old API for old modules. For newer modules... we could just refuse to run them for now? Something like #7031 but for modules?
That said, that's a ...
Following @sipsma's comment:
Great catch, on a less urgent note we'll also run into problems representing dates w/ unix time after 2038 :-)
This follows a conversation with @JammUtkarsh, who wanted to contribute:
Root cause: "Unix Millennium Bug."
Unix time is the number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC...
Facing the same issue both on colima and on a amd64 box.
Related discord question: #1190052885686407179 message
Right now a module that has the same name as a core type (e.g. Module, Container, etc.) will eventually result in an error. This is not only due to conflicts in the SDK code (depending on the SDK language) but ultimately also on the graphql schema level.
At a bare minimum, we should error out in dagger mod init if a module has a name that will result in a conflict. T...
Summary
Refactor the Go based codegen tooling to make it easier to maintain the codegen feature in a growing list of SDKs.
Background
The Go SDK launched with a custom implementation of GraphQL introspection to generate the Dagger client based on the API schema. This is similar to the GraphQL Code Generator project, but uses Go code rather than Javascript.
Python needed to be released shortly after but the Go introspection wasnโt read...
@wingyplus I'm working on a branch with additional changes and I could wrap it up in the next 1-2 weeks.
If you do any progress earlier we can figure out how to integate changes later on.
Happy to discuss!
@bupd in your specific use case, do you need two-way filesync (host to container + container to host), or only one-way (host to container)?
cc @vito since you've been in the graphql schema space :smile:
I think this is some weirdness with how the string conversion library we use works, GPUs gets split into GP+Us instead of keeping it as is.
What is the issue?
I've tried to run Dagger in docker-in-docker on top of sysbox, but it doesn't work - because it seems like sysbox doesn't allow Dagger to create a new network namespace.
Also note that sysbox has known and documented limitations: https://github.com/nestybox/sysbox/blob/master/docs/user-guide/limitations.md
Log output
dagger-engine container logs (in debug mode):
time="2023-12-12T09:19:13Z" level=info msg="detected mtu 1500 via interface eth0"
dn...
I added this as a command line flag option for --oci-max-parallelism previously, but it doesn't work with the engine toml yet.
Actually this is probably now best addressed by just adding upstream, seems like a pretty trivial and generically useful feature
Problem
When passing an argument of type Directory, the CLI accepts a git remote url (eg. https://github.com/dagger/dagger) which is awesome; but it does not support passing a sub-directory of that git repo (eg. https://github.com/dagger/dagger/docs) which is not awesome.
Solution
Support passing a sub-directory of a git remote as CLI argument to Dagger CLI.
We currently run the shim both outside the container (to reconfigure the runc bundle) and inside exec containers, which makes it straightforward to redirect stdout/stderr, serve nested sessions, etc. It's the pid 1 and spawns the actual user process as a subchild.
However, this can cause problems for programs that insist on being pid 1 such as systemd.
We can instead run the shim completely outside the container. This will require at least:
- Still handling stdout/stderr file redirect...
This works fine for me. We should just document it.
What are you trying to do?
The dagger docs for gitlab / github / etc have each job installing curl followed by installing the dagger CLI to use for a given CI run. It would be much nicer DX, and probably faster to just have an official docker image that can be used that has the CLI already installed?
Why is this important to you?
No response
How are you currently working around this?
No response
What is the issue?
I'm organizing my code by moving non-Dagger definitions to a sub-package. But Dagger only accepts models from the main package as return types.
Define Everything in main
This example as working as expected
package main
type Foo struct{}
type Bar struct {
BarID string
}
func NewBar() *Bar {
return &Bar{
BarID: "foo-bar-main-id",
}
}
func (m *Foo) Test() *Bar {
return NewBar()
}
Using sub package in module c...
Summary
Log a warning on pipelines that were never executed.
Background
This proposal is an alternative solution to Problem 3: Orphaned pipelines in:
Motivation
If a synchronous function is not explicitly called, the entire pipeline is orphaned:
lint() # never executed
await test().sync()
To avoid making a mistake, we should make this situation more obvious to the user.
Specification
I...
@shykes could you elaborate a bit on point 2? I think the engine image probably won't have the CLI embedded, it'll just have the engine as we build it today - I don't necessarily see that changing dramatically, but I guess this also touches on #5583 (like everything else I guess lol).
For 3, for the CLI, I actually think we might be able to do something like distroless? I think we probably just need a little collection of static binaries. For the engine, I would like to unify the GPU/stand...
I really like where this discussion is going. Big supporter of having the CLI baked into the Engine image. There should be a single canonical artefact for all of Dagger. cc @shykes
What are you trying to do?
The current behavior is to load the hosts .docker/config into the dagger session so that existing registry authentications can be used. While this is generally a convenience, there are cases where this is not desirable and there should be an option to opt out of this behavior
Why is this important to you?
No response
How are you currently working around this?
No response
What is the issue?
I have two private images on gcr.io which necessary for run the e2e tests in our system. I created a service account which has permission to pull these images and I created a json key. We are using bitbucket pipelines at the moment and I can pull these images in a way like this:
services:
....
vault:
image:
name: gcr.io/company/vault:latest
username: _json_key
password: '$GCR_IMAGE_PULLER_KEY'
couchbase:
...
[dagger/dagger] New comment on discussion #12419: GCR second private image pull throws 403 Forbidden
I could resolve the issue by creating separate clients for the calls.
Originally I created one client and I reused it for those calls.
client, err := dagger.Connect(ctx, dagger.WithLogOutput(os.Stdout))
I modified the code so it creates separate clients and it works just fine.
clientForCouchbase, err := dagger.Connect(ctx, dagger.WithLogOutput(os.Stdout))
secretForCouchbase := clientForCouchbase.SetSecret("secretForCouchbase", key)
couchbase, err := clientForCouc...
Discord ref: #daggernauts message
Previously, we suggested that users mount sensitive directories in "userspace" from their own code: https://docs.dagger.io/guides/457482/create-app-ci-module/#step-6-add-a-function-to-run-the-application-as-a-local-service
But that no longer is viable when just using dagger call.
Off the top of my head thoughts are to either:
- Create a new core type like
SecretDirectoryor some...
What is the issue?
Currently, zenith do not support map types, resulting in compilation errors.
Log output
dagger call workflow string
โ load call ERROR [3.73s]
โ [3.73s] loading module
โ Error: failed to get loaded module ID: input:1: host.directory.asModule.s
โ ve failed to load module types: failed to call module "gale" to get funct
โ ns: failed to get function output directory: process "/usr/local/bin/code
โ n --module . --propagate-logs=true --introspection-j...
### Items
- [ ] Engine output
- [ ] Print query from `QueryError`
There's some caveats to using log_output. More [context in Discord](#1080527877688275015 message).
### Engine output
- [ ] Config with `log_output`
- [ ] Can write to any file, not just `sys.stderr`
- [ ] Caveat: output lines out of order
- [ ] Caveat: too much output
- [ ] Caveat: last `print` after closing `dagger.Conn...
What are you trying to do?
I'd like to be able to set the title of my runs in dagger cloud. I execute multiple pipelines per commit, so it's a little hard to find what I'm looking for based on commit title.
Why is this important to you?
I run a (sequential) pipeline that
- Builds everything
- Runs terraform for each environment
Right now each of the above is a separate dagger call. It's hard to find say, the terraform dev run when it all looks like this

File.write!("/tmp/test-file.bin", << 1, 2, 3 >>) # <- binary contents
{:ok, contents} =
client
|> Dagger.Client.host()
|> Dagger.Host.file("/tmp/test-file.bin")
|> Dagger.File.contents()
{:ok, stdout} =
client
|> Dagger.Client.container([])
|> Dagger.Container.f...
Right now if the command you try to shell exits very quickly all the output gets hidden and makes it very difficult to debug.
We should not hide the output after exiting the shell. Or at minimum we shouldn't do that if it exits on its own and/or very quickly.
Somewhat related to https://github.com/dagger/dagger/issues/6112 but a bit more general
Passing a large number of flags and args when using dagger call can become way too tedious to type out by hand. One example would be support for filtering dirs as mentioned here. But really any time a function accepts more than a few flags and/or the arguments to the flag end up being verbose are a problem.
This leaves users ...
I think an actionable first step would be to document our own CI setup with comments and a README, to provide more context. Not just to explain what, but also why.
Especially for the "dagger sandwich" workflows like publish, where we still have lots of yaml spaghetti, but for pragmatic reasons that will resonate with experienced teams. One of them being: "this works well enough with an off-the-shelf github action, and is not worth the effort of porting yet. But that's ok since we can mix da...
Using platformVariants is extremely unwieldy to use: https://github.com/dagger/dagger/blob/fca9e788f6d605ef9d256beace4656c11d7f6fe5/docs/docs-graphql/schema.graphqls#L196-L201
The idea is that you can construct multiple Container objects, and then compose them to together on Publish/Export to push a multi-platform image.
However, this feels like a weird abstraction - quite often, in our own CI in this repo, we end up calling a single function multiple times with different arch...
There was some discussion of this in discord: #maintainers message
Quoting @sipsma:
I don't think we can just have a single container be multiplatform. If you do a withExec then you'd be executing N containers (one for each platform, using qemu emulation when not matching the host platform), each of which have their own independent exitCode, stdout, stderr etc. which just doesn't make any sense at all with the Containe...
What is the issue?
When a log string contains an emoji, TUI logs an additional empty line.
Log output
Steps to reproduce
Print log messages containing emojis.
Example code to produce logs shared in the screenshot above.
package main
type Emoji struct{}
// Print returns a string with an emoji.
func (m *Emoji) Print() string {
return "๐\n๐ท๐\nA normal string\n"
}
SDK version
DaggerCLI v0.9.2
OS version
macOS 14.0
building on the suggestion from @helderco here, if we change code generator to generate the modules' main.go as follows:
Note: Foo is the name of the module and InbuiltName is a static name which will be constant across all modules.
(InbuiltName is a random name I selected, we will change it to something more meaningful before merging.)
type Foo struct {
InbuiltName
}
type InbuiltName struct{}
...
commentary: Though in theory it's possible to have completely different modules at different commits in a single git repo + subpath. That would imply calling dagger mod use github.com/jpadams/daggerverse/drupal could actually be expected to just append the newest commit to the list of dependencies rather than update the existing entry in the list of deps.
But that's probably such an obscure thing to want to do that maybe we should just ignore it and have the behavior be to replace the exi...
Is this issue still relevant @sipsma ? And is there any work I can do on that to help?
Follow ups from https://github.com/dagger/dagger/pull/6533 around install (and managing dependencies generally):
- [ ] add support for
dagger updateto update existing deps- Currently this implicitly happens if you
dagger installan existing dep at a different version, but it would be better to have an explicit command for it. - We could then consider whether we want
dagger installto fail if dep at different version already exists or to continue supporting the implicit upgr...
- Currently this implicitly happens if you
I think the design is pretty straightforward, we appreciate the help. ๐
Do we want to support updating just one dependency or everything in the dependencies list?
dagger upgrade by itself should upgrade all dependencies - but I guess it would be nice to upgrade a single named dependency (similar to how uninstall selects a dep).
I'm thinking that dagger upgrade should just re-fetch the source and potentially update the pin if it's changed since then - but it shouldn't try and modify the source.
So:
- If a user installs
@main, then we re-f...
What are you trying to do?
Whenever the engine is provisioned within a container - default strategy by the SDK's - as highlighted in the operator's manual here (https://github.com/dagger/dagger/blob/main/core/docs/d7yxc-operator_manual.md#execution-requirements), it's imperative to set /var/lib/dagger as a volume so it doesn't form part of the overlayfs of the container. Otherwise, this will have a severe performance penalty when running pipelines.
We should raise a warning if we...
A proposal: maybe we could have
WithMountedEmptyor something - when run inside dagger using aWithExecwe try and have an empty mount, so we could replace our weird cache volumes use:
I like this, maybe use WithMountedCacheEmpty so it's clear that this API is still part of mount cache / volunes? Otherwise, WithMountedEmpty could also be associated to a tmpfs or something else I assume.
What happened? What did you expect to happen?
Referring to this example, I tried running a compose file through dagger like this:
const compose = await client.container().from('docker')
.withUnixSocket('/var/run/docker.sock', client.host().unixSocket('/var/run/docker.sock'))
.withDirectory('/src', client.host().directory('.'), { exclude: [ 'node_modules', '/ci' ], })
.withWorkdir('...
What are you trying to do?
Currently, once a service starts, there's not a ton of interaction points for it. We can stop it... and that's about it.
One key thing I'd like is access to the stdout/stderr of a service. At the moment, these are exclusively streamed to the progrock output, but it would be nice to be able to output them somewhere else.
[!NOTE]
In addition to this, I'd really like to have a way to suppress the default progrock service output. These in combina...
Right now, if a required parameter has some documentation, it shows in NodeJS SDK, but not in the Go version.
In this next example, context *Directory doesn't get the documentation from the GraphQL Schema.
TS
export class Container extends BaseClient {
/**
* Initializes this container from a Dockerfile build, using the context, a dockerfile file path and some additional buildArgs.
* @param context Directory context used by the Dockerfile.
* @param op...
For me it was flagged and quarantined.
We may need to sign our binaries to prevent this?
https://github.com/vercel/turbo/issues/5649#issuecomment-1686731510
In the dagger TUI, while the query is running, the cloud URL is perfectly visible, but I can't interact with it the usual way...
clicking on the link doesn't open it in the browser like it usually does
selecting doesn't work
This seems to be cause by the ultra-fast refresh rate of the TUI.
I have to wait for the run to be done to copy the link.
What are good names for
- modules
- functions
- arguments
How should a module be commented?
- for short overall description
- for each function
Optional args and sane defaults preferred.
- module name: noun
- function name: verb
- arg names: abbrev? not abbreviated? optionals where possible
- version tags
- return types: lean to core types for user flexibility? avoid engine eval where possible?
Secrets handling.
Interfaces?
Lintable, if possible to ensure style is c...
Proposal:
Agree with most of it.
- abbrev (
dir)? or not abbreviated (directory)?
My preference: pick one and call it idiomatic, so I don't have to waste brain power on deciding it. (It also allows others to shame me into doing "the right thing")
Some high level practices I'm interested in (although may not be lintable):
- Interface for initializing a module using software version, custom image reference and/or
Container([example](https://github.com/sagikazarmark/da...
today
-m, --mod string Path to dagger.json config file for the module or a directory containing that file. Either local path (e.g. "/path/to/some/dir") or a git repo (e.g. "git://github.com/dagger/dagger?ref=branch?subpath=path/to/some/dir"). (default ".")
possible fix
-m, --mod string Path to dagger.json config file for the module or a directory containing that file. Either local path (e.g. "/path/to/some/dir") or a git repo (e.g. "git://github.com/dagger/da...
Todo
- [ ] No mypy warnings[^1]
- [ ] Add to lint step for CI (
lint:typing) - [ ] Build with mypyc?
- [x] Support Pyright (Microsoft's type checker, default in VS Code)
- [ ] Make sure PyCharm is well supported as well
[^1]: The ones that are leftover represent some annoyances, and don't suggest any bug. I decided to move on to not waste time for now.
This all makes sense to me ๐
[dagger/dagger] New comment on discussion #12461: Support services in Container `Publish` and `From`
@vito, what's the effort here?
Hi @mlathara, we'll have an update on distributed caching later this week in the Dagger community call. There are a few threads in Discord on caching, and the most recent one is here: https://discord.com/channels/707636530424053791/1151898625945915454. Hope to see you there. :)
Note, at least one user has developed a wrapper tool to do this.
I want to run two container in the same python code.
The first container is an foundry anvil, this is a web3 endpoint and should be run indefinitely. The second container is a python image that interacts with the first container.
I've tried many ways to detach the command anvil: anvil &, (anvil &), nohup anvil &, etc
This is the code of the anvil container (container to detach):
async def run_anvil(self, port:int=8545) -> dagger.Container:
scripts_dir...
Overview
I regularly see developers get confused (sometimes severely) by File.Export, Directory.Export, and Container.Export, to the point of failing to "get" Dagger, and sometimes even giving up entirely.
I think we should consider the possibility of deprecating these functions.
The timing matters, because we are currently discussing a new CLI experience for Zenith (dagger call etc) which might rely on these export functions. So it seems important to discuss the future of these e...
What is the issue?
It looks like WithFile("/a/b/c", ...) currently changes ownership and/or permissions of /a/b even if they already exist.
Log output
No response
Steps to reproduce
h/t @stobias123: https://gist.github.com/stobias123/46c7b9dce0506349ddeb6597674f19cd
SDK version
Go SDK v0.8.4
OS version
Linux
What is the issue?
Our docs do a good job discussing why its necessary to have a privileged container (https://github.com/dagger/dagger/blob/main/core/docs/d7yxc-operator_manual.md) but we do not mention why it is safe to do so.
We should provider some additional documentation so that security teams can have more context to make the right infrastructure decisions for their organization.
also, this doesn't happen with Dockerfile standard COPY. My assumption is that this could be related to the MergeOp optimizations we have for WithX operations.
Hi @levlaz , we will be undergoing security review soon of our proposed solution based on dagger. It would be useful to have any additional info around this topic if possible.
What happened? What did you expect to happen?
This might be a dumb question but can I run this in the official docker in docker image to get around my perms issues?
Bitbucket pipelines don't support enough privilege for dagger to work: https://github.com/dagger/dagger/discussions/1677#discussioncomment-2619008. And I'm not going to run them on-prem which is the workaround.
But could I have my dagger scripts built into the official docker in docker image (https://hub.docker.com/_/do...
We could create a GetStarted module that opens an interactive shell and teaches you how to use Dagger.
You could take this really far, but as a baseline it could just be a container w/ the dagger CLI and some example module code. It then presents you with prompts for dagger CLI commands to run that show off the various things you can do.
More interesting stuff you could layer on top of that baseline:
- Per-SDK tutorials (i.e. specific ones for Go, Python, Node, etc.)
- You could...
What are you trying to do?
Let's say I have a node app.
At present, I can use withMountedCache to reduce the npm install times i.e. it does not require us to re-fetch the dependencies over the internet.
```json
{
"name": "test",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"dependencies": {
"express": "^4.18.2"
...
What are you trying to do?
I've been looking into using Dagger for our CI pipeline in which one of the main tools we use is Bazel.
The issue with using Bazel in Dagger is that the Bazel startup time(Analysis phase) grows as your repository grows.
Most organizations using Bazel end up using persistent CI workers to lower this startup cost since Bazel keeps the repository state in memory and this makes incremental build very fast once the analysis phase is over.
This model is kind...
What are you trying to do?
Discussed in discord with @vito and @marcosnils: #maintainers message
It would be nice to have some subcommands for the dagger cli that can help inspect and prune the cache. At a basic level, it would be nice to have similar behavior to buildctl du and buildctl prune.
Future extension ideas:
- Nice visualization of cache records and how they link to each other
- Listing and pruning...
Is there any way to pull docker images from a private and insecure registry instead of docker.io ??
This is my testing code:
import anyio
import dagger
async def main():
config = dagger.Config(log_output=sys.stdout)
async with dagger.Connection(config) as client:
# use a node:16-slim container
# mount the source code directory on the host
# at /src in the container
source = (
client.container()
...
What are you trying to do?
When grouping various actions in a "submodule", there is no way to assign an action to the parent at the moment.
Given the following module:
type Ci struct{}
func (m *Ci) Lint() *Lint {
return &Lint{}
}
type Lint struct{}
func (m *Lint) All(ctx context.Context) error {
var group errgroup.Group
group.Go(func() error {
_, err := m.Go().Sync(ctx)
if err != nil {
return err
}
return nil
})
group.Go(func() error...
What is the issue?
When MIMEType defaults to application/vnd.oci.image.layer.v1.tar+gzip, ghcr.io no longer displays OCI labels correctly, i.e. https://github.com/users/gerhard/packages/container/sysadmin/114534202
This changed in v0.6.3 via:
When MIMEType is set to application/vnd.oci.image.layer.v1.tar.gzip, OCI labels work as expected, i.e. https://github.com/u...
GHCR docs claim to support oci image spec annotations: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry#labelling-container-images
So if I'm reading them right and they are to be believed, I think something else is probably breaking.
I know we have integ tests for publishing all the different mediatypes, and I think we have integ tests for labels, so it may be worth creating a mashup test and see what happens.
Right now callers can pass their environment variables to modules by just reading them and setting them to function arg values, e.g. w/ the cli:
dagger call my-function --some-arg $SOME_ARG_VALUE --other-arg env:OTHER_VALUE
This suffices for straightforward use cases but multiple users have found it to be tedious + clunky once you need to pass a lot of env vars. It also isn't ideal for some use cases where the caller may not know what they are even supposed to pass.
This issu...
What happened? What did you expect to happen?
Using private registry with private CA (stored in /etc/docker/certs.d, we store the ip resolution in /etc/hosts.
It appears that Dagger do not take into account the /etc/hosts and fail to resolve the registry fqdn:
dagger.exceptions.QueryError: failed to do request: Head "...": dial tcp: lookup on 10.87.0.1:53: no such host
Is there a way to tell Dagger to resolve the registry using the /etc/hosts and use the certificats...
The new default behavior, for an unspecified argument foo, is to look up the environment variable FOO, and use its value.
@shykes I like the general idea of your proposal in that we could make this a CLI-exclusive piece of functionality to start.
The auto-matching of arg name to env var would be the most magical part and I can definitely think of various corner cases or situations it might not handle super well. But that's obviously fine provided we at least improve the situation sig...
@shykes, indeed, having it all in a sandbox makes the inner process more secure. It does not directly prevent secret exposure. But that said, getting back to the argument passing, if it's true that it's not a dagger issue itself, developers or ci/cd tools can make mistakes in exposing/printing those secrets to the logs/output example:
... --my-secret=$MY_SECRET --another-secret=$(gcloud auth print-access-token)
the second argument directly depends on the ci/cd tool handling/masking th...
Hi @bessey,
Thanks for your comment ๐
Our registry piggybacks to ghcr, which is currently facing a major outage: https://www.githubstatus.com/
<img width="488" alt="image" src="https://user-images.githubusercontent.com/31691250/222166421-c739b28f-6b33-4085-91f2-013bf92a94b0.png">
We are taking that into consideration and have added in our backlog the implementation of a more resilient solution @gerhard
What you are experiencing is the fix we implemented a few weeks ago after a ...
Right now vendor directories in a go module don't really work as expected (or at all depending on the situation).
They should work seamlessly and enable the removal off all deps on the internet in terms of go modules and use of private packages the engine may not be able to access.
Steps to reproduce:
- Checkout the following branch https://github.com/marcosnils/kubeconeu-question-5/tree/dagger
- Run
go run ./ci/main.go packageand you'll notice that dagger execution never finishes after displaying something like#3 11.82 Layer 'buildpacksio/lifecycle:cache.sbom' SHA: sha256:a5cda63693b26825fec73e9367bbf216d1134e8c5d32f0459f568117dea3348b
Running the same pipeline with docker works:
`docker run -v /var/run/docker.sock:/var/run/docker.sock -v $(pwd):/ap...
@marcosnils do you mind assigning this to yourself, or is there someone else that should work on it?
@marcosnils thanks for the simpler reproducer, I poked at this for a little bit but am more confused than when I started now.
I was wondering if we just needed to propagate a close of the docker container conn to the buildkit client, so I made that change along with a few other println debugs here: https://github.com/sipsma/dagger/commit/0ee831ff343861718d4346951d6f302889c95b55
The first weird thing is that while most of the time I still get a hang when running with that branch, I occas...
Dagger Cloud run URL
docker-container://dagger-engine
What happened? What did you expect to happen?
I tried some examples from dagger.io.
And for me is unclear in what cases the image is repulled by the dagger-engine.
Manually pulled images seem to be ignored?
The problem is even more critical if you imagine kubernetes pod running the dagger-engine. Because there will be no info after restart of pod. Mounted docker.sock should have wished effect... but If it will repull, dag...
After a short research most of the tools mentioned support the use of other addresses than 127.0.0.1.
This is a good enough examples to support it IMO. If other tools support it, I don't see why we wouldn't also. Thx for sharing @borissmidt
@Pymann, from what I understand, you've been:
- Pulling an image in Docker using the docker CLI
- Referencing the same image in a Dagger pipeline
- Realizing that the pipeline would download the Dagger image even though you have it in locally in Docker
If this is what you meant, it doesn't work that way: docker's cache and dagger's cache are not related, even when you mount the socket.
The problem is even more critical if you imagine kubernetes pod running the dagger-engine. Bec...
What are you trying to do?
When using service containers, they just show up in the dagger TUI as "service nc512ita2341" with some randomly generated name, what I'd like to do is supply a user defined label to this, to make it more human-centered in its representation, so that I'd see something like
Dagger Pipeline....
โ
โโโโถ service "Primary PostgreSQL Database"
โ โโโถ .....INSERT INTO xxxx ...
If you connect to an existing dagger session (e.g. via dagger-in-dagger or via dagger run) and specify a workdir it's ignored and instead the workdir will be the workdir of the session process.
I think the very minimum would be to throw an error if this happens (a workdir other than the one of the session is specified) just to at least replace the confusing behavior w/ annoying but comprehensible behavior.
It also might be possible to actually allow different clients to have different...
What is the issue?
It would be great to have a better high level overview of the differences between the CLI and the SDK to invoke dagger and when to use one or the other.
Right now we have this in the intro page but its a bit misleading because we say that you should use the CLI if you are a "fan of shell scripts", then the rest of the documentation (i.e. [go getting started](https://docs.dagger.io/sdk/go/959738/get-started#require...
What is the issue?
I haven't found any examples of how this is suppose to work, but maybe its obvious and I'm not looking hard enough.
I know I can run the pipelines locally, but can I run pipelines locally and mock out all the actual commands? So I can test the logic without actually doing a deployment?
Is the solution to just factor your code in a way where you can unit test its components? Even if I do that I'd still want a way to "integration" test where I run the whole pipelin...
Just want to add more to this. This is not the testing I'm talking about: https://docs.dagger.io/sdk/python/628797/get-started#step-3-test-against-a-single-python-version
I don't want to actually execute commands I want to do something like mock them out. This is really important if you are capturing output of commands and parsing it in code.
Using python as an example there is a framework called pyinvoke designed to make it easy to execute shell commands programmatically. Its kind of a...
What are you trying to do?
Installing dagger-cli from Homebrew is awesome.
less awesome is installing by
cd /usr/local
curl -L https://dl.dagger.io/dagger/install.sh | sh
I searched for "package" "install" and "completion" before opening this issue.
Labels: CLI, DX
(There is a thread describing the situation in detail at #1155601074393194658 message )
Why is this important to you?
I think that it will be e...
User request to be able to push to http registry: #1046817210695417906 message
I can confirm that I get the same error but only when trying to push to a non-https registry that is not on localhost. There must be some logic buried somewhere in buildkit or its image push dependencies to not enfore https on localhost?
Either way, buildkit actually has a flag to support this during image export but for some reason I can't get it to ...
TLDR: dagger call is very safe, but lacks the convenience of artisanal scripts. There is a way to get both: safety and convenience.
Problem
Now that Dagger Functions are generally available, the standard way to use Dagger from your project is to call functions. Today that is done with dagger call.
dagger call is a fantastic primitive: simple, reliably, and safe. If you understand dagger call, you understand how Dagge...
CLI examples:
https://github.com/dagger/dagger/blob/main/cmd/dagger/query.go#L29-L41
https://github.com/dagger/dagger/blob/main/cmd/dagger/exec.go#L21-L24
Are unix specific, we should change it to depending on which platform the CLI is built, examples differ.
today this is a pain, all the output really just overlaps badly
Wouldn't this be fixed by all the calls sharing the same session? Similar to dagger run sh?
What are you trying to do?
This isn't quite a feature request, but a request for better examples.
I'm using the Rust sdk, as I want to use dagger to run my Rust project through CI. The examples do a good job of showing how to build go and js projects, but I still found it difficult to get a useable pipeline, written in Rust, for a Rust project.
I mad e Rust project, seperated into workspaces, one of which is ci. This is the main.rs file that I used to get Dagger to run with a r...
Test (see the Relative path):
func TestDirectoryWithNewFile(t *testing.T) {
t.Parallel()
c, ctx := connect(t)
defer c.Close()
entries, err := c.Directory().WithNewFile("some-file", dagger.DirectoryWithNewFileOpts{
Contents: "some-content",
}).Entries(ctx)
require.NoError(t, err)
require.Equal(t, []string{"some-file"}, entries)
// Relative path
dir := c.Directory().WithNewDirectory("a").WithNewFile("some-file", dagger.DirectoryWithNewFileOpts{
Contents...
What are you trying to do?
The release artifacts (cli binary tars in the github releases and container in GHCR) should be signed
- Detatched or clearsigned checksums.txt
- Signed container in GHCR
- ? SBOM for container in GHCR ?
Why is this important to you?
So that I know the artifact(s) are from Dagger
How are you currently working around this?
No response
Based on a conversation in #help yesterday, I think this is true:
src := c.Host().Workdir().Directory("sdk/python")
This will send all of workdir to buildkit and changes outside of sdk/python will bust cache
src := c.Host().Directory("sdk/python")
this will just send sdk/python to buildkit and changes outside of sdk/python will not bust cache
We should make this more clear :)
What are you trying to do?
I want to use client.http("https://domain.example/tool-1.2.3.tgz") to download a build-time dependency. While it works, it provides no protection if the remote file changes. I propose extending ClientHttpOpts with sha256 parameter, that'd have 2 functions:
- if hash of downloaded file doesn't match, dagger rejects the file and prints the conflicting values.
...
What are you trying to do?
I had a scenario while testing different builder images where I had to set different Owner for certain tool chain images.
...
WithMountedCache("/mydir/.m2", c.CacheVolume("m2"), dagger.ContainerWithMountedCacheOpts{
Owner: "jenkins:jenkins",
}).
...
The current implementation of this silently ignores the new cache if a previous cache (with different owner) exists. https://pkg.go.dev/dagger.io/dagger#ContainerWithMountedCacheOpts
It ...
I believe I encountered the same problem. Here's the situation: I have two Dagger modules. The first builds my software as a non-root user and uses cache volumes. However, this module only handles the software's build. The second module uploads the cache to my Artifactory server. When I attempted to mount the Cache Volume using the same key, I received an empty directory. Through debugging, I discovered that I needed to mount the Cache Volume with the same owner for the files to even appear. ...
What are you thoughts on adding an owner value to CacheVolume(), e.g.
c.CacheVolume("m2-jenkins")c.CacheVolume("m2-owner2")
What are you trying to do?
Part of the story around Dagger's appeal is its cache-first approach, backed by Buildkit.
Dagger Cloud, for those who have alpha access, offers some visibility features, namely a UI that shows whether something was cached or not. However, at Airbyte, where we leverage Dagger heavily, we have noticed limitations around the existing tooling that Dagger offers. Namely, we are missing some features that allow us to automatically analyze and qualify builds, as ...
Thank you for your feedback, @cpdeethree!
It's on our roadmap for the UI to
- Surface caching analytics across changes
- Highlight caching analytics in a change
- Make it easy to determine why something wasn't cached, debug it, fix it, and then verify it's now cached
For determining why something wasn't cached, there are two places in the UI we've considered adding more visibility: the tree view and the DAG view. You can see relations in the DAG view, but it's experimental a...
Thank you for your feedback, @cpdeethree!
It's on our roadmap for the UI to
- Surface caching analytics across changes
- Highlight caching analytics in a change
- Make it easy to determine why something wasn't cached, debug it, fix it, and then verify it's now cached
For determining why something wasn't cached, there are two places in the UI we've considered adding more visibility: the tree view and the DAG view. You can see relations in the DAG view, but it's ex...
Dagger currently has Dockerfile support through the DockerBuild and Build operations, but it only allows specifying a single build context at the time for that. Not so long ago, Docker (and Dockerfiles) added support for multiple named build contexts https://www.docker.com/blog/dockerfiles-now-support-multiple-build-contexts/ which allows to use multiple build contexts during a build.
I'd be nice if Dagger could add support for this use-case as well.
ref: https://discord.com/chann...
What is the issue?
Differently than Docker which has an embedded tiny process (https://docs.docker.com/engine/reference/run/#specify-an-init-process), some Dagger users could potentially find differences while running service containers (i.e mongodb) as the service container will just exec as soon as the init process exists.
We should document this caveats and provide instructions for users finding themselves in this situations. Here's a discord thread which provides one possible ...
What is the issue?
From @ringods
you might want to highlight that the Dagger SDK will do some magic behind the scenes to ensure you have a Dagger Engine running in each of the CI integrations here: https://docs.dagger.io/7442989/cookbook#integrations
I was puzzled that I didn't need to install dagger as part of e.g. my Github Actions workflow.
That feature is called "Automatic Provisioning". There's more info about it in the SDK contribution guide.
What are you trying to do?
I'm downloading the Dagger binaries, but Edge browser is telling me that the zip archive is untrusted.
Why is this important to you?
It would be nice if zip/binary was signed so that Windows could trust it. I'm not sure how much effort this would involve.
How are you currently working around this?
I have to override and ignore the warnings that edge gives me.
 shouldn't have this problem.
What are you trying to do?
When running dagger query in a script by dagger run, the session from run isnโt being reused. dagger query should look for the port and token env vars to initiate a client connection.
The same goes for other commands since they share the same base for starting a session.
Why is this important to you?
Using setSecret with dagger query isnโt possible because the built-in secrets use an in-memory store which gets wiped on each new sess...
If you run a pipeline that references an image using a tag, the tag needs to be resolved to a SHA, which requires internet access (or, more specifically, network access to the registry).
This means that if you are offline you can't run those pipelines, even if the images are cached locally. This also results in the inability to run pretty much all of our test suite while offline, which is quite annoying if you are working on dagger and only have intermittent internet access.
Workarounds...
This might have an impact on the analytics collection. cc @gerhard
@gerhard Should this benefit tests execution too? Tests that share some Alpine image should reuse that, etc.
Yes, this makes a lot of sense.
We are already doing this for the Engine image:
failed to resolve image digest: Get "https://registry.dagger.io/v2/": dial tcp: lookup registry.dagger.io: no such host
falling back to leftover engine
Connected to engine fce67ef5b2b5
I just confirmed that sha256 image references uses the locally cached layers and works without an internet connection:
x ping -t 1 -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
pin...
Update: Build Fix Added โ PR #1607
The deploy pipeline on main is broken due to a TypeScript error in the warehouse activity tab (from PR #1594, unrelated to our CA work). PR #1607 fixes it with a one-line type annotation.
Updated Merge Order
- PR #1607 โ Build fix (unblocks deploys) โ one-line, no behavior change
- PR #1604 โ Root cause fix (remove
attribute_not_exists(dc_id)) - PR #1598 โ Post-push negative check (safety net)
- PR #1605 โ Webhook receiver + t...
As reported by Kasper Hermansen:
Service containers are great, the host names are bit weird in the output, i.e. the generated hostname, would be nice if it showed the alias more clearly.
Not sure; hard to say what output the original issue is referencing, but I don't think the situation has changed with the new TUI, since it doesn't go out of its way to show service aliases.
We at least don't have those service DDSKYFHAKOU groups anymore! Now you just see a start <command> span, like this:
Probably somewhere around here. But who am I to say =D
Summary
This proposal suggests adding an SDK helper for efficiently synchronizing multiple pipelines, in an easy to use way.
Background
This is based on one aspect of:
- #4205
Motivation
Often times, you want to execute multiple pipelines in parallel (e.g. build & test). This is surprisingly tedious to do:
eg, gctx := errgroup.WithContext(ctx)
eg.Go(func() error {
_, err := test.Sync(gctx)
return err
})
eg.Go(func() error {
_, err := li...
What are you trying to do?
Would like to get a list of which files were read/opened during a pipeline run.
Context in discord [here](#general message)
Why is this important to you?
Lots of boilerplate code in our repos, significant amounts aren't actually used. Would be good cool to be able to say "xyz files can likely be deprecated"
How are you currently working around this?
If this isn't possible dire...
[dagger/dagger] New comment on discussion #12507: โจ Observability - Find Opened/Read/Touched Files
I'd also add to this that having better visibility about which files are being sent to the context on each build could also help to stop some performance improvements of unnecessary file transfers.
Summary
For simple object types where all their fields are non-parametrized scalars, make it more convenient to access the objectโs properties in SDKs by returning the whole object at once as a leaf value.
Motivation
Our chainable API is pretty simple, but it also feels limiting when you want multiple related fields, especially if theyโre a part of a simple object like EnvVariable, Port or Label.
For example, if I have an EnvVariable object, and I want both the `name...
I just updated the proposal which was long overdue.
I removed the example on ExecResult which was the main reason I wanted this in the first place, but there's other solutions for that and I no longer think it worth it to have a wrapping type for exitCode, stdout and stderr especially if the output could be huge and you don't want all those fields when you just need one.
@helderco This issue can help to improve #5557 integration (See https://github.com/dagger/dagger/pull/5557#issuecomment-1687440697)
Should we start working on It? I understood your proposal and have an implementation in mind for Node and Go.
This would make our generators a bit more complex and specific (since we have special function for what you call simple object).
Should we start working on It?
We should agree on design first.
Having spoken to @helderco sync, we are thinking of not including this in the upcoming breaking changes release since more discussions are needed. FTR:
@vito @sipsma @shykes @aluzzardi Waiting for your feedbacks then :D
For continuity from Discord conversations with @shykes:
We agree that there's a need for state and that there is effectively a fields vs. functions distinction internally, but @shykes 's point is that fields should just be an implementation detail of modules, not distinguished in any way through the API. The main take-away is that it should be easy for a module author to switch something from a field to a function internally without any impact on users.
So I think to address this we'll ...
What are you trying to do?
Making codegen types (from API) hashable would allow them to be used in some interesting use cases.
Why is this important to you?
As an example, one user could benefit from using an LRU cache in a function that receives a (lazy) pipeline, does something dynamic with it and returns it.
Assuming that such function is a dependency used more than once in the same project, and that the result will be the same if the input pipeline is the same, you ca...
What is the issue?
This issue will collect the various improvements we can make in the near term to the documentation for using Jenkins and Dagger together for CI.
Summary of issues
- The Node and Go SDKs have examples of how to use CI with Dagger, but the CLI and Python SDKs do not
- Users must know how to specify where the Dagger CLI gets installed. The docs do not detail that Dagger's uses the $XDG_CACHE_HOME env variable to find/download the CLI. If that variable is not...
[dagger/dagger] New comment on discussion #12511: Improvements for Jenkins integration documentation
Example: setting the environment variable to specify where Dagger should be installed: export XDG_CACHE_HOME=${env.YOUR_LOCATION};
Jenkins declarative pipeline
pipeline {
agent any
stages {
stage('build image') {
steps {
git branch: 'master', url: 'https://github.com/robertu94/libpressio'
sh '''#!/bin/bash
python3.10 -m venv workenv;
. ./workenv/bin/activate;
...
[dagger/dagger] New comment on discussion #12511: Improvements for Jenkins integration documentation
Another thing that was missing in my case was on CentOS 8, there were also kernel modules iptable_nat and iptable_filter that needed to be loaded.
Problem
Dagger supports multi-platform operations. The most common use of this feature is to run containers on both x86 and arm architectures. However in its standard, single-node configuration, the engine will use emulation under the hood, resulting in poor performance. In theory, this can be addressed by distributing execution across several machines, one for each architecture - the underlying buildkit runtime provides plumbing to do this. However in practice, configure buildkit i...
Rough immediate thoughts: we could support connecting to multiple runner backends from the session and then just route the requests based on the Platform field in the container/directory/file ID payloads.
I think the tricky part would be that currently separate runners don't know anything about each other, so when it came time to try to push a multiplatform image you'd somehow need them to coordinate between each other to push the different platforms for the image without stomping over e...
What are you trying to do?
A consistent, more accessible way to generate new SDKs and add features to be implemented by existing SDKs.
Why is this important to you?
This will allow for the SDKs that users need to be produced by more community members and make them easier to maintain.
How are you currently working around this?
SDKs need deeper knowledge of and integration with Dagger core today.
cc @samalba
Passing thought, given the fact that:
- Quite a bit of the work here is pretty monotonous boilerplate (e.g. the codegen templates)
- We have a pre-existing set of examples (go, python, nodejs)
This feels like a potentially good use case for LLMs. It's too big an input+output to just plug into chatgpt, but I would not be surprised if a slightly more specialized setup of gpt or similar could take care of a lot of the boilerplate for something like this. Even if the result isn't perfect, ...
I see a few issues in general. You kind of want to still hold the reins of what is in the sdks you don't want a super big sprawl because then adding features, and tweaking stuff will become a lot of work.
Each sdk has some core bits that needs to be added to a degree some of it could be solved using a shared library approach, most of the current languages technically could use a dll/so file approach for downloading the engine and creating a connection to it. This would reduce most the actu...
When docker build is used with buildkit mode in the same machine, images present through docker pull are shared with buildkit automatically (not sure how it actually works under the hood). Some users (https://discord.com/channels/707636530424053791/1073696894380949545) which are currently trying out dagger pre-pull docker images as part of their node bootstrap and would like those images to be present in their Dagger pipelines as well so they don't have to be re-downloaded.
Probably ...
When docker build is used with buildkit mode in the same machine, images present through docker pull are shared with buildkit automatically (not sure how it actually works under the hood)
This works because docker doesn't use vanilla buildkit, it imports buildkit as a library and then plugs in its own snapshotter and worker backend that integrates with docker's content stores: https://github.com/moby/moby/tree/master/builder
In docker's most recent release I believe support has been...
Some advanced (#1073552228390031400 message) users are running the dagger engine separately and then using the _EXPERIMENTAL_DAGGER* flags to hint their SDK's accordingly.
The issue arises that if miss-matching session CLI's and engines are used, users could potentially get weird errors and/or behaviors.
Possible solutions
- Print a warning message about these versions being different
cc @sipsma
Hey @kpenfound, we run Cloudbees Core with ephemeral agents. I'd be happy to provide details about our setup. I haven't gotten dagger to run on it yet. Not because it's not possible but because I haven't had the time. However, not having a local cache isn't encouraging me much to get on it.
@rawkode This might be a good one to build a real-world example for in the video series
From a "CI/CD Pipelines as Code" system, I expect to dinamically handle jenkins agents from code. ๐
Example:
Run build, test, lint, typecheck commands on 4 or more agents based on how many subtasks have each target (i.e: if my unit test without cache take 20 min, I would like to split them on furtherer two different agent)
Provide a definitive guide on how to run Dagger on Gitlab CI self-hosted runners.
how is this issue different from #4544 ?
They overlap quite a bit on the gitlab part, but #4544 seems to be about one very specific tutorial that happens to use Gitlab, among other tools. This issue focuses on providing operators with a reference documentation for how to install Dagger on Gitlab runners.
User feedback [on discord](#general message):
In my customers organisation the DinD setup is (almost) forbidden on Gitlab runners so we are looking for ways to run Dagger without that. We are currently rolling out own runners for our team but maintaining them isn's something we are too keen about but we like Dagger that much that we are biting the bullet ๐ Hopefully soon there are other options.
how is this issue different from #4544 ?
Provide a definitive guide on how to run Dagger on CircleCI self-hosted runners.
What are you trying to do?
This feature has been requested by the user in Discord YourTechBud
" Using dagger to build some code and images. I want to restrict the cpu and memory allocated to this. How can I do that?"
cc @YourTechBud
Why is this important to you?
N/A
How are you currently working around this?
N/A
just a note: buildkit has support for specifying an existing cgroup for an exec to run in. That by itself is not the greatest dx because it requires the cgroup to be created beforehand manually, but I feel like we could do something with our shim to improve this further, maybe make cgroups on the fly so that users can just specify actual cpu/mem limitations?
but I feel like we could do something with our shim to improve this further, maybe make cgroups on the fly so that users can just specify actual cpu/mem limitations?
that'd be awesome.
idea: we could inspire on the approach docker run` uses for setting CPU and memory constraints? After all, users are already familiarized with those.
It would be useful to be able to query the digest of a directory or container. A typical use case would be to use that digest as a tag when pushing an image to a docker registry - thus ensuring that a given version of an image is only pushed to one tag.
cc @kpenfound
@kpenfound do you happen to know if any users have requested this yet? cc @d3rp3tt3
We would definitely use this. One example would be producing a canonical manifest of the digests for out application (it's made of multiple images).
Create an example pipeline that uses conditionals based on git changes or other inputs to determine what to execute
Hi @aluzzardi, I saw that you were using D2 for https://github.com/dagger/dagger/tree/main/cmd/dagger-graph, looks great!
I wanted to just bring up that we have an API that can make programmatic generation of D2 diagrams a lot easier/simpler to manage/debug than writing the script with fmt lines: https://pkg.go.dev/oss.terrastruct.com/d2@v0.1.5/d2oracle
Here's a blog post with runnable code on how it might be used: https://terrastruct.com/blog/post/generate-diagrams-programmatically/. A...
Neat, thanks @alixander! Indeed I missed it -- I went through the 1-d2lib example and entirely missed the 2-d2oracle one.
By the way, is there a way using d2oracle to set a label programmatically and skip "interpretation" altogether?
While generating using a string, I ran into escaping problems (single/double quotes,$ being interpreted etc). The graph "labels" are extracted from logs so they can contain anything.
@aluzzardi, if you just Set (https://pkg.go.dev/oss.terrastruct.com/d2@v0.1.5/d2oracle#Set), D2 will figure out the best way to quote the string, handling escaping for you.
See here for an example:
https://github.com/terrastruct/d2/blob/master/d2oracle/edit_test.go#L806
It's calling Set with a string that has both single quotes and double quotes
What are you trying to do?
I've recently been considering moving pieces of my existing (non-Dagger) CI pipeline to self-hosted infrastructure on Google's spot instances. Because these instances could be preempted at any time, it would be ideal if progress on my pipeline were saved incrementally, in as granular a way as possible. It occurred to me that Dagger's cache model (where each execution step can be cached, potentially to long-lived external storage) might make solving this problem...
That's very interesting. I wonder how much you could get out of the current version of Dagger on spot instances, with either a regular cache export at the end of the job, or persistent block storage to avoid the need for cache export entirely? Of course some jobs would be interrupted before the end, but depending on the average lifespan of a spot instance, it might happen infrequently enough to be worth it.
Regardless of caching, there are other aspects of this setup that would not be triv...
Hi,
Are you able to give more details about this?
We have an ambitious roadmap for dagger's caching infrastructure though, so we'll get around to it eventually - but not in the near future I believe.
Currently dagger intentionally is a local first engine, this however means that the pipeline creation has to execute on too of forge-native or external ci systems for the time being
This is not directly apparent from the documentation
This allows a user to add hosts to the Dockerfile build
input Host {
host: String!
ip: String!
}
type Directory {
dockerBuild(dockerfile: String, platform: Platform, hosts: [Host!]): Container!
}
@samalba, as it is the last issue on https://github.com/dagger/dagger/issues/4241. How do you feel about the priority of this one ? I recall that @shykes had some reserves around the design of the host /engine interactions ?
From: #1049383705967333426 message
We could also add a dagger.ConnectOpts that would enable or disable that behaviour.
If activated, rerun the missing step.
If deactivated (default), error out.
What is the issue?
Create a guide on how to write tests for a dagger pipeline
Related issues:
https://github.com/dagger/dagger/issues/4199
What are you trying to do?
I'd like to set resource limits to build calls made to Dagger API.
Why is this important to you?
Having build resource limits will prevent abuse of the shared Dagger/Buildkit cluster we maintain
How are you currently working around this?
Not working around it currently.
Thanks to @sipsma pointing out that Buildkit already supports this so it would be something that Dagger API needs to support. https://discord.com/channels/707636530424053791/105084...
@jedevc does your PR solve this? https://github.com/dagger/dagger/pull/8800
We had a few commanders and a customer run into this issue.
@RealHarshThakur what are your multi-tenancy requirements? Is your cluster shared internally to your team, or actually available by customers? In other words how much do you trust your tenants, and how much do they trust each other?
It would be for customers so don't really trust people using it. Having noisy neighbors is something that is acceptable for the most part. A resource limit would be a safeguard against someone who's trying to consume all the infra resources for themselves.
@sipsma can comment further, but I don't believe buildkit can be safely used in a multi-tenant way if tenants don't trust each other. It's reasonably sandboxed, but I wouldn't bet a customer's data on that. For example we run our API playground on a shared buildkit, but are very clear with users that they should not use it for anything critical, and they should not upload sensitive credentials or assets either.
This doesn't invalidate the need limits to avoid noisy ...
@mircubed #8800 is just about allowing configuring existing options that today are configured through a different mechanism - it doesn't yet add any additional controls (but when we do add them, we would do so through the new engine.json mechanism it introduces).
Oh, can you please expand more on that? What would be the attack surface? Some sort of cache reuse attacks?
Yeah, buildkit's cache isn't separated per incoming user - it's shared across an entire instance. Essentially, if...
I wouldn't bet a customer's data on that.
Oh, can you please expand more on that? What would be the attack surface? Some sort of cache reuse attacks?
In the original discord thread, the WithCgroupParent was mentioned - I think that's probably the right place to start?
Not entirely what level of granularity we'd want - I think it probably makes sense for the client to set session-wide cgroup limits (we probably don't want modules to have that level of machine-specific granular control over their WithExecs, but maybe there's a use case).
In terms of how to configure it: I think we'd want something like https://github.com/dagger/d...
What are you trying to do?
Currently there's no way to check if a host variable is unset or if it's value is empty since envVariable will always return empty regardless if the variable is set or not.
Given the following GraphQL queries:
{
host {
envVariable(name:"NON_EXISTING_VAR") {
value
}
}
}
{
host {
envVariable(name:"EMPTY_VAR") {
value
}
}
}
dagger will always return "" for both cases. It'd be ni...
What are you trying to do?
I would like to be able to, in a container, run an anonymous function instead of a shell script.
You can run a shell script using
container := client.Container().From("golang:1.19")
container = container.Exec(dagger.ContainerExecOpts{
Args: []string{"some", "command},
})
but I would like to be able to run an anonymous function on the container using a function like container.Run
Ideally, it'd look like this:
Overview
I propose adding a new feature to the Dagger API: saving & loading of pipelines.
- Save: snapshot the state of a pipeline, encode it as text, send it to the client
- Load: restore the state of a pipeline, decoded from text received from the client
This would be a very powerful primitive that we could use in many ways:
- Stitching. Allows clients to "stitch" pipelines together into more complex pipelines. This is necessary since some pipelines cannot be expressed a...
Many thoughts, but one immediate note is that this has significant overlap with some of the problems and possible solutions to session stickiness that @vito and I talked about previously. Specifically, see possible solution A) Pin sources in returned IDs in this issue: https://github.com/dagger/dagger/issues/3613
This issue and that one aren't the exact same (just overlapping venn diagrams), but that other issue may have some helpful context around the general idea of making IDs more re-...
cc @aluzzardi @sipsma @davidwallacejackson
pinging @kjuulh who expressed interest in this topic today :)
Spent some time thinking about this and have a proposal to pick apart. There are still some loose ends and potential paths to explore, but there's enough to riff on async for now.
I started by defining a protocol format for IDs on the basis that they're closest thing we have to "save/loadable pipelines" and we've been kicking the can down the road with regard to their structure and format. We're going to want a canonical way to serialize/deserialize these, and [JSON ain't it][no-json], so ...
The current approach for ensuring we don't leave a bunch of engine images+binaries around running forever is very primitive and doesn't allow multiple versions of an engine to coexist. More background in this comment and the one preceding it: https://github.com/dagger/dagger/pull/3647#issuecomment-1302721770
This means that we must always update engine dependencies in SDKs very close to each other and that users must update those SDKs in lockstep too if they use multiples from the same mac...
Agreed with point 1, whatever we do ends up needing some mechanism for that.
Point 2 though, does introduce a new point of friction for users - I'm a bit worried that this would be an annoying breaking change for most users.
Ideally, we'd have a way for engines to tear themselves down after not having been used for a period of time. But I can't see a way to convince the daemon to do this - maybe if we had a --restart=always or similar, then the engine could wipe it's own volume (even th...
What are you trying to do?
One of the challenges with CI systems right now is the lack (or poor state) of analytics.
As a requirement for us to use dagger as a building block, we would love to have access to execution data so to build solid "pipeline observability", as a core feature to our product.
Why is this important to you?
Well, customers want it :)
Information about pipelines and "actions" execution time, failure trends, caching, are important to have for people in cha...
Yes! I started to look into what's supported since I saw there is some tracing-related code, but I didn't see any documentation for it yet.
Something I'd love to see that I don't see mentioned here is a way to pass the tracing context all the way down so that I could add my own tracing to the jobs being run inside Dagger. For example, on a test run I'd love to have the ability to trace execution within the individual tests. This would be invaluable in pinpointing testing bottlenecks, or so...
What are you trying to do?
Provide an easy way to clear a directory of any files ignored by git. The formal definition can be found here .
My suggestion would be the following:
func (r *Directory) WithoutGitignore() *Directory
This directory with all files removed that would be ignored by git
Side Note:
I don't currently need this but WithoutUntracked and other exclusions based on git might be useful as well.
Why is this impor...
until it's decided if this will is a good candidate for the core API, you can currently do this by using the recently added include and exclude arguments in 0.4 https://github.com/dagger/dagger/pull/3583. In case you're wondering which is the pattern matching logic behind that include and exclude arguments, you can check it from here: https://github.com/moby/patternmatcher. It basically supports exact, prefix, suffix and regexp matching.
The .gitignore native feature wi...
I am not sure if simply parsing .gitignore files is sufficient as gitignored files are defined as followed:
A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected
Using include and exclude might also cause problems, as tracked files, which match a .gitignore pattern will be removed. This file would have been present inside any CI framwork but now iw ignored.
To fully replicate this behavior one needs:
- all .g...
I am not sure if simply parsing .gitignore files is sufficient as gitignored files are defined as followed:
I agree, that's why I didn't suggest parsing the .gitignore files since that wasn't going to be enough. One thing you can do though is to get the output of git status --ignored or git check-ignore **/* and use that as an input for the exclude argument.
Problem
When you have a beautiful chain of 20 function calls, no error checking end-to-end... except the one in the middle, then you're forced to break your chain, plumb error checking all the way up... So much beauty ruined.
Solution
Allow me to attach an error to the container, so that it is lazily returned to the caller, and I don't have to deal with error passing in my code. Example:
func Beautiful(ctx context.Context) *dagger.Container {
checkTheThing := ...
Agreed, I previously considered whether we could instead have WithErr (naming tbd), which takes a func (*dagger.Container) (*dagger.Container, error). I'd rather we don't explicitly embed errors into containers, but I'm struggling to explain why I think that pattern is less desirable.
Regardless of the interface, the error would then get surfaced in the next function in the chain which returns an error, and if one is not present, it would be exposed at the top level of the module...
What is the issue?
The error message output by this should correctly indicate that two sibling modules being referenced via a local url must live within the same git repository. This will allow end users to much more easily understand why this is failing
Dagger version
dagger v0.10.0 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
โ /tmp rm -rf test
โ /tmp mkdir test
โ /tmp cd test
โ test mkdir mod1
โ test mkdir mod2
โ test ...
The "Expected" language above is only suggested of course, perhaps a better verbiage can be determined
What is the issue?
When browsing the documentation, it's difficult to navigate to the section on module development. Right now this is buried underneath Dagger API > Working With Modules. There is also a reference under the features section called Features > Reusable Modules that links to Custom Functions.
For a new user, or even someone relatively famil...
Right now this is buried underneath Dagger API > Working With Modules.
...
I'd like to propose that we consolidate these documentation pages into a new top-level section - something like Developing Modules that combines these pages into a single section.
We iterated quite a few times on the docs structure and even at the time, modules were one of the topics we had a hard time fitting into the overall navigation. This is because modules a...
Today we have benchmarking for running very basic benchmarks for
dagger init (to create the Dagger module with the default layout and example functions) and then dagger functions (to list the available functions) a few times (first uncached, then cached, then after modifying source code), that show latency of these commands and improvement areas for the SDKs around "getting things ready to run".
https://github.com/dagger/dagger/actions/workflows/benchmark.yml
We should also be running ...
Given the following Talos v1.9.1 cluster:
kind: Cluster
name: dagger-ci-2025-01-02
talos:
version: v1.9.1
kubernetes:
version: v1.32.0
patches:
# Single-node cluster FTW! ๐ช
- name: allow-scheduling-on-controlplanes
file: ../patches/allow-scheduling-on-controlplanes.yaml
# https://www.talos.dev/v1.9/talos-guides/network/kubespan
- name: kubespan
file: ../patches/kubespan.yaml
# https://github.com/siderolabs/omni-feedback/issues/41
# https://s...
Problem
Dagger doesn't support mounting NFS directories directly into containers. Instead, the user must mount them into the client machine, and copy them from there into the engine, like any other host directory. This works reliably, but is less efficient than a direct bind-mount.
Solution
At this time there is no design for bypassing the copy into the engine. Nikola Jokic has [proposed implementing support for direct bind mounts](https://discord.com/channels/70763653042405379...
After a closer look, virtio-fs is the culprit for this issue:
it cannot be used as a "upper layer" of overlayfs without a custom patch
Source ๐ @t3hmrman
mount output from the dagger-kata-0 container:
none on / type virtiofs (rw,relatime)
proc...
Having followed https://github.com/kata-containers/kata-containers/pull/3137 from @t3hmrman, I was able to get this Dagger StatefulSet to work:
<details>
<summary><code>kata-emptydir-memory.statefulset.yaml</code></summary>
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: dagger-kata-emptydir-memory
name: dagger-kata-emptydir-memory
namespace: dagger-2025-01-03
spec:
replicas: 1
selector:
matchLabels:
app.kube...
See https://v3.dagger.cloud/dagger/traces/7ac8bb11c84ec5925eab8c0c8528c9d7#c8b39737d86fb4f8:EL46:
assertion failed:
--- expected
+++ actual
@@ -31,4 +31,5 @@
โ .stdout: String! X.Xs
! process "/bin/sh -c echo im failing && false" did not complete successfully: exit code: 1
+โ โ remotes.docker.resolver.HTTPRequest X.Xs
Error logs:
You can run 'go test . -update' to automatically update testdata/TestTelemetry/TestGolden/docker-build-fail to the new expected value.'
Most of the...
What is the issue?
In main it seems that these two pipelines should be equivalent:
dagger core container from --address postgres without-entrypoint with-default-args --args docker-entrypoint.sh,postgres,-c,log_min_messages=notice with-exposed-port --port 5432 with-env-variable --name POSTGRES_PASSWORD --value postgres up
dagger core container from --address postgres with-default-args --args docker-entrypoint.sh,postgres,-c,log_min_messages=notice without-entrypoint...
I'm kind of interested into diving into what the NFS mounts are going to be used for :eyes:
- is it for avoiding the expensive context transfer of files?
- is it to enable a faster speed between an engine-fileserver while the cli is remote and slow?
- is it to allow a writeback to the NFS server?
The use case determines what we'd want to build here I think - whether it can be entirely transparent, or whether there's a dag.NFS equivalent like we have dag.Git, etc.
I've also...
I'm curious to know the specifics of the use case here, especially around how the data in the NFS mount would be used. The two categories of data we support currently are "immutable recipe-defined layers" and "mutable cache mounts". I'm guessing the use case here probably follows the "mutable cache mounts" pattern, but want to confirm. I think this actually impacts the design pretty significantly.
I can't tell yet how much this relates back to the engine/cli split. Theoretically you coul...
We run Dagger on hosts with mounted fileshares used for file uploads/downloads. Programs may read configuration files from these shares, upload files for external API processing, or download files generated by APIs.
Currently, this workflow isn't supported in Dagger, restricting its use to a subset of CI workflows.
is it for avoiding the expensive context transfer of files?
is it to allow a writeback to the NFS server?
Yes to both. These fileshares are too large to copy, and we ...