#github-feed
1 messages ยท Page 17 of 1
Hey @gregoryboue! Just saw this. Will provide an update tomorrow :pray:
Fix for an issue that I noticed while I was testing the TS SDK in a monorepo setup.
Basically, if your context dir is /root and your module that generate the client is in /root/foo/bar, the generated content would be in /root instead of /root/foo/bar (only happens in TypeScript).
This PR fixes that behaviour :)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it- `@dependabot ...
Thaaaaaanks @vito :heart: :heart: :heart:
This prevents output from API calls like Foo.contents from showing up in the plain output, where the signal:noise ratio is very poor. (Prior art from the dots frontend: https://github.com/dagger/dagger/pull/10617)
If the session cache Release method was called while some calls were still running, it was possible for them to only be appended to the list of results after Release was already done, in which case they'd stay in the underlying cache and leak forever.
This adds handling to track when the session cache is closed and release any results that show up after that.
This seemed to be resulting in memory leaks. It wasn't perfectly repro-able, but was able to see leaks fairly often just a...
This patch improves the telemetry at client startup in a few ways:
- Earlier notification of cloud telemetry info - this ensures we can open the web view before the engine is provisioned.
- Adds logging info as a real OTEL span, instead of a virtual log. This means that we can get metadata about the versions we're actually connecting to in cloud (previously missing).
- Correctly nests the image store configuration under the "connecting to engine" span (which requires defering the loa...
What happened? What did you expect to happen?
I have a CI pipeline that use Dagger running on version 0.18.12 locally using the Python SDK.
The pipeline was working fine but due to a clunky step that use a lot of RAM, my computer (Ubuntu 22.04) freeze and crashed while dagger was running on my workstation.
When I restarted my computer and tried to run dagger again but it doesn't work anymore and I have the following error:
dagger call --debug --progress=plain
...
448 : 3dc4249ec717...
We were re-using the same code path for stdout/stderr collection which enforces a 100kb size limit. Applying this to the error extraction resulted in the Error ID also being truncated, which led to errors falling back to the unhelpful process "/runtime" failed with exit status 2-esque error.
Example: https://dagger.cloud/dagger/traces/9c9ac34fec07079afbc9b6a737ffacaa
Now we only enforce the limit for stdout/stderr and allow the Error ID to be arbitrarily large.
@sipsma I know you m...
- A module may reference another as its blueprint.
- fix install
What happened? What did you expect to happen?
Hi there. I created this issue to document how a recent change to the engine impacted us when upgrading. We have since solved our issue, but I thought it might be interesting to document it here.
Our organisation deploys a single version of the dagger engine for our CI runners - this is because it would be too expensive to deploy multiple versions. Dagger modules across repos are subject to the CI version and when upgrading, all CI builds ar...
@marcosnils no update ? ๐
Fixes:
TODO:
- [x] Nerdctl / Finch
- [x] Integration tests
- [ ] Manual sanity checks
- [x] Podman
- [x] Integration tests
- [x] Manual sanity checks
- [ ] Apple
container
@gregoryboue my apologies :see_no_evil:, got swamped with some other stuff this week. Will reply today for sure :pray:
What is the issue?
This appears to be a regression with some of the recent changes to how enums operate. In the past I could have a module that looks like
type Dependency struct {
Opts []dagger.ContainerPublishOpts // +private
}
func New() *Dependency {
return &MyModule{Opts: []dagger.ContainerPublishOpts{
{PlatformVariants: []*dagger.Container{dag.Container().From("alpine")}},
}}
}
func (m *Dependency) Publish(ctx context.Context) (string, error) {
return dag.Container()....
hey @gregoryboue! I was finally to find some time to leave my thoughts here.
There's a long thread we could pull from here about "good" design / software practices and what would be the "best" way to model this. Having said that, I'll try to be brief and cut to the point about how I'd approach this knowing Dagger's limitations while also trying to to put myself in your position of delivering the best experience for your module creators and adopters.
Change the way we design our modu...
Bumps the docs group in /docs with 1 update: posthog-js.
Updates posthog-js from 1.256.2 to 1.257.0
Release notes
Sourced from posthog-js's releases.
1.257.0 - 2025-07-08
one for flags and flags for all (#2079)
Fix comment (#2078)
feat: Enhance AssignableWindow type with additional properties for better SDK integration (#2077)
reset flags internal state when posthog.reset is called (#2066)
Commits
a004c9a chore: Bump version to 1.257.0
d7121...
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it- `@dependabot ...
Bumps the sdk-java group with 2 updates in the /sdk/java directory: org.apache.commons:commons-lang3 and org.junit:junit-bom.
Updates org.apache.commons:commons-lang3 from 3.17.0 to 3.18.0
Updates org.junit:junit-bom from 5.13.1 to 5.13.3
Release notes
Sourced from org.junit:junit-bom's releases.
JUnit 5.13.3 = Platform 1.13.3 + Jupiter 5.13.3 + Vintage 5.13.3
See Release Notes.
Full Changelog: https://github.com/junit-team/junit-framew...
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it- `@dependabot ...
And update goreleaser for good measure.
Nix requires cp from coreutils (for reasons, it's annoying). Thankfully, we can just install those.
Small CI maintenance chore
Looks like this was a "simple" case of the conditional being the wrong way round. Fixing that though means we need a better way of ensuring that we doFetch correctly.
Instead of going through the buildkit gateway, directly invoke and call the mount manager from inside of dagger. This is a follow-up to #10457, it's essentially the exact same transform, but for services.
This turns out to be a dependency for changes we'd like to do around #6990 - if we have direct access to the mount manager, then we open the way to propagate synced directories in.
[!WARNING]
This is work-in-progress! :construction_worker_woman:
What are you trying to do?
When configuring a Service with certificates and doing up the output shows
tunnel started port=443 protocol=tcp http_url=http://localhost:443
Despite the fact the URL is actually https://localhost.
This is purely cosmetic, as visiting the HTTPS URL works as expected.
But it would be nice if Dagger could somehow detect if a Service was using TLS and show the output accordingly. I'm not sure how this could be implemented, but perhaps a check again...
Two little tweaks to improve error UX:
- Preserve the error origin when setting the root span error, so we can be 100% sure what error was the root cause of the failure.
- Always reveal error origins. Currently it's easy for these to be hidden by other spans that configure
reveal: true.
Hi @marcosnils,
Thanks for the answer.
For the moment i think we will continue to have duplicate code in separate module, to keep better code readability.
Are you planning anything to make dagger support inheritance better ?
We added support for module interfaces a while back.
However, we never went the full way and we didn't ever need interfaces in the "core" module (the main dagger API). So it just doesn't work right now.
There are several cases I think we should support:
- Allowing core types to implement core-defined interfaces
- Some types just make more sense as an interface! They already have multiple "backends", like
GitRepositoryorService. We should expose this implied interface as a real int...
- Some types just make more sense as an interface! They already have multiple "backends", like
Problem
Suppose a user is working on a fairly standard frontend/backend project. The user will likely have two separate Services for each service:
func (MyModule) Frontend(
// +defaultPath="./src/frontend"
src *dagger.Directory,
) *dagger.Service {
return dag.Container().
From("node:latest").
WithWorkdir("/src").
WithMountedDirectory(".", src).
WithExec([]string{"npm", "install"}).
WithExec([]string{"npm", "build"}).
Wit...
Fixes https://github.com/dagger/dagger/issues/10715.
This doesn't mean these values have become allowed, the engine will still reject them. However, now, they can correctly be used in private fields again, like they used to be.
This introduces a new structure and layout for the documentation.
Things left to be done:
- [ ] Finish migrating and merging the content into the new pages
- [ ] Add/update all of the redirects from the old URIs to the new ones
- [ ] Get feedback on the look and feel as well as the navigation, content, and structure
Prints https is the service port is 443. This is not a bullet proof
solution but it's extremely unlikely that a service would use port 443
without listening for TLS traffic.
fixes #10724
Signed-off-by: Marcos Lilljedahl
What is the issue?
Problem
As stated in the title, seems like calling .refresh doesn't seem refresh/reload the module you're working on. If you make any changes like removing / adding functions or changing their arguments, .refresh doesn't seem to reflect that.
I'd assume this is a regression since I recall seeing this working in previous Dagger versions
Dagger version
v0.18.12
Steps to reproduce
- Create a module
- Run
dagger shell - With the shell open, add a ...
Update local module loading to lookup for all .gitignore files inside the context directory
Add IgnorePattenrs in LocalModuleSource.
Apply IgnorePatterns when loading contextual directory argument.
Essentially, the opposite of https://github.com/dagger/dagger/issues/8025.
We should be able to import images from the local container runtime. Probably under the Host API, so something like dag.Host().Container(""). That matches up with how we load files/directories already.
This way, it would be possible to do something like:
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
my-img latest d4a4cfe3b1dd 2 mi...
(This is currently only a known issue on main, not in a release yet, just creating to track fixing it before next release)
The evals workflow has been failing with errors along the lines of instantiate: toSelectable: unknown type EvaluatorEval. Similar errors reported by users testing off main w/ interfaces.
Caused by https://github.com/dagger/dagger/pull/10620
Have a basic idea of what's wrong here, working on a fix
What is the issue?
For security and consistency reasons, both Cache Volumes (https://github.com/dagger/dagger/issues/7211) and Secrets are scoped by default to the modules they're defined in. If users have a need to share them across modules, they need to intentionally pass a reference to those resources via constructor or function arguments.
We don't mention anything in our docs neither here https://docs.dagger.io/api/secrets/ or here https://docs.dagger.io/api/cache-volumes/ and th...
This introduces a new execInMount function, which deduplicates a lot of the boiler plate code needed to perform dagops.
Takes a Git-compatible patch string and applies it to the directory, using git apply under the hood.
This way you can make incremental changes to a directory without having to add entire new file contents at a time. Also supports binary diffs, so this is a bit beefier than patch -p1.
Simplify Env with generic bindings. This is part of #10370
[x] New core type: ID. A generic ID for any Dagger object.
[x] New core function: Env.withBinding. Create a new binding with the given ID as value.
[x] New core function: Env.binding. Retrieve a binding.
[x] New core function: Env.bindings. List all bindings.
[ ] Deprecate Env.with[XXX]Binding
[ ] Deprecate Env.inputs and Env.outputs
Fixes https://github.com/dagger/dagger/issues/10434. These fields can easily be constructed and be nullable.
Before:
โฏ echo "{module{name,runtime,source}}" | dagger query
โถ connect 0.2s
โ moduleSource(refString: ".", allowNotExists: true): ModuleSource! 0.0s
โถ .configExists: Boolean! 0.0s
โ module: Module! 0.0s
โ .name: String! 0.0s
โ Module.runtime: Container! 0.0s
โ Module.source: ModuleSource! 0.0s
Full trace at https://dagger.cloud/jedevc/traces/cbb397e127bbea...
What is the issue?
Under high concurrency scenarios, the Python client exhibits performance issues and instability not observed with the Rust client. Specifically, the Python client can create a combinatorial explosion of sandboxes when a single node is hit by many users simultaneously, resulting in significant slowdowns.
Feedback from user (@igrekun):
โThe way Python and Rust manage global Dagger sessions is a bit different.
When using the Python client through an HTTP server under ex...
- based on #10742
- uses
ripgrep --jsonunder the hood (added to engine image) - returns a structured
[SearchResult!]!output
A teeny tiny QoL for when you run Dagger from Claude Code. Right now it uses the plain format which is too overwhelming. It seems to handle --progress=report really well.
Fixes https://github.com/dagger/dagger/issues/10738
There was a very subtle issue where ObjectResults were accidentally being "downgraded" to Result when dagql call internals were attempting to unwrap them. This was due to unintentionally calling DerefValue on the embedded Result of ObjectResult and returning the received, which was a Result rather than full ObjectResult.
This broke interface loading specifically because we currently rely on some objects already being select...
Seeing some flakes on main+PRs with session cache is closed, e.g. https://dagger.cloud/dagger/traces/2c21ffb6385408be6b9b89cf9e7bec4d?listen=ac11982282afb038&listen=87dded5a7770eee9&listen=52f3eb5dc55d05b4&listen=b4c672b2d466aa9f#165234f9b49aa894:L1735
https://github.com/dagger/dagger/pull/10708 introduced that error case; it's correctly error'ing because we shouldn't be trying to use session caches that are closed (and doing so can result in memory leaks), so need to find where we are s...
Will fix https://github.com/dagger/dagger/issues/10750
Draft, haven't had success repro'ing locally yet so gonna parallelize in CI
[dagger/dagger] Pull request opened: #10752 exp: allow to run dagger 'tasks' from a dagger.yaml file
This is experimental, just to see if that could be a good idea or not.
All start with a dagger.yaml file you can put in your project. The dagger.yaml file is composed of two sections: vars and tasks.
vars allow to define some variable (could be basic variable like strings, or more complex using any dagger primitives).
For instance this is declaring a Go version and defining a ctr variable representing a basic container to work on a go project:
vars:
go_vers...
A new feature in the engine API: load resources from the host using a single standardized address.
This is a feature that already exists in the CLI, but we're moving in the engine so that it can be used from other places. Specifically a persisted config file to pre-configure default values. Most especially default secrets.
Noticed the v3 UI was choking on traces generated by dev engines, because encoding/gob can't handle []any. SpanSnapshots get sent over the wire with encoding/gob for performance reasons; it's generally safe because we control both sides (client + server), so we don't need to worry about schemas and compatibility drift, but it does restrict what types we can feed into it.
Quickly extracting this rough proposal from [a Discord discussion](#1346164284278706258 message) since it's come up a couple of times now.
We have a lot of the primitives already to build a pretty nifty prompting API, building on the existing 'prompt to allow module to use LLM' code path.
type Query {
prompt(
"Markdown-formatted message to display."
message: String!
): Prompt!
}
type Prompt {
"Request a y...
Despite squashing a number of occurences, we are still seeing occasional flakes related to using stale sessions. These errors do mean something unexpected is happening with the lifecycle of session caches and should be an error in the long term, but in the short term it's not strictly necessary to return them; things should generally work.
This update thus downgrades returning the error to just logging it, while still avoiding memory leaks previously caused by this problem.
PR up first in case we want to quickfix this, looking into eval coverage now.
Edge merging is a constant thorn and may explain some remaining weirdness we are seeing with sessions disappearing and related errors.
I know that this currently results in a failure in a caching test due to content hashed mounts not applying to cache keys for execs correctly, which will need a fix before merge, but sending out now to sus out any other issues in the background.
when an agent starts going off the rails it's natural to interrupt it and course-correct. but right now that actually completely undoes the prompt and whatever progress it made.
this mistake was being made at multiple layers:
- we were Fork()ing at each prompt, even though we don't even support rewinding in the UI yet
- the $agent var handling wasn't being respected everywhere, so if WithPrompt didn't succeed it would end up resetting back to the old value in $agent
- error origins could sometimes not be wired up depending on span receiving order
- engine version scrubber choked on the
vin-dev
What are you trying to do?
I would like to inspect the host where the CLI is running to understand where exactly the dagger engine is running. As an Enterprise user of dagger, we have various compliance and security needs that we need to meet. One such need is the need to know exactly where the client (and the engine) is running.
We would like to take actions within our modules based on the host.
Why is this important to you?
An example of something we would like to do is, based ...
(reviving https://github.com/dagger/dagger/pull/10361 which can't be reopened)
Currently when the model runs something like withExec("date") it doesn't see any output - it has to call stdout or stderr to see it.
This trace shows the model trying to run various diagnost...
A sneaky workaround for the lack of self-referential inputs: when called from a module function call, this will pass the calling object in to the environment.
distributed cache is currently being reworked at a lower level so we
remove the magicache code given that it's almost likely that the new
architecture will not use it.
Signed-off-by: Marcos Lilljedahl
What is the issue?
Originally reported by @skycaptain in #1396132812377296936 message.
Dagger version
v0.18.13
Steps to reproduce
See the repro: https://github.com/skycaptain/dagger-issue-passing-secrets
In v0.18.12:
$ dagger -m ./module-b call job --netrc-file 'file:dagger.json' run
โถ connect 1.5s
โถ load module: ./module-b 19.5s
โ parsing command line arguments 0.0s
โ moduleB: ModuleB! 0.7s
โ .job(
โ netrcF...
Fixes https://github.com/dagger/dagger/issues/10663
Handling of single quotes was naive. Should've replaced them only if first and last char but simpler to just embrace the direct output from repr and let ruff reformat it later.
Also recovered default value for list arguments, although it doesn't change behavior, just makes it show on the body of the function (client binding) which can be helpful while debugging.
This allows passing build args to a docker build via the CLI.
Example
host | directory . | docker-build --platform darwin/arm64 --build-args BIN_NAME=docker-runx,NO_ARCHIVE=true --target export-bin | export .
\cc @eunomie
Fixes #10776
When a module object had a Nullable field for an object type, we were subtly setting the ID for the field to the ID that selects the field, rather than the ID for the object it wraps (when the nullable is set).
This didn't impact too much other than secrets, where it could break loading in certain situations when the secret would be attempted to be loaded from the field selector ID rather than the underlying ID for the secret from the core API.
This fixes the issue by...
What are you trying to do?
A very neat feature would be the ability to specify stdin for a command in WithExec which is a secret variable so that it doesn't get exposed in the logs.
Why is this important to you?
When trying to use the tool skopeo, I encountered its limitation that it does not expand environment variable in the login credentials. Directly supplying the credentials is a no-go, as they would be exposed then in Dagger's logs. The other option to supply a password to ...
I currently use dagger telemetry metrics to follow up container resource usage.
I would like to add custom tags to know for example image name of a container where the metrics are coming from.
I would know if someone has already done this or if it is possible to do it ?
For the moment, only these tag key are available :
I tried to set OTEL_RESOURCE_ATTRIBUTES environment variable but it doesn't add the tags to the metrics.
Thanks for your help
What are you trying to do?
I am trying to reliably access (both programmatically and in Dagger Cloud) the output of .with_exec() steps that might or might not have been cached previously. Right now it seems cached steps don't store their stdout, so cached and non-cached runs behave differently.
Related Discord thread: https://discord.com/channels/707636530424053791/1397564686618198026
Why is this important to you?
Generally speaking, caching is a technique to improve performanc...
@shykes notices that JSONValue was badly formatted when defined as object (#1397223053452120144 message)
It's the first time we have this case, that's why we never saw it before.
This PR fixes that behaviour.
What is the issue?
For context, see: https://discord.com/channels/707636530424053791/1397614015756374219
Dagger version
dagger 0.18.4
Steps to reproduce
In a repo storing the blueprint:
$> git checkout -b test
$> dagger init --sdk go --name not-main --license none --source not-main not-main
$> git add .
$> git commit -m 'chore: non-default branch module'
In a repo consuming the blueprint
$> dagger init --blueprint=ssh://github.com/nadirollo/daggerverse...
A few PRs got merged that changed the Go SDK and the end merged result on main was out of sync, just needs a regen
CI hit an error in the cache unit tests, locally I could repro it in ~2 runs when running w/ -count=100000, so unclear if it was really causing any genuine problems.
Was a legit problem though; with the right timing it was possible to remove a call from internal maps when there were waiters remaining, which would result in extra calls appearing.
What is the issue?
Two times now I have been incredibly confused by the fact that my code says this:
pub source: Directory! @defaultPath(
path: "/",
ignore: [
"Session.vim"
"dang"
"zed-dang/grammars/"
".env"
".envrc"
]
)
But then in the terminal I see this:
โ dang(
โ source: Host.directory(path: "/var/home/vito/src/dang", exclude: [], noCache: true): Directory!
): Dang! 0.4s
โ .source: Directory! 0.0s
Meanwhile,...
Fixes #10785
Repro script for reference:
set -e
mkdir repro
cd repro
cat >dagger.json <<'.'
{
"name": "test",
"engineVersion": "v0.18.14",
"blueprint": {
"name": "not-main",
"source": "github.com/shykes/x/not-main@test",
"pin": "6b29f8aa297117bc06181050cab1b067c4927c6d"
}
}
.
dagger call -q hello
dagger update
dagger call -q hello
cat dagger.json
Overview
Stable configuration for provisioning and connecting to the dagger engine from the dagger CLI.
- Deprecated:
_EXPERIMENTAL_DAGGER_RUNNER_HOST - No change:
DAGGER_CLOUD_ENGINE: connect to dagger cloud experimental engine - New:
DAGGER_ENGINE_HOST: connect directly to an engine. Supportstcp://,ssh://,unix://,container://,kube-pod://. no provisioning, no special URL flags - New:
DAGGER_ENGINE_IMAGE: if provisioning from an image, override which ima...
Problem
Officially, there is no supported way to connect remotely to an engine. But there is an escape hatch (_EXPERIMENTAL_DAGGER_RUNNER_HOST) and lots of people use it in production. In fact it has become a de facto standard for everyone running Dagger in self-hosted CI clusters.
This disconnect between what users do, and what we support, must be resolved. We face a simple choice:
- Promote the escape hatch to a fully supported feature. This means replacing `_EXPERIMENTAL_DAGGER_RU...
could you explain (roughly) how the version checks work today? How does the CLI determine whether it can use a given engine version? Are there know limitations and planned improvements to that system?
Jumping in :wave:
There are two types of version checks generally - between the engine and modules, and between the cli and the engine (the latter is what we're interested in here).
When the CLI connects to an engine it performs a naive health check by hitting a gRPC /Info endpoint - esse...
Before I can comment on this half of the proposal @gerhard @jedevc @sipsma I need the other half. Reducing the scope of conversation doesn't automatically reduce the scope of the design. It may just sweep parts of it under the rug.
If we ship a flag with no concern for provisioning, we're making a bunch of implicit decisions. For example we're deciding that any client version can connect to any server version and it's our responsibility to manage the full compatibility matrix. I think we sho...
The sequencing I'm imagining which incorporates both connecting and then provisioning
We make the hook for getting connections (what's called
_EXPERIMENTAL_DAGGER_RUNNER_HOST) public and documented
I'm good with the sequencing here, but just to nitpick - I think that one of the reasons to design these together, is that the docker-image:// in _EXPERIMENTAL_DAGGER_RUNNER_HOST today is actually more of a Provisioner, instead of a Connection Driver. So ideally I'd like to sketch a pa...
We talked about this with @jedevc & @sipsma and the key take away from that conversation is that we want to split the connecting & provisioning concerns.
Today, _EXPERIMENTAL_DAGGER_RUNNER_HOST combines both concerns and therefore pulls in the Compute Drivers context. Before we stabilize _EXPERIMENTAL_DAGGER_RUNNER_HOST into a first-class feature, the consensus is that we want to reduce its scope. The proposal is to:
- Introduce a new CLI ...
We assume that an Engine exists, and we need to connect to it via a remote TCP/IP connection. That is the boundary of this issue, both in terms of discussion & design.
I just started collecting my thoughts on how an Engine gets provisioned, via a "compute driver" in the other issue, which is focused on creating & deleting Engines, with no connection concerns.
I don't see the coupling or sequencing requirement between creating / deleting and connecting. Do you @jedevc @...
The "REP", the protocol that is private today but we are considering making public
@shykes We don't need to make all of that public. The only thing we need to be made public is the hook the CLI uses to get a network connection to the engine server (in concrete terms, the CLI needs a net.Conn). Today the various values of _EXPERIMENTAL_DAGGER_RUNNER_HOST are just specifying how the connections are made:
tcp://,unix://, etc. - just directly connect using normal ip/unix socket- `s...
Would it make sense to push the Provisioners discussion into what is today called https://github.com/dagger/dagger/issues/5583 and keep this issue focus on the Connection Driver?
No, we have to discuss it together. I challenge that "connection driver" and "provisioner" are even different concepts. It's all compute drivers to me. By splitting them up before even discussing their design, you're front-loading a design decision before the design discussion even started.
It may be possible now to use Copilot APIs as an LLM provider allowing users with Copilot access to use those models within Dagger.
Looking at the implementation in sst/opencode, we should be able to initiate an oauth flow with Copilot. There are some references to using a token as well which may or may not actually work. Needs investigation.
With token (may not work):
Set base_url to https://api.githubcopilot.com
Get the api key from ~/.config/github-copilot/apps.json
Oauth flow:
http...
Follow up fix for https://github.com/dagger/dagger/pull/10580 to make the trace-url available to the SDKs. Looks like the cloudOrg wasn't being passed through to nested sessions, so it would work with dagger core cloud trace-url but not via SDK
What is the issue?
I am trying Module self-invocation with an LLM (not released, using a dev build on that PR #10584).
The pattern is convenient because it avoids creating a separate module for the toolset, you can simply expose the current module to the LLM.
However we get back to the problem of filtering functions available to the LLM. Here is what happens:
Example:
type MyModule struct{}
// Tool1
func (m *MyModule) Tool1(ctx co...
Bumps the docs group with 3 updates in the /docs directory: posthog-js, typedoc and typedoc-plugin-markdown.
Updates posthog-js from 1.256.2 to 1.258.2
Release notes
Sourced from posthog-js's releases.
posthog-js@1.258.2
1.258.2
Patch Changes
#2111 7114593 Thanks @โpauldambra! - checks for session activity i...
Bumps the engine group with 9 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.75 |
0.17.78 |
| github.com/anthropics/anthropic-sdk-go | 1.4.0 |
1.6.2 |
| github.com/containerd/containerd | 1.7.27 |
1.7.28 |
| github.com/mark3labs/mcp-go | 0.33.0 |
`... |
Closes #9263
The Rust SDKโs โUsageโ snippet in sdk/rust/crates/dagger-sdk/README.md no longer compiles because connect now requires you to pass a closure. This PR updates the example to:
dagger_sdk::connect(|client| async move {
// 1) Spin up a Go 1.19 container
// 2) Run โgo versionโ inside it
// 3) Grab the printed output
let version = client
.container()
.from("golang:1.19")
.with_exec(vec!["go", "version"])
.stdout...
Bumps the sdk-java group with 4 updates in the /sdk/java directory: io.netty:netty-common, io.netty:netty-handler, org.apache.commons:commons-lang3 and org.junit:junit-bom.
Updates io.netty:netty-common from 4.2.2.Final to 4.2.3.Final
Commits
aef99f0 [maven-release-plugin] prepare release netty-4.2.3.Final
a79d8a2 Generate missing javadocs jar
29a9678 Fix staging of codec-...
Fixes https://github.com/dagger/dagger/issues/10781.
This allows reading stdin from a file in the container - we name this option RedirectStdin to be inline with RedirectStdout/RedirectStderr.
Before:
$ time dagger call -m github.com/dagger/dagger/version@main version
v0.18.15-250728111339-1a8c04db77d6
Full trace at https://dagger.cloud/jedevc/traces/fa964659c3e20b2df74c3b43590d70ab
dagger-dev call -m github.com/dagger/dagger/version@main version 3.44s user 0.88s system 4% cpu 1:37.37 total
$ time dagger call -m github.com/dagger/dagger/version@main version
v0.18.15-250728111339-1a8c04db77d6
Full trace at https://dagger.cloud/jedevc/traces/8276c6e06d137a4fd0b66...
This changeset fix default value in Elixir doesn't set properly when default value declared via :default option.
Now if user declare a signature like:
defn sample(hello: {String.t(), default: "world"}) :: String.t() do
hello
end
The defn will transform into:
def sample(hello \\ "world") do
hello
end
The dagger mcp command exposes a dagger module as an mcp server
To better support turning your daggerized projects into a usable mcp server for agents, we must make the interface 'dumber'. The idea is that chaining dagger types via API calls is too complex of a flow for agents to successfully follow.
Proposal
- The
dagger mcpcommand should not expect clients to support dynamic tools - Function calls only return scalars
- Core types can have an auto-scalar resolution. Such as `F...
What is the issue?
Blueprint modules
#10464 #10712
in order for kernel modules to be automatically loaded on startup, the
file should be named with a .conf extension.
ref: https://man7.org/linux/man-pages/man5/modules-load.d.5.html
Signed-off-by: Marcos Lilljedahl
What is the issue?
https://github.com/user-attachments/assets/fbeefc9a-a49e-4151-9b35-afaa772cc018
A repro with dagger 0.18.4 and an engine built from main.
The issue happened with the 0.18.4.
https://dagger.cloud/Quartz/traces/57b929a4d8811682c82534b10789c063#f4f0d42dba4159ba
Dagger version
0.18.4
Steps to reproduce
I had trouble reproducing the issue but I think the bug happens when I switch my dev engine version:
- Build a dev engine from main
- Run dagger functions (o...
Fixes #10737 as a follow-up to #10662.
TODO:
- [ ] Tests passing
- [ ] Cleanup
- Move more implementation to
core/
- Move more implementation to
This had a FIXME, we've wanted to do this for a while.
We can deprecate functions whenever we like, depending on time-frame we could remove this in the next minor release.
We've got some deprecated fields which can be removed for v0.19.0:
withAuthToken/withAuthHeader, deprecated since #10248keepBytes, deprecated since #8725setSecretFile, deprecated since #9682
What is the issue?
Description
I'm deploying Dagger as a DaemonSet on a Kubernetes cluster, and I've set CPU and memory limits on the dagger-engine pods. However, the containers launched by Dagger (dagger core container from ...) do not inherit these resource constraints, and can consume significantly more memory than specified.
Dagger version
dagger v0.18.12 (unix:///run/dagger/engine.sock) linux/amd64
Steps to reproduce
Setup
- Dagger version:
v0.18.12
-...
Context
In our company, we use Dagger as the CI engine for our software factory, which is used across all IT departments (DSI).
Dagger is deployed as a DaemonSet in our Kubernetes cluster.
As part of our billing and usage tracking, we need to collect metrics from containers launched by Dagger, which uses the BuildKit SDK under the hood to spawn runc containers.
We use Datadog as our monitoring solution.
However, currently, metrics from these runc ...
[dagger/dagger] Issue opened: #10815 Break backwards compatbility for session attachables in v0.19.0
[!WARNING]
Milestoning so I don't forget :eyes:
There's a lot of clutter in the session attachables to make sure that we can handle old clients/engines - but this is getting a bit tricky to manage. Since v0.19.0 is a minor release, it feels fairly reasonable to bump this (so clients =0.19.0 and vice versa).
We should bump here: https://github.com/dagger/dagger/blob/aaa13befbe949553e6f0f3deb1b03ff5be2f34ec/engine/version.go#L32-L38
And then declutter: https://github.com/search?q=repo%...
This restriction seems to have been introduced way back in #6482. Regardless, it does just work, and it's very annoying to hit an error condition and then have to remove the --output flag to just get it working.
Setup
Assume the following module:
package main
import (
"context"
"dagger/foo/internal/dagger"
)
type Foo struct {
Entries []string
}
func New(
ctx context.Context,
// description goes here
// +defaultPath="./arg"
// +ignore=["foo.txt"]
myArg *dagger.Directory,
) (*Foo, error) {
entries, err := myArg.Entries(ctx)
if err != nil {
return nil, err
}
return &Foo{entries}, nil
}
With the following testdata:
$ mkdir arg
$ touch arg/{foo,bar}.txt
Get the t...
This will allow module authors to mark parts of their API as deprecated (currently not possible).
For example, in go:
package main
import (
"context"
"dagger/foo/internal/dagger"
)
type Foo struct {
MyDeprecatedField string // +deprecated
}
// +deprecated
type MyAdditionalType struct {
X string
}
// +deprecated
func (foo *Foo) MyDeprecatedFunc() {
}
func (foo *Foo) MyOtherFunc(]
myDeprecatedArg string // +deprecated
) {
}
[!NOTE]
This requires that we all...
Today, the functions and their args do not illustrate some common best practices and style.
The large comment block is simply removed by most and so we should make it much shorter and to the point.
Fixing this will help adoption.
- [ ] module comments shortened to essential
- [ ] functions/args reworked
- [ ] tests updated
Previously, the following operations were failing:
mkdir test && cd test
dagger init
dagger client install go
Because the go client generator assumed that the module was aside a go module, same as module generation before we generate a default go.mod.
This PR fixes that issue by: generating a default go.mod based on the module name if no go.mod exist in the current directory. This allows an user to create a submodule in a go project and import the client from there.
Al...
Add Kubernetes Service for Dagger Engine
Context
We operate a large-scale software factory supporting key business units (DSM/DSI).
To enhance our CI capabilities and accelerate delivery, we are deploying Dagger as our new CI solution.
Our setup:
- Dagger runs as a DaemonSet in Kubernetes
- Shared Dagger modules live in GitLab
- Projects use these modules via GitLab CI pipelines
This aims to provide a scalable and reliable CI platform aligned with our bu...
What is the issue?
Error logs:
โผ asModule getModDef 1.7s ERROR
[ERROR] Dagger\ValueObject\Type should not be constructed for arrays, use ...
What are you trying to do?
As part of https://github.com/dagger/dagger/pull/10714, we should also consider making the necessary changes into the engine default registry authentication mechanism (i.e: reading dagger.json) so images can be automatically pulled from private registries if the client is already authenticated.
Why is this important to you?
No response
How are you currently working around this?
No response
- Updated default uv version to 0.8
- Changed default build backend to uv_build instead of hatchling now that it's stable
- Changed default Python version to 3.13
What are you trying to do?
A discussion more than a feature request (yet!)
How would you feel about adding a new parameter, when installing a --blueprint that allows the dagger call to always fetch the latest ref?
Our platform team maintains many pipelines, and we expect our consumers to be on the hundreds.
Introducing new functionality, improvements or chaging behind the scenes implementations (e.g. migration from an artifact registry to another), requires our consumers to update...
What are you trying to do?
I suggest to add flag --status to dagger login so it will be easy to check login status of the user.
Why is this important to you?
I like to create simple scripts to call specific dagger functions to hide some complexity from my collegues.
And I would like to keep them logged in to Dagger Cloud so they can enjoy web traces and magic cache.
But I don't want to force them to login with blocking call dagger login. So I would like to check the login sta...
A small feature, this basically unwraps the error exec to unwrap the error such that we show more clearly what fails and whatnot.
What is the issue?
I was checking out the hidden dagger client install command that I learned about from a chat in the discord.
When I ran the help command on client install to learn how it works I noticed that the option --generator was still present in the help output even though the functionality was removed in this PR-10454.
This leads to a mismatch from the command's help output and actually running the command
Dagger ver...
When running the dagger client install --help command the output suggests there is a --generator option whose functionality was removed and appeared to be missed https://github.com/dagger/dagger/pull/10454.
This PR assumes the intention was to remove that flag and cleans up the code that causes it to still show up in the commands help output.
Bumps the sdk-typescript group with 15 updates in the /sdk/typescript directory:
| Package | From | To |
|---|---|---|
| @opentelemetry/exporter-trace-otlp-http | 0.202.0 |
0.203.0 |
| @opentelemetry/sdk-node | 0.202.0 |
0.203.0 |
| @opentelemetry/semantic-conventions | 1.34.0 |
1.36.0 |
| [node-color-log](https://... |
Bumps the sdk-java group with 6 updates in the /sdk/java directory:
| Package | From | To |
|---|---|---|
| io.netty:netty-common | 4.2.2.Final |
4.2.3.Final |
| io.netty:netty-handler | 4.2.2.Final |
4.2.3.Final |
| org.apache.commons:commons-lang3 | 3.17.0 |
3.18.0 |
| org.apache.commons:commons-compress | 1.27.1 |
1.28.0 |
| [org.junit:junit-bom](https://... |
[dagger/dagger] Pull request opened: #10834 chore(deps): bump the docs group in /docs with 7 updates
Bumps the docs group in /docs with 7 updates:
| Package | From | To |
|---|---|---|
| docusaurus-plugin-typedoc | 1.4.0 |
1.4.1 |
| posthog-js | 1.258.2 |
1.258.5 |
| react | 19.1.0 |
19.1.1 |
| react-dom | ... |
See #10823
A Dagger Function is written returning an array, this requires a #[ReturnsListOfType] attribute. With the attribute missing the error message received is:
[ERROR] Dagger\ValueObject\Type should not be constructed for arrays, use
Dagger\ValueObject\ListOfType instead. If this error occurred outside ...
Fixes https://github.com/dagger/dagger/issues/8034.
Hit this, decided to do cmd+strip, which is a fairly standard way of doing "protocol variations".
In the future, we could switch the default, but decided to pass on that change for now.
Bumps the engine group with 13 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.75 |
0.17.78 |
| github.com/alecthomas/chroma/v2 | 2.19.0 |
2.20.0 |
| github.com/anthropics/anthropic-sdk-go | 1.4.0 |
1.6.2 |
| github.com/containerd/containerd | `1.7.2... |
Follow-up to https://github.com/dagger/dagger/pull/10825
Pushed as a separate PR (and in draft) so this is only published after releasing that change.
This is just a nice thing to do :tada:
We work out which contributors are external by looking at whether they're in a specific github team - any members of the maintainers tag or sdk- tag are treated as external.
Closes #10835
Users were faced with a misleading error message when returning an array from their function, but forgetting to specify its subtype.
This provides a clear message with the solution.
Shell Mode Service Object Handling Issue
Problem Statement
The Dagger shell mode cannot pass Service objects to functions that accept ServiceID parameters, specifically affecting git --experimental-service-host and http --experimental-service-host.
Technical Analysis
API Definition
The git function expects a Service object ID as defined in:
core/schema/git.go:148
type gitArgs struct {
URL string
KeepGitDir dagql.Opti...
Fixes @helderco's comment in https://github.com/dagger/dagger/pull/10800#discussion_r2251896934.
Ooops!
Follow-up to https://github.com/dagger/dagger/pull/10722
We always should have been using --first-parent here, without that, we always get all the parents, which counts all parents of a merge commit, which isn't really useful for estimating the depth.
This is also really just a guess - it's possible that different parents can end up with different depths. This means it's theoretically possible to get the wrong results here.
Fixes https://github.com/dagger/dagger/issues/10841
Affected commands
Affected functions should only be git and http if using an object passed as a variable or direct command substitution ($(...)) because from the list of commands in .stdlib these are the only ones that accept object arguments:
- cache-volume
- container
- directory
- engine
- env
- file
- git
- host
- http
- llm
- secret
- set-secret
- version
Chained funct...
Add the capability to use the remote dagger library on the Typescript SDK.
This make possible to commit the generated client bindings and simplify overall module setup.
For backward compatibility and consistency across the various setup (local, bundle, remote), I used the import map to rename the remote dependency @dagger.io/core so the user still import the client binding with @dagger.io/dagger.
Setup remote module on Node/Bun
yarn init // bun init
yarn add @dagg...
Fixes #8520. Follow-up to https://github.com/dagger/dagger/pull/10195.
[!WARNING]
This PR is under construction! :construction_worker_woman:
This allows a module to get git information about itself - it can do this through the core Git type.
TODO:
- [ ] SDK support
- [x] Go SDK
- [ ] Python SDK
- [ ] Typescript SDK
- [ ] Testing
- [x] Local source tests
- [ ] Git source tests through http://github.com/dagger/dagger-test-modules
This is pretty much the main reason we need our own Git implementation in version/git.go (which is slow).
See https://github.com/dagger/dagger/pull/10801 for more context.
We can implement this ourselves (with a reasonable amount of reshuffling and refactoring).
What are you trying to do?
User asked:
Another question on this .... is a --source that is a git repo a full clone? Am I supposed to have access to all the tag and metadata?
Short answer, no.
since i'm working with azure repos it complicates things. Good to know i explored all options. made it a little tricky ๐
You can look at
dagger -M -c 'container | from alpine/git | with-workdir /a | with-exec git,clone,https://github.com/dagger/dagger,. | terminal'
vs
dagger -M -c...
Optimize performances by moving the gitIgnore loading into a dagOpWrapper internal operation so it's cached
more efficiently.
This PR follows up #10736 and apply this comment: https://github.com/dagger/dagger/pull/10736#discussion_r2254524913
Benchmarks
What is the issue?
I am using the Container Use MCP. One of my projects included a git submodule and when an agent tries to create an environment with that repo, the git SSH command fails due to not having an SSH key (it's a private gitlab repo). I dug into how Container Use works, then how it invokes dagger session to create the dagger engine docker container.
My issue is this container never gets my host's SSH auth socket mounted. Reading the Dagger docs, they claim this should happ...
Previously, cloning a repository with HTTP(S) authentication worked for the parent repo but failed for submodules because the auth header was not passed down to git submodule update. This change injects the correct http.:///.extraheader into the environment for all Git commands run by the engine, ensuring submodules receive the same credentials.
Key changes:
- Updated
RemoteGitRepository.setupto add the extraheader viaGIT_CONFIG_*env vars instead of only passing-cargs to th...
Alpine Linux 3.22 updated their Go package from 1.24.4 to 1.24.6-r0 on 2025-08-08. This change updates the Go version constant to match the available package, fixing the build error when building the dev version of the engine:
go-1.24.6-r0.apk disqualified because "1.24.6-r0" does not
satisfy "go~1.24.4"
The constraint "go~1.24.4" specifically requires version 1.24.4.x, but Alpine no longer provides this version: https://pkgs.alpinelinux.org/package/v3.22/community/x...
- Change the Elixir image from
hexpm/elixirtoelixirwhich's maintained by Erlang Ecosystem Foundation Team (https://github.com/erlef/docker-elixir). - Bump the Erlang OTP to 28
[dagger/dagger] Pull request opened: #10859 chore(deps): bump the docs group in /docs with 4 updates
Bumps the docs group in /docs with 4 updates: docusaurus-plugin-typedoc, posthog-js, sass and typedoc.
Updates docusaurus-plugin-typedoc from 1.4.1 to 1.4.2
Changelog
Sourced from docusaurus-plugin-typedoc's changelog.
1.4.2 (2025-08-04)
Patch Changes
Fix error when () ...
Bumps the engine group with 18 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.75 |
0.17.78 |
| github.com/alecthomas/chroma/v2 | 2.19.0 |
2.20.0 |
| github.com/anthropics/anthropic-sdk-go | 1.4.0 |
1.8.0 |
| github.com/containerd/containerd | `1.7.2... |
Bumps the sdk-java group with 7 updates in the /sdk/java directory:
| Package | From | To |
|---|---|---|
| io.netty:netty-common | 4.2.2.Final |
4.2.3.Final |
| io.netty:netty-handler | 4.2.2.Final |
4.2.3.Final |
| org.apache.commons:commons-lang3 | 3.17.0 |
3.18.0 |
| org.apache.commons:commons-compress | 1.27.1 |
1.28.0 |
| [org.junit:junit-bom](https://... |
What are you trying to do?
I am currently building an experimental Continuous Delivery (CD) pipeline using Dagger to release software & configuration changes to our CDN platform. This requires taking multiple inputs, such as the details of the person making the change, the artefacts to release (packages & versions, configuration changes) and the list of targets (physical machines) to deploy the changes onto. This input data must be validated, and is stored beyond the lifetime of the Dagg...
Pretty much this:
https://github.com/dagger/dagger/blob/40dba8d312c76caed679a9ba952048c52c96a259/core/git.go#L789-L794
Problems:
- Bad caching. If a submodule A is already in the cache as repo A, we won't actually clone after that.
- Weird auth. See https://github.com/dagger/dagger/pull/10855#discussion_r2266427963. We should be able to configure auth for submodules.
- Inflexible. While we can configure the
--depthof a clone, we can't do this for submodules - we always go to ...
What happened? What did you expect to happen?
I'd like to get confirmation if it is or not, per discussion with @jpadams last week.
If it's a problem then there is likely a bug to report based on our discussion caused by a combination of someone running ECI and a dagger command overwriting content in the .git directory that probably needs to be added.
https://docs.docker.com/enterprise/security/hardened-desktop/enhanced-container-isolation/
With the ability to get a Dagger Cloud trace URL from the Dagger client, its now possible to attach the current session as in-toto attestation evidence on an artifact produced from your Dagger function.
This is created from the in-toto predicate template
This markdown file once on main will be pointed to by the URL https://dagger.io/evidence/trace-url/v1
An example use case for this predicate t...
What are you trying to do?
For local testing we use the serve functionallity. One of our containers stores a SQLite DB file and writes that to a mounted directory. With docker compose this file was then available and persisted at the mounted directory. With daggers withMountedDirectory nothing is written to the mounted directory.
The docs state as much:
any changes to mounted files and/or directories will only be reflected in the target directory and not in the mount sources
I wish th...
What is the issue?
A trailing slash is commonly used in .gitignore files to ignore complete folders. In one of my projects, I have the following lines to ignore all build directories:
# Ignore build directories
build*/
In the same project, I have a file as part of my Dagger module under .dagger/build.go. Recent versions of Dagger appear to have an issue where this file is ignored when running the module as shown below. The problem can be mitigated by renaming the file, but it...
Sparked by a bug reported by @jasonmccallister.
- Essentially, not every SDK supports generating/displaying sourcemaps, so these fields must be nullable.
- We weren't displaying sourcemaps for modules loaded from directories / git (we were only doing local).
- We can very reasonably display for these cases.
- We just need to construct an HTML URL!
- Propose rule in style guide for capitalization
- Update text to match proposed style rule
- Add back missing link to engine config schema
- Update reference overview page to be in sync with latest nav changes
- Propose rule in style guide for capitalization
- Update text to match proposed style rule
- Add back missing link to engine config schema
- Update reference overview page to be in sync with latest nav changes
By using the -E flag, or the E hotkey, we can enter a special TUI no-exit state.
While in this state, even after the dagger operation is completed, we keep the TUI open and running. However, previously, we were completely shutting down the session and the telemetry.
For some interesting future operations (e.g. #10867), we want to defer these callbacks until we're quitting the TUI completely - we want to keep an active client as long as the TUI is running in some form :smile:
This is a HUGE PR resulting from a bunch of experiments that sort of blended from one to another. (Sorry... again. I'll split this up after my wedding. :sweat_smile:)
The big things:
Envnow has a filesystem, which automatically propagates between tool calls and gets re-hydrated as contextual args to modulesLLMnow supports MCP servers (in other words,LLMis an MCP client), which also run with the same filesystem, and even propagate changes out to subsequent tool calls
*...
Close #8558
Adds two tests for constructors in PHP modules:
- Asserts it receives arguments to the constructor method correctly.
- Asserts it can manipulate arguments inside the constructor body correctly.
I also added a .gitignore for php test data so that I don't have to keep manually deleting READMEs and such.
This PR moves files and directories to reflect the final agreed navigation for the site. The intent is to arrange the filesystem logically and make it easier to locate specific pages using the public URL.
There are a lot of files in this PR, however the majority of the diff is physical movement rather than content update.
What is the issue?
Specifying $HOME environment variable in some Container.With* method does not expand the environment variable to what it's pointing to, despite the environment variable being defined in the container.
Is this a bug or is there something I am misunderstanding?
I am working around this by just writing out the path to $HOME, so it's not the end of the world, but it's an annoyance.
Dagger version
dagger v0.18.14 (docker-image://registry.dagger.io/engine:v0.18...
What are you trying to do?
SDK's can now implicitly expose a "getter" function on properties: https://docs.dagger.io/api/state/
The PHP SDK will want to implement this for feature parity.
Why is this important to you?
Feature parity with other SDKs.
Reduce boilerplate code for getters.
How are you currently working around this?
Write fully fledged DaggerFunctions like this:
#[DaggerFunction]
public function getFoo(): Foo
{
return $this->foo;
}
Implements my suggestion in https://github.com/dagger/dagger/issues/10868#issuecomment-3183991570.
We remove the original approach from https://github.com/dagger/dagger/pull/10736, which attempts to convert gitignore-style patterns into dockerignore-style patterns (supported by buildkit, which uses mobypatternmatcher). Instead, we add a gitignoreFS, which creates a filtered FS in the style of filterFS, but that automatically extracts gitignore filters from .gitignore files in the...
Hello,
We have started seeing this issue when using the python sdk (as an app, not a dagger module):
dagger.ClientConnectionError: Failed to establish client connection to the Dagger session: Failed to build schema from introspection query: Unknown argument "includeDeprecated" on field "__Field.args".
I believe it is due to a recent release in the gql python library.
I have forced the version of gql to `3.5....
The problem: public repositories must expose their credentials if they wish to send telemetry Dagger Cloud. We expose our DAGGER_CLOUD_TOKEN in this repository. Since its only telemetry we don't worry much. But as we introduce compute-related features its critical that we have a secure mechanism to authenticate against api.dagger.cloud without exposing sensitive credentials.
To fix this issue we implement an OIDC authentication flow against our cloud API. To use this mechanism users need t...
Summary
Fixes a critical build failure in the TypeScript SDK caused by a missing OpenTelemetry Jaeger exporter dependency. The @opentelemetry/sdk-node package dynamically imports @opentelemetry/exporter-jaeger but this dependency was not included in the package.json, causing webpack and other bundlers to fail during build.
Problem
Projects consuming @dagger.io/dagger would encounter the following build error:
Module not found: Can't resolve '@opentelemetry/exporter-jaeg...
Fixes https://github.com/dagger/dagger/issues/10885.
We need to release this ASAP.
Additional fix for https://github.com/dagger/dagger/issues/10885.
See the graphql spec at https://github.com/graphql/graphql-spec/blob/main/spec/Section 4 -- Introspection.md
Somehow, we weren't supporting the includeDeprecated arg in all the required places. This probably appeared when we did the original import into dagql, but until gql 4.0.0, no graphql client was actually querying these fields.
Reverts both https://github.com/dagger/dagger/pull/10736 and https://github.com/dagger/dagger/pull/10853.
There's a fairly bug in the pattern conversion approach: https://github.com/dagger/dagger/issues/10868. It's not immediately obvious that it is at all fixable with the current approach, and I think more major refactoring in the form of https://github.com/dagger/dagger/pull/10883 is actually required.
However, the original author of the original patch is currently on PTO (and my re...
[dagger/dagger] Pull request opened: #10891 chore(deps): bump the docs group in /docs with 4 updates
Bumps the docs group in /docs with 4 updates: posthog-js, typedoc-plugin-markdown, @types/node and markdownlint-cli.
Updates posthog-js from 1.259.0 to 1.260.1
Release notes
Sourced from posthog-js's releases.
posthog-js@1....
Bumps the sdk-java group in /sdk/java with 3 updates: io.netty:netty-common, io.netty:netty-handler and org.mockito:mockito-core.
Updates io.netty:netty-common from 4.2.3.Final to 4.2.4.Final
Commits
7fefa5a [maven-release-plugin] prepare release netty-4.2.4.Final
350da87 Merge commit from fork
817bab1 Add support for SOCKS5 private authentication methods (RFC#1928) (#15470)
c4ac661 ...
Bumps the sdk-typescript group in /sdk/typescript with 17 updates:
| Package | From | To |
|---|---|---|
| @opentelemetry/exporter-trace-otlp-http | 0.202.0 |
0.203.0 |
| @opentelemetry/sdk-node | 0.202.0 |
0.203.0 |
| @opentelemetry/semantic-conventions | 1.34.0 |
1.36.0 |
| [node-color-log](https://github.com/tig... |
Bumps the sdk-elixir group in /sdk/elixir with 1 update: ex_doc.
Updates ex_doc from 0.38.2 to 0.38.3
Changelog
Sourced from ex_doc's changelog.
v0.38.3 (2025-08-17)
Enhancements
Allow configuring autocomplete limit, and default it to 10 instead of 8
Display description text in docs groups
Load discovered makeup apps for CLI
Commits
0630c3c Release v0.38.3
8ba731c Bump tmp from 0.2.1 to 0.2.4 in /assets (#2139)
6f032c4 Load discovered mak...
Live development proposal
This is an mega attempt to solve #6990 - our most upvoted issue in the backlog.
It's a big issue, and there's lot of different use-cases, proposed solutions, and prototypes. This is an attempt to unbundle all this, and try and address each use case - and importantly, plot a plan going forward. The idea isn't to plan every detail, but to agree on a general destina...
Woo, I'm really smart. Introduced this in #10714.
What is the issue?
The Python SDK documentation here: https://dagger-io.readthedocs.io/en/sdk-python-v0.18.14/
Links to the archive documentation. Once we publish the new docs structure, we should make sure these links are updated to the new location on the docs.
What is the issue?
The Typescript documentation published to https://www.npmjs.com/package/@dagger.io/dagger points to an old archive version of the docs.
Once the new docs structure is published live, we should update this to point to the right location in the new docs.
Just bring back the stderr scanning :cry:
Follow up to: https://github.com/dagger/dagger/pull/10896
What are you trying to do?
Problem
Currently, the with helper in the Container type has the following signature:
with = (arg: (param: Container) => Container)
This makes it quite cumbersome to implement something like this:
dag.container()
.from("foo")
.with(retries(["mix","test"],5))
.exitCode()
Since retries needs to be able to await on the container to validate the execution.
Solution
Implement a with helper which allows passing an async func...
Don't think there's any reason NOT to do this, helps to have the debug listeners set up before you know you need'em (e.g. a deadlock).
- avoid using names since names aren't actually exposed, LLM may confuse
for filenames - don't be over-precise for withEnvVariable tool naming convention
Signed-off-by: Alex Suraci
Bumps the sdk-java group with 2 updates in the /sdk/java directory: io.vertx:vertx-web-client and org.mockito:mockito-core.
Updates io.vertx:vertx-web-client from 4.5.18 to 5.0.3
Commits
5af8f1e Releasing 5.0.3
c38d62e Set next snapshot version
035c5da Releasing 5.0.2
58cc745 Documentation must indicate when a BodyHandler is required (#2759) (#2760)
50f2e9e Set next snapshot version
ee50828 Releasing 5.0.1
f0ba...
This option got dropped during driver refactoring, which seems to have caused engine start in CI to fail >50% of the time due to sed: write error when the engine tries to setup cgroups during its entrypoint.
Previously that would happen, the engine would restart and then succeed since the sed error is ephemeral. However, without the option the engine just never starts.
This change just re-adds that to the docker run command line.
- [ ] Bikeshed API changes
Changes
Envnow has a filesystem, which automatically propagates between tool calls and gets re-hydrated as contextual args to modulesLLMnow supports MCP servers (in other words,LLMis an MCP client), which also run with the same filesystem, and even propagate changes out to subsequent tool callsLLMnow captures and displays logs in each tool call response (supersedes #10768)LLMnow exposes its tools in "dynamic mode" by default,...
Some services (like the containerd service) only listen on unix sockets. We don't really support those, all our services are tcp/udp networked.
[!NOTE]
To workaround, we're doing something like: https://github.com/dagger/dagger/blob/28043bb7c21924d5e0663abf6ef3a2b8e8591f6c/core/integration/provision_test.go#L337-L344
We put the unix socket into a
CacheVolume, and then mount it in both the server and the client.This "works", but 1. is hacky, and 2. doesn't support useful feat...
What is the issue?
Currently DefaultPath for Files will load the entire directory containing the file and then select the file from it https://github.com/dagger/dagger/blob/v0.18.16/core/modfunc.go#L644
So Host().Directory(dir).File(file)
This is surprising when that directory is large and takes a long time when we only want one file
The desired behavior is
Host().File(file)
or if we must load the directory for some reason,
Host.Directory(dir, include:file).File(file)
Dagger...
The Argument attribute has been replaced in favour of a single purpose Doc attribute.
This has been deprecated for several minor versions now and it would be good to remove this for the release of 0.19.0, since BC breaks are expected at this point already
What is the issue?
I have a function like
defn publish(ci: {boolean(), default: false}) do
...
end
The module is now crash with stacktrace:
== Compilation error in file lib/flava/container_registry.ex ==
** (FunctionClauseError) no function clause matching in Dagger.Mod.Object.Meta.validat
e/1
The following arguments were given to Dagger.Mod.Object.Meta.validate/1:
# 1
{:default, false}
Attempted function clauses (showing ...
This moves php docs generation out of the docs generator and into the sdk generation. It could kind of have gone both places - but there's a significant advantage to having it in the SDK.
We need to use the generated php code as the input to the doctum generation step - if we don't, we actually don't end up updating the docs in one pass, it requires two generation passes, which is super annoying (and means you end up running generate steps twice).
This fixes that issue!
Fix translate GraphQL Float type from float (which's incorrect) into f64.
Bumps the engine group with 19 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.75 |
0.17.78 |
| github.com/alecthomas/chroma/v2 | 2.19.0 |
2.20.0 |
| github.com/anthropics/anthropic-sdk-go | 1.4.0 |
1.9.1 |
| github.com/containerd/containerd | `1.7.2... |
This adds a new banner to let users know they can visit the old docs, it also has some small styling/spacing tweaks.
This proposal tries to address Issue #10693 by introducing engine-level authentication configuration that provides consistent private package access across all Dagger SDKs. The solution extends the existing engine.json configuration to support bundled authentication credentials that SDKs can use natively.
Problem Statement
Current Authentication Challenges
Based on [Discord discussion](https://discord.com/channels/70...
It seems like after a terminal has been run in the "background" of the TUI, we fail to restore events correctly.
This seems to affect:
- Mouse isn't restored (caused by
disableMousecalled byReleaseTerminalnot having a corresponding undo inRestoreTerminal) https://github.com/charmbracelet/bubbletea/blob/b224818d994537a25de86e2658fb9f437ea0baf4/tty.go#L41-L45 - The first key press after unbackgrounding gets dropped (not sure of this cause)
WithExec([]string{...}, dagger.ContainerWithExecOpts{
CombinedOutput: true,
})
Standard error will be redirected to the standard output and both can be retrieved at once using stdout
Order is not quarantee.
What are you trying to do?
Instead of doing
dag.Container().
WithMountedDirectory("/src", dir).
Workdir("/src")
I'd like to do
dag.Container().
WithMountedDirectory("/src", dir, dagger.WithMountedDirectoryOpts{Workdir: true})
Why is this important to you?
Nicer syntax sugar ๐
How are you currently working around this?
No response
Partial revert to #10852, but not fully.
We now only need the checkout step to do telemetry, nothing else. So we can put it more last minute, and don't need to revert any of the other refactorings.
What is the issue?
The README has two references in docs/static/img/current_docs/index/
This directory has currently been changed to docs/static/img/current_docs/indexaaa/
It would be a quick fix to the README, but I'm not sure which should be corrected, the references, or the directory name.
Fixes https://github.com/dagger/dagger/issues/10913
Ideally, we'd just call host.file here, but then we'd have to reproduce all of the other logic in LoadContext, which doesn't sound incredibly fun.
So this is a quick fix!
Platform teams can bundle authentication secrets directly within the Dagger engine, providing organization-wide authentication for all developers without requiring individual configuration
I'm gonna hard disagree here.
Obviously, it's very tricky to define exactly how all of this should work, but the problem is that there are a lot of subtle differences, and unifying it is hard - there's no silver bullet.
I think, generally, while yes, we want to allow the platform team to config...
I think in terms of moving this issue forward, we should instead:
- Add support (and add tests, and docs) for git-based private packages across all our supported SDKs.
- This currently works for go (we need the
GOPRIVATE"hack" because go is a bit special here) - Don't think it works for the others - even if it does, we definitely don't have the tests+docs to consider it completed.
- This currently works for go (we need the
- Extend git-based support to allow for HTTPS authentication (so we can avoid
insteadOf[here](https...
I think if we want to allow for a more engine driven configuration, so that end users don't need to think about it... this is an option to explore later. I would say that we would do this using a "special" secret provider, like bundle://.
However, I think that getting auth to work at all (in an entirely client-driven way) should be our first priority. Then we can explore other options (potentially, even options that are driven by cloud).
A file in a container can be references as container.file ... until you cache the directory it is in, at which point you have to mount the cache wherever you need it. This breaks code when you add caching, and is a leaky abstraction.
Dagger currently only supports UNIX based OpenSSH agent forwarding
The underlying reason is:
- The current socketStore only supports UNIX + IPSocket, no named pipes
- We query the PATH to the socket (https://github.com/dagger/dagger/blob/3dfb4eeba6308ce86f1bbdc2368247eddb08bba9/engine/client/client.go#L1149), by honoring
SSH_AUTH_SOCK. However, not all clients on Windows respect it and j...
- add descriptions to extending Dagger pages
- cleanup custom app table with icons (cc @jedevc)
- fix some CSS styling
- Collapse some sidebar items to reduce the need to scroll
What is the issue?
I am using the following query and have tested both Typescript and Go modules using the documentation example and asEnum.members are always null for both.
Here is the GraphQL:
query directoryAsModule {
host {
directory(path: ".") {
name
asModule {
id
name
objects {
kind
asObject {
description
name
functions {
id
name
desc...
based on #10907
- Add
Directory.search - Add
File.withReplaced - Add
Directory.changes(older: Directory!): Changes! - Add
Directory.withChanges(changes: Changed!) - Add
modules/doug, a Claude-like coding agent
- [ ] Remove
modules/coder? It's just a lighter-weight version of.dagger/main.go- mostly a crutch
Bumps the sdk-java group with 1 update in the /sdk/java directory: org.mockito:mockito-core.
Updates org.mockito:mockito-core from 5.18.0 to 5.19.0
Release notes
Sourced from org.mockito:mockito-core's releases.
v5.19.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.19.0
2025-08-15 - 37 commit(s) by Adrian-Kim, Tim van der Lippe, Tran Ngoc Nhan, dependabot[bot], juyeop
feat: Add support for JDK21 Sequenced Collections. [(#3708)](mockito/mo...
What are you trying to do?
Currently, you can choose whehter to use SSH or HTTPS when using a remote module (dagger call -m git@... or dagger call -m https://...). This is great, but will only help you when using a module that does not depend on other remote modules. When installing module B in module A, the auth method gets baked into module A's dagger.json based on which URL format has been provided at install time.
This means that if and end user of module A is (for whatever ...
Bumps the docs group with 5 updates in the /docs directory:
| Package | From | To |
|---|---|---|
| posthog-js | 1.259.0 |
1.260.2 |
| typedoc | 0.28.10 |
0.28.11 |
| typedoc-plugin-markdown | 4.8.0 |
4.8.1 |
| [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node... |
Updates the requirements on gql[httpx] to permit the latest version.
Updates gql[httpx] to 4.0.0
Release notes
Sourced from gql[httpx]'s releases.
v4.0.0
Breaking Changes
Change transports prototype using GraphQLRequest (#551)
Using GraphQLRequest instead of DocumentNode for gql, execute, subscribe methods (#556):
This is a big change:
the gql and dsl_gql methods will now return a GraphQLRequest instead of a Document Node
a GraphQLRequest is an o...
Bumps the engine group with 21 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.75 |
0.17.78 |
| github.com/alecthomas/chroma/v2 | 2.19.0 |
2.20.0 |
| github.com/anthropics/anthropic-sdk-go | 1.4.0 |
1.9.1 |
| github.com/containerd/containerd | `1.7.2... |
Introduces Changes, a new API representing a diff between two directories - similar to Directory.diff, except it can represent removals as well.
Critical APIs (see .graphqls for docs):
extend type Directory {
changes(older: DirectoryID!): Changes!
withChanges(changes: ChangesID!): Directory!
}
type Changes {
before: Directory!
after: Directory!
changedPaths: [String!]!
addedPaths: [String!]!
removedPaths: [String!]!
}
Better exp...
Splitting these handful of spring cleaning -ish changes out from my other PRs since there isn't really a rightful home for them.
Remove warnings, fix mobile navigation
Fixes issue with latest wolfi busybox
/bin/busybox: /usr/lib/libc.so.6: version `GLIBC_2.42' not found
This is probably a temporary fix and the base image should also been pinned in a way all components are consistent over time.
This type was built while the core git type was kinda bad - but it's significantly better now, so we should be using that instead.
The eventual aim is to remove this custom type entirely, this is a step towards that.
Follow-up to #10852.
We still need the checkout step (annoyingly), but we should be directly invoking the dagger module, for the reasons explained there.
Follow-up to https://github.com/dagger/dagger/pull/10951
Pinning busybox would have prevented the breakage fixed in that PR, so following up w/ that to lessen re-occurrences down the line
Curious to see how jsonv2 performs in our CI since there's purported decoding perf benefits and we do our fair share of json decoding.
What is the issue?
Originally reported in discord: https://discord.com/channels/707636530424053791/1410361079061807306
I have a pipeline that after calling many functions reaches the point below. I find that the first terminal is not the same as the second one through --interactive when integration tests fail:
test_container = (frontend_with_env .with_service_binding('proxy', proxy_service) .with_service_binding('backend', back...
There's currently no easy way to get this without checking out the whole repo using tree.
A few use cases:
- Determining the fully-resolved ref (if an implied URL is provided, like
github.com/dagger/dagger, without the leadinghttps://) - Getting the URL of a remote, as in the case of #10200
Note, this can only be implemented for remote repos, local repos have no externally accessible url, so we should return an error.
Previously, we were always assuming that a git url without a protocol (like github.com/dagger/dagger.io) could always be interpreted as an HTTPS URL.
However, this is a bit weird, we should also consider that it could be interpreted as an SSH URL.
This also means that a private module URL such as github.com/dagger/dagger.io can now be accessed using SSH as well as HTTPS, depending on the available auth available at runtime!
Currently these all just do exactly the same as ref.
However, we should start enforcing this - in a backwards compatible way ofc.
See https://github.com/dagger/dagger/issues/9362.
We've supported this functionality since #7255, but we never added it in our docs (see #7814). I think it's worth including, otherwise there's really no way to know it exists.
It's hacky, but worth including :tada: We can easily our docs once we have a better method.
Fixes the link for the engine.schema.json under reference.
What is the issue?
When mounting a cache volume, dagger seems to default to having the mounting directory owned by root with permissions 0755. This is problematic for containers who do not run as the root user by default because the cache volume will not be able to be written to by the default user.
Since containers are able to define their default user, shouldn't dagger default to ensuring that cache volumes are mounted to directories owned by that default user?
It is already possibl...
Needed to debug some perf regressions in https://github.com/dagger/dagger/pull/10761; while doing so I found a lot of extremely low hanging fruit. Just gonna group them together rather than send out 5+ separate PRs.
Draft because I'm pushing more commits here still. Pushing them one-by-one so I can verify they independently fix individual bottlenecks (i.e. don't make each other redundant) and don't have any dependency on #10761
[dagql: optimize InputSpecs.Inputs](https://github....
Fixing issue (#10915)
- add tests for PrimitiveTypeDefaultArgs
Trying this out separately since the previous PR was getting some strange behavior in CI (occasional fast runs, occasional extremely slow ones) that I want to see in isolation.
The goal here is to avoid running introspection-related queries as often. The reason being that they appear to result in 10k+ calls to dagql.Resolve, which creates a pretty insane amount of overhead. dagql is just much more optimized for queries that involve the core API than it is for introspection-shaped queries...
Closes #10914
The PHP SDK attribute: #[Arg] was deprecated in favour of #[Doc] many minor versions ago.
Ideally this should be merged for 0.19.0 as that minor version going to break backwards compatibility with #10815.
https://github.com/dagger/dagger/pull/10960 should vastly simplify installation of private dependencies.
It's now easier to just skip the explicit https/ssh proto, since it can be automagically determined in more cases. I've updated the docs to make this clearer.
I've also moved the info on private repos directly next to the info on installing other dependencies, instead of living in remote repositories, where I don't really expect it to be.
Bumps the sdk-java group in /sdk/java with 3 updates: io.smallrye:smallrye-graphql-client-api, io.smallrye:smallrye-graphql-client-implementation-vertx and io.vertx:vertx-web-client.
Updates io.smallrye:smallrye-graphql-client-api from 2.14.0 to 2.14.1
Updates io.smallrye:smallrye-graphql-client-implementation-vertx from 2.14.0 to 2.14.1
Updates io.smallrye:smallrye-graphql-client-implementation-vertx from 2.14.0 to 2.14.1
Updates `io.vertx:ve...
Bumps the docs group with 8 updates in the /docs directory:
| Package | From | To |
|---|---|---|
| @mdx-js/mdx | 3.1.0 |
3.1.1 |
| @mdx-js/react | 3.1.0 |
3.1.1 |
| posthog-js | 1.259.0 |
1.261.0 |
| sass | 1.90.0 |
1.91.0 |
| typedoc | `0.... |
Bumps the engine group with 21 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.75 |
0.17.78 |
| github.com/alecthomas/chroma/v2 | 2.19.0 |
2.20.0 |
| github.com/anthropics/anthropic-sdk-go | 1.4.0 |
1.9.1 |
| github.com/containerd/containerd | `1.7.2... |
Add WithUpdatedClients to ModuleSource to
update one or more clients.
Add integration tests.
Additional changes:
- Small fix on client install to clean the path in the generator is a local module
- Cherry-pick of
06126db(#10946) - And also a change to move the
Viewtype intodagql/call, soID.Viewcan directly return a rich type, which avoids the need to convert it later, a fiddly and annoying thing.
Trying this out to see how much breaks immediately. The final change is going to have to deal with lots of back-compat issues and most likely a million corner cases around secrets. For now ignoring those to see how much bubbles up.
Originally the plan was to build this all on top of dagql persistent caching, but given recent conversations it probably makes sense to see if we can fast-path it and then rebase it on top of the new persistent cache once that's ready.
General package updates, and fix for gql v4 (follow-up to https://github.com/dagger/dagger/pull/10888).
Supercedes https://github.com/dagger/dagger/pull/10942
Bumps the sdk-typescript group with 18 updates in the /sdk/typescript directory:
| Package | From | To |
|---|---|---|
| @opentelemetry/exporter-jaeger | 1.30.1 |
2.0.1 |
| @opentelemetry/exporter-trace-otlp-http | 0.202.0 |
0.203.0 |
| @opentelemetry/sdk-node | 0.202.0 |
0.203.0 |
| [@opentelemetry/semantic-conven... |
Removes a module dep and constructor args no longer needed.
Follow up to #10916.
Issue
The Go, Python and Typescript SDKs implicitly return Void, if no type is specified: reference
The PHP SDK demands all Dagger Functions define their return type.
Should It Be Supported?
Referring to the SDK design guidelines:
Aim for the best developer experience,...
Our contributing guide + related docs are out of date.
With more folks trying to work on the engine, I want these to be up-to-date.
docs check is failing - follow-up to https://github.com/dagger/dagger/pull/10969
Hi.
In this PR I add :
sdk.config.phpExtInstallto install additional extension for the module (such as pcntl for example)sdk.config.usePieto enable or notphp/piesdk.config.phpVersionto use a different php version per module- Use the official composer image (official not in the docker registry meaning) which is smaller and built for COPYing the binary.
- fixed an issue with
func(string $var = null)where nullability of$varwas implicit and this is deprecated (...
What is the issue?
When using _EXPERIMENTAL_DAGGER_RUNNER_HOST=docker-container://..., caches are invalidated more compared to the variable not being set.
Example project
Take a directory with this layout:
.
โโโ dagger.json
โโโ somefile
where somefile is empty and the contents of dagger.json are:
{"name": "dagger-foo"}
Dagger invocation
We create a container, add somefile to it and execute a dummy command:
$ dagger <<'EOF'
container | ...
What happened? What did you expect to happen?
Hello - is there a way to run dagger without the daemon and docker images / service? Essentially run it inline on the cli (client runtime)?
What is the issue?
With the new dagger version v0.18.17, we are automatically applying .gitignore when calling host.Directory.
But that means you can't use an ignored file as a argument anymore:
func (e *Example) Example(
ctx context.Context
//+defaultPath=./foo.txt
foo *dagger.File,
...
) (...)
# .gitignore
foo.txt
See for the full context: https://discord.com/channels/707636530424053791/1413511775546118215
We need a way to bypass the .gitignore for spec...
What is the issue?
As I saw in one of the previous releases, Dagger is now by default filtering files from .gitignore.
This erroneously affects files that are already added staged (for ex with git add --force, or added prior to .gitignore modifications), but would have fallen under .gitignore if they wouldn't.
I have a few small .mp4 files checked into the repo for testing purposes. My .gitignore also ignores **/.mp4. My tests in Dagger now started failing after an upgra...
This fixes an error in the ./cmd/engine module, where generate() manually installs pinned go packages with a dependency on protoc, which conflict with the system version of protoc installed in the base image
This is a POC for loading default configuration from .env, and injecting it into the dagger schema.
How it works
- Dagger automatically searches for
.envby findup. - Each time a module is loaded, the
.envis searched for variables that match the module name. For example, a module namedappwill match all variables starting withapp_orAPP_ - Matching variables are matched to corresponding constructor argument names
Example
cat > .env < This will l...
ubntu@localhost:~/Desktop/github-stream$ curl -fsSL https://dl.dagger.io/dagger/install.sh | BIN_DIR=$HOME/.local/bin sh
curl: (6) Could not resolve host: dl.dagger.io
ubntu@localhost:~/Desktop/github-stream$ dagger
Dagger interactive shell. Type ".help" for more information. Press Ctrl+D to exit.
โ base=$(container | from alpine) 0.0s
โถ env=$(env | with-container-input 'base' $base 'a base container' | with-container-output 'nodejs-dev' 'a container with nodejs dev tools') 4.3s
โผ llm | with-env $env | with-prompt "You have an alpine container. Install tools to develop with Node.js." | env | output nodejs-dev | as-container | terminal 0.1s ERROR
โฐ๐ง Y...
What is the issue?
Walking through the documentation here, there is no reference to the Apple container.
The reference alongside instructions is located here.
Even if the Apple container option is in the experimental phase, I would include the "How it works" in the Getting Started Installation Guide.
I am more than happy to work on the issue and ...
Bumps the sdk-java group with 5 updates in the /sdk/java directory:
| Package | From | To |
|---|---|---|
| io.smallrye:smallrye-graphql-client-api | 2.14.0 |
2.14.1 |
| io.smallrye:smallrye-graphql-client-implementation-vertx | 2.14.0 |
2.14.1 |
| io.vertx:vertx-web-client | 4.5.18 |
4.5.21 |
| org.codehaus.mojo:versions-maven-plugin | 2.18.0 |
2.19.0 |
| [com.google.testing.compile:compile... |
[dagger/dagger] Pull request opened: #11005 chore(deps): bump the docs group in /docs with 3 updates
Bumps the docs group in /docs with 3 updates: posthog-js, sass and @types/node.
Updates posthog-js from 1.261.0 to 1.261.7
Release notes
Sourced from posthog-js's releases.
posthog-js@1.261.7
1.261.7
Patch Changes
#2284 bdfe450 Thanks @โpauldambra! - fix: order of operations when replay does pageview fallback
posthog-js@1.261.6
1.261.6...
Bumps the sdk-typescript group with 20 updates in the /sdk/typescript directory:
| Package | From | To |
|---|---|---|
| @opentelemetry/core | 2.0.1 |
2.1.0 |
| @opentelemetry/exporter-jaeger | 1.30.1 |
2.1.0 |
| @opentelemetry/exporter-trace-otlp-http | 0.202.0 |
0.204.0 |
| [@opentelemetry/sdk-metrics](https://gi... |
Bumps the engine group with 19 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.75 |
0.17.78 |
| github.com/alecthomas/chroma/v2 | 2.19.0 |
2.20.0 |
| github.com/anthropics/anthropic-sdk-go | 1.4.0 |
1.11.0 |
| github.com/charmbracelet/bubbletea | `... |
Bumps the sdk-python-docker group with 1 update in the /modules/ruff/build directory: astral-sh/ruff.
Bumps the sdk-python-docker group with 1 update in the /sdk/python/runtime directory: astral-sh/uv.
Updates astral-sh/ruff from 0.12.11 to 0.12.12
Release notes
Sourced from astral-sh/ruff's releases.
0.12.12
Release Notes
Preview features
Show fixes by default (#19919)
[airflow] Convert DatasetOrTimeSchedule(datase...
In
generated/Directory::search()method.$patternis a required parameter but it is declared after two optional ones$pathsand$globswhich is an issue.
_Originally posted by @Neirda24 in https://github.com/dagger/dagger/issues/10991#issuecomment-3258901958_
Since PHP 8.1: Declaring required parameters after optional ones has been deprecated. ...
As discussed with @jedevc, this PR ensure that module with version < v0.18.18 are not automatically loading .gitignore
so that we don't break compatibility.
I'm waiting for a clear response on #1413511775546118215 message before applying any fixes on disabling gitignore for specific arguments
PR #10999 seems to have left an unnecessary comment, just nit but it's a 1 min change on my end
cc @TomChv
A quickstart guide where the user will
- create hello-dagger from the template repo
- install https://github.com/kpenfound/blueprints/tree/main/hello-dagger as a blueprint using
dagger init --blueprint=github.com/kpenfound/blueprints/hello-dagger - run
dagger functions - run
dagger call test
What is the issue?
Mounting a service into another container before returning it, creates 2 instances of the service in the engine, and the exposed tunnel moves intermittently between instances of the same service.
For more context:
https://discord.com/channels/707636530424053791/1414607480117530656
Dagger version
between 0.18.2 and 0.18.9
Steps to reproduce
func (m *Tests) ServiceTest(ctx context.Context) (*dagger.Service, error) {
// Define a database ser...
This is a placeholder draft issue. Please provide additional information so we can fill out the issue with relevant details.
From @marcosnils in [discord](#maintainers message):
is it me or this description in not true? https://github.com/dagger/dagger/blob/c99b557537d68b9fc662a4533f4adb7696907a43/dagql/types.go?plain=1#L212
since multiple functions in that dagql Int type like this one https://github.com/dagger/dagger/blob/c99b557537d68b9fc662a4533f4adb7696907a43/dagql/types.go?plain=1#L217-L226 are also effectively handing the case for int64...
Blueprint modules in typescript were failing to load during introspection because it was looking for the wrong main object name between the main module and blueprint module.
I added tests to confirm the fix and also confirm that its not broken in python.
The main fix is here:
- sdk/typescript/src/module/introspector/dagger_module/module.ts
- sdk/typescript/src/module/introspector/typescript_module/ast.ts
One possible implication of this change is a case where I have one normal type...
Bumps the sdk-python-docker group with 1 update in the /modules/ruff/build directory: astral-sh/ruff.
Bumps the sdk-python-docker group with 2 updates in the /sdk/python/runtime directory: python and astral-sh/uv.
Updates astral-sh/ruff from 0.12.11 to 0.12.12
Release notes
Sourced from astral-sh/ruff's releases.
0.12.12
Release Notes
Preview features
Show fixes by default (#19919)
[airflow] Convert DatasetOrTimeSch...
Bumps the engine group with 18 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.75 |
0.17.78 |
| github.com/alecthomas/chroma/v2 | 2.19.0 |
2.20.0 |
| github.com/anthropics/anthropic-sdk-go | 1.4.0 |
1.11.0 |
| github.com/charmbracelet/bubbletea | `... |
this enables users that need to access the metrics server for example to
be able to expose ports to scrape them
Signed-off-by: Marcos Lilljedahl
Roughly this PR would address most of the items in https://github.com/jsoref/dagger/actions/runs/17617300634/attempts/1#summary-50053683369 (resulting in https://github.com/jsoref/dagger/actions/runs/17617302128/attempts/1#summary-50053688729)
I'm marking this as a draft because I fully expect a lot of pushback and I couldn't get CI to work in my fork. I'm doing this in spare time (I've signed into Discord so feel free to tag me there, but do note that I don't regularly use discord, so...
Update the evals workflow to run on PR events with path filtering instead of push events with path filtering.
Push events with path filtering was causing this workflow to get executed when tags are pushed and on dependabot PRs.
For the tags, it was running because path filters are not evaluated for pushes of tags.
For dependabot, I'm not actually ...
What is the issue?
Version 0.18.17 introduced the NoGitAutoIgnore argument, which is even highlighted in the releases as a breaking feature. Which with the rust sdk specifically means code no longer compiles without changes, which is not a good thing considering unless locked to a specific version cargo will happily update to newer patch versions.
Honestly I get that the change isnt too breaking for most of the sdks, due to optional arguments etc, but for rust which doesnt have tha...
Azure devops repositories allow creating organizations, projects and repositories with spaces in it's names.
This results in git repository URLs to possibly look like this:
https://dev.azure.com/My%20Organization/My%20Project/_git/My%20Repo
or with ssh:
ssh://git@dev.azure.com/v3/My%20Org/My%20Project/My%20Repo
When creating remote dagger modules on such a repository, these modules cannot be installed or used, as dagger only allows alphanumerical + "_.-". when validating the URL.
...
Bumps the engine group with 19 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.75 |
0.17.78 |
| github.com/alecthomas/chroma/v2 | 2.19.0 |
2.20.0 |
| github.com/anthropics/anthropic-sdk-go | 1.4.0 |
1.12.0 |
| github.com/charmbracelet/bubbletea | `... |
What is the issue?
Environment
โข GKE cluster
โข Self-hosted GitLab Runners
โข Dagger Engine v0.18.15 deployed as DaemonSet on runner nodes
Problem
Weโve recently started seeing random pipeline failures with the error:
When the error occurs, engine logs show thread exhaustion:
2025-09-11T04:50:39.601124906Z stderr F time="2025-09-11T04:50:39Z" level=debug msg="session manager handle conn done r57ml1rrvxd4uiob4pczjbkfx" client_hostname=dagger client_id=r57ml1rrvxd4uiob4pczjbkf...
Adds a subtle indicator in the keymap section of the TUI for when a cloud engine is being used. For the other progress methods we will have a new span that will say "connecting to remote engine" and is a part of #10790 since an indicator that sticks doesn't really make sense in that context. Here is what it looks like:
Prior attempts here:
TODO:
- [ ] Somehow this is actually slower, despite doing less work :thinking:
We were setting it to a filepath that's not persistent or fetchable.
This is a combined cleanup + improvement of the git backends.
To avoid a bunch of problems downstream, we eagerly evaluate git ls-remote on the target as soon as we get it - instead of when we resolve a ref.
This allows us to:
- Avoid extraneous calls to
ls-remote- we make one giant call, and then have all the tags, branches, etc. - This means we hugely reduce the amount of chit-chat with the server.
- We can use these calls to carefully only set tags/branches we know about:
...
Now we download our LICENSE file and check that it contains "copyright". That is unlikely to change in the future.
Signed-off-by: Solomon Hykes
Load default module configuration from .env, to avoid typing too many CLI arguments on every call.
How it works
- To persist default configuration for your dagger modules (typically secrets), write them as variables in
.env - The name of the variable must be
_. For example,ACME_TOKENwill set a default to the argumenttokenof the moduleacme. - The value may be a scalar value, or an object addresses to referenc...
reference:
https://github.com/dagger/dagger/pull/11026
Should've also included allowing spaces directly, as it seems part of parsing url-decodes when %20 is being used with dagger cli.
What is the issue?
๐จ Dagger SDK Compatibility Issue with Go 1.24+ and 1.25.1
We've identified a critical compatibility issue when using Dagger SDK with Go 1.24+ and Go 1.25.1.
โ Problem
Build fails with telemetry-related errors:
# dagger.io/dagger/telemetry
../../../go/pkg/mod/dagger.io/dagger@v0.18.17/telemetry/transform.go:69:29: cannot use res (variable of type *resource.Resource) as resource.Resource value in argument to ResourceToPB
๐งช Testing Results
| Go V...
this commit fixes the issue where running dagger call svc up only runs
the service once even if used by different clients.
Fixes #11014
Signed-off-by: Marcos Lilljedahl
Bumps the sdk-java group with 6 updates in the /sdk/java directory:
| Package | From | To |
|---|---|---|
| io.smallrye:smallrye-graphql-client-api | 2.14.0 |
2.14.1 |
| io.smallrye:smallrye-graphql-client-implementation-vertx | 2.14.0 |
2.14.1 |
| io.vertx:vertx-web-client | 4.5.18 |
4.5.21 |
| org.codehaus.mojo:versions-maven-plugin | 2.18.0 |
2.19.0 |
| [com.spotify.fmt:fmt-maven-plugin](... |
Bumps the sdk-typescript group in /sdk/typescript with 6 updates:
| Package | From | To |
|---|---|---|
| @opentelemetry/exporter-trace-otlp-http | 0.204.0 |
0.205.0 |
| @opentelemetry/sdk-node | 0.204.0 |
0.205.0 |
| @types/node | 24.3.1 |
24.4.0 |
| [@typescript-eslint/eslint-plugin](https://... |
Bumps the sdk-python-docker group with 1 update in the /modules/ruff/build directory: astral-sh/ruff.
Bumps the sdk-python-docker group with 2 updates in the /sdk/python/runtime directory: python and astral-sh/uv.
Updates astral-sh/ruff from 0.12.12 to 0.13.0
Release notes
Sourced from astral-sh/ruff's releases.
0.13.0
Release Notes
Check out the blog post for a migration guide and overview of the changes!
Breaking c...
[dagger/dagger] Pull request opened: #11045 chore(deps): bump the docs group in /docs with 3 updates
Bumps the docs group in /docs with 3 updates: posthog-js, typedoc and @types/node.
Updates posthog-js from 1.262.0 to 1.266.0
Release notes
Sourced from posthog-js's releases.
posthog-js@1.266.0
1.266.0
Minor Changes
#2321 b81e152 Thanks @โpauldambra! - feat: expose rrweb custom events on the public interface of the recorder. not in...
Bumps the engine group with 19 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.75 |
0.17.79 |
| github.com/alecthomas/chroma/v2 | 2.19.0 |
2.20.0 |
| github.com/anthropics/anthropic-sdk-go | 1.4.0 |
1.12.0 |
| github.com/charmbracelet/bubbletea | `... |
Bumps the sdk-typescript group with 7 updates in the /sdk/typescript directory:
| Package | From | To |
|---|---|---|
| @opentelemetry/exporter-trace-otlp-http | 0.204.0 |
0.205.0 |
| @opentelemetry/sdk-node | 0.204.0 |
0.205.0 |
| @types/node | 24.3.1 |
24.4.0 |
| [@typescript-eslint/eslint-pl... |
I did allow this at some point, but during development of #10847, I guess I removed it :cry:
Fixes https://github.com/dagger/dagger/issues/10348.
This brings it inline with other similar functions. source is a much better name anyways, just naming it directory is strange, that information is already present via the type-info.
Replace https://github.com/dagger/dagger/pull/11046.
This PR updates engine dependencies and resolves dependency breaking changes such as https://github.com/dagger/dagger/pull/10659#issuecomment-3018788339
TODO
- [ ] Updated all non-AI dependencies in
go.modandsdk/go/go.mod - [ ] Update gqlgen
- [ ] Update AI dependencies
- [ ] Update remaining deps (if it works)
#10867 added support for interactively debugging Directorys, Containers and Services.
However, one important thing is still missing: I can't debug an ExecErr.
For example:
I can't interactively debug the failed withExec - because it simply attempts to replay the ID, which fails.
Realistically, in this case, we should be able to replay the ExecErr, and enter that debug state - all without needing to pass -i at the top-level.
Doing this is a bit tricky - it means we'll need...
See the following command:
$ dagger core -E container from --address=alpine with-mounted-directory --path=/src --source=. with-exec --args ls,-lh,src stdout
(this is the issue I observed during a live demo last week lol)
We need to make sure to preserve the IDs that we actually observe!
Since last week (approximately), github.com/dagger/dagger/modules/wolfi | container takes a long time in the context of our CI: at least 1mn.
To reproduce, run any function in our CI that requires building a wolfi base image. For example:
dagger -m github.com/dagger/dagger/cmd/dagger | cli
Specifically the custom span GetPackageWithDependencies is where all the time goes. Note: this custom span is not in our source code, it's in the underlying wolfi tool.
Attempting a fix for https://github.com/dagger/dagger/issues/11055, local runs are promising in terms of reducing GetPackagesWithDependencies down to 0.0s (i.e. too fast to register), but will do some re-runs in CI to check further.
We were on a pretty old version. We were getting what appeared to be slow/cpu-intensive apk solver steps (GetPackagesWithDependencies), which smelled an awful lot like an inefficient algorithm that might have been made noticeable by recent changes to our pinn...
It doesn't make sense to use gitAutoIgnore when an exact file path is being requested to be loaded. It also broke the
./hack/with-dev go test ... workflow since the bin/ dir in the repo is .gitignored, meaning the dev dagger bin couldn't be loaded.
What am I doing wrong here? It seems locally to be passing, but clearly should not be.
Chaining WithDirectory(dst, ...) calls with the same destination, will keep files from the first directory (assuming the same file paths don't also exist in the second chained call).
What is the issue?
Calling .terminal() in python just explains that it's not available outside the TUI. The would be really useful to have through all SDK versions
Dagger version
sdk-python-v0.18.18
Steps to reproduce
No response
Log output
No response
[dagger/dagger] Issue opened: #11069 ๐ CA Certificates broken when mounted from Kubernetes Secret
What is the issue?
If you run Dagger in Kubernetes using the helm chart, and you configure custom CA certificates to be mounted from a Kubernetes Secret into the /usr/local/share/ca-certificates directory in the Dagger Engine Pod using a direct mount without using subPath, then the files in that directory will be symlinks because of how Kubernetes [mounts secrets](https://github.com/kubernetes/kubernetes/blob/5835544ca568b757a8ecae5c153f317e5736700e/pkg/volume/util/atomic_writer.go#L...
Previously on this journey, we disabled deduping of concurrent dagql calls and the related "edge-merging" feature of buildkit. Motivation being that we did not have any handling of a number of corner cases like a client canceling their request that got deduped with other clients.
We are still leaving buildkit edge merging off forever, but this change reintroduces de-duping to the dagql cache with the new twist that it only occurs within calls that belong to the same session.
Now if a si...
Fixes https://github.com/dagger/dagger/issues/10818
This allows module creators to deprecate fields, args, enum values, functions and types (module types). The codegen and the engine will catch-up with those.
TODO:
- [x] Engine binding(s)
- [x] Go SDK
- [x]ย Integration test suite
- [ ] Typescript SDK (in progress)
- [ ] Python SDK
Last week, I made a little experimentation to improve module loading performances by compiling a module into a docker image or an OCI tarball so we can increase performances on cold call (1st run has no cache).
My compiler is on that repo: https://github.com/TomChv/dagger-module-compiler
There are 2 parts:
- The compilation (either by creating a OCI tarball or publishing an image to a registry)
- The SDK wrapper that pull the module from that image or load it from the OCI tarball, thi...
:face_exhaling: sigh.
We were never testing this behavior, but as of https://github.com/dagger/dagger/pull/11030, I wanted to start relying on it.
We technically had subtly different behavior for checking out refs and checking out SHAs directly; the former included tags in the history, the latter didn't.
[!WARNING]
This is not quite mergeable, it's got pretty wild consistency issues.
Hi
here the suggestion to implement Telemetry to Java SDK
let me know if we should review something.
I would test it directly with dagger cloud, is possible during execution of github actions?
Thanks in advance
This imports the rest of our buildkit package dependencies to be in tree, replacing our current fork at https://github.com/dagger/buildkit
Main motivation is that I'm hitting a lot of situations where I want to tweak something in the code, either for debugging or actual functionality, which is made much more tedious by having the separate repo. I know @marcosnils was asking about this too.
Should also make it a bit easier to convert things over to dagger native code as we continue down ...
Since https://github.com/dagger/dagger/pull/10632 and following our recent docs changes, the preferred way to use enums in Typescript is through the native enum type.
However, the legacy @enumType was never marked as deprecated.
This removes all occurences to the previous pattern and introduces a legacyEnym test for retrocompatibility
Bumps the sdk-python-docker group with 1 update in the /sdk/python/runtime directory: astral-sh/uv.
Updates astral-sh/uv from 0.8.17 to 0.8.18
Release notes
Sourced from astral-sh/uv's releases.
0.8.18
Release Notes
Released on 2025-09-17.
Enhancements
Add PyG packages to torch backend (#15911)
Add handling for unnamed conda environments in base environment detection (#15681)
Allow selection of debug build interpreters (#11520)
Improve uv init defaults...
Bumps the sdk-typescript group in /sdk/typescript with 5 updates:
| Package | From | To |
|---|---|---|
| @grpc/grpc-js | 1.13.4 |
1.14.0 |
| @types/node | 24.4.0 |
24.5.1 |
| @typescript-eslint/eslint-plugin | 8.43.0 |
8.44.0 |
| [@typescript-eslint/parser](https://github.c... |
Bumps the docs group in /docs with 1 update: @types/node.
Updates @types/node from 24.4.0 to 24.5.1
Commits
See full diff in compare view
[](https://docs.github.com/en/github/managing-security-vulnerabilities/ab...
Bumps the engine group with 20 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.79 |
0.17.80 |
| github.com/Azure/azure-sdk-for-go/sdk/azidentity | 1.7.0 |
1.12.0 |
| github.com/Azure/azure-sdk-for-go/sdk/storage/azblob | 0.4.1 |
1.6.2 |
| [github.com/Microsoft/hcsshim](https://github.com/Micro... |
I saw in our engine logs that edge merging was still happening in a few places, due to the fact that we aren't providing the SkipEdgeMerge option everywhere.
Rather than whack-a-mole, this change just removes that code from the buildkit solver (which is now in-tree).
Hi
here the suggestion to implement Telemetry to Java SDK
let me know if we should review something.
I would test it directly with dagger cloud, is possible during execution of github actions?
Thanks in advance
What is the issue?
Files are added to a different path since v0.18.18 when using WithFiles, and behave differently compared to WithFile.
WithFiles will use the absolute path of the File in its original directory when copying it to the new location.
e.g.
I have a container with the following file /go/bin/example
I retrieve the file example and put it in /usr/local/bin of another container. This results in the following file:
- v0.18.18:
/usr/local/bin/go/bin/example
...
This replaces https://github.com/dagger/dagger/pull/11042 as bumping com.google.testing.compile:compile-testing requires more configuration in order to work correctly.
On Wednesday, 17th of September, we organised a meeting to deep dive on SDKs and focused on the SDK interface, how the engine interact with it and what could be improved there to speed up SDK loading process.
This discussion aims to continue our reflexion and define a plan for the future.
For a reminder of the current state, uncollapse this part:
The SDK interface is a composition of 3 other interface: Runtime, CodeGenerator and ClientGenerator.
The Runtime is responsi...
A lot of changes are proposed on https://github.com/dagger/dagger/discussions/11072 and the main motivation is to improve both performances and maintainability.
However we do not have a clear and simple way to test/compare SDK performances and that feels necessary as we work on the SDK interface.
Here's how I benchmark SDK for now, feel free to also share your methods:
Most the of benchmarks I did in my PRs like in https://github.com/dagger/dagger/pull/10846 were done manually:
- I cr...
:warning: currently broken!
- When a module is pinned, we lose track of what the original ref is. This means dependencies that use contextual git will get the wrong ref.
- When calling a module in CI (like here), you can choose between either addressing it via ref (and risk it getting updated in between), or addressing it via sha (and losing the ref info).
Both of these need fixing!
What is the issue?
Several examples in the documentation fail when using the PHP SDK.
See: https://github.com/dagger/dagger/pull/11086#discussion_r2358610881
Code
See: https://github.com/dagger/dagger/pull/11082#discussion_r2357882486
[Code](https://github.com/vikram-dagger/dagger/blob/563d746bcd437b8b1ba0b42c70cb0d0d3dec008...
Occasionally (several times a day), when exiting an interactive TUI session, dagger does not relinquish control back to my system shell: it just hangs there.
- SIGINT (
Ctrl-C) does nothing - SIGQUIT (
Ctrl-\) usually works. It results is a segfault with a massive stack trace
Anecdotically, this seems to happen after "big" interactive sessions, with a big build (dagger -m github.com/dagger/dagger | dev | ... | terminal...
Dagger has native 1password integration. To test it in dev, I need to inject a 1password service account token into the dev container. I do this manually eg. dev | with-secret-variable OP_SERVICE_ACCOUNT TOKEN xxx | ..., but it would be nice to make it an optional argument of dev and other build functions. Especially with upcoming #11034 , then I can add it to my .env and type shorter commands :)
It would be very useful to have core API support for appending to a file.
This primitive allows a client to introspect a module and get a list of local paths which are inputs to the module. In other words, which paths should trigger re-loading of the module if they change.
A perfect implementation would take into account:
- Files to be loaded by the module, based on module directory + include/exclude config + gitignore rules
- Local dependencies (other modules in the repo which are inputs - recursively pulling in their own local inputs)
- Default paths for all...
As discussed, this removes the dev engine from our CI steps and adds one small new step that uses the dev engine to make sure it can load our CI module.
TODO
- [ ] Merge https://github.com/dagger/dagger-for-github/pull/187
- [ ] Tag dagger-for-github v8.2.0
- [ ] Refactor the
dagger callsteps to use dagger-for-github instead of the script
[dagger/dagger] Pull request opened: #11100 remove cancellation from context when stopping a service
this was causing an issue while trying to stop services here https://github.com/dagger/dagger/blob/e669c2a22a319691f82ae2cfbe4d9925ef26e0c0/core/services.go?plain=1#L373-L380 since the parent
context was being cancelled which caused services to never be removed
from the running service list. Since we are stopping the service in a
separate goroutine, we don't need to propagate the cancellation.
Signed-off-by: Marcos Lilljedahl
Bumps the sdk-java group with 8 updates in the /sdk/java directory:
| Package | From | To |
|---|---|---|
| io.smallrye:smallrye-graphql-client-api | 2.14.0 |
2.14.1 |
| io.smallrye:smallrye-graphql-client-implementation-vertx | 2.14.0 |
2.14.1 |
| io.vertx:vertx-web-client | 4.5.18 |
4.5.21 |
| org.assertj:assertj-core | 3.27.4 |
3.27.5 |
| [org.mockito:mockito-core](https://github.com/mockit... |
Bumps the docs group with 4 updates in the /docs directory: posthog-js, sass, typedoc-plugin-markdown and @types/node.
Updates posthog-js from 1.266.0 to 1.266.3
Release notes
Sourced from posthog-js's releases.
posthog-js@1.266.3
1.266.3
...
Bumps the sdk-typescript group in /sdk/typescript with 4 updates: tar, @types/node, eslint and rollup.
Updates tar from 7.4.3 to 7.4.4
Commits
15d4510 7.4.4
a474465 Fix some typos
65ff5be docs(changelog): add missing v7 breaking change
458d0fd docs: clean up duplicate onwarn options
afa8cf5 update all deps...
Bumps the engine group with 21 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.79 |
0.17.80 |
| github.com/Azure/azure-sdk-for-go/sdk/azidentity | 1.7.0 |
1.12.0 |
| github.com/Azure/azure-sdk-for-go/sdk/storage/azblob | 0.4.1 |
1.6.2 |
| [github.com/Microsoft/hcsshim](https://github.com/Micro... |
[dagger/dagger] Pull request opened: #11106 chore: ensure commit checkouts have tag history (take 2)
Follow-up to https://github.com/dagger/dagger/pull/11073.
This logic has to be duplicated for the remote fetching.
This was likely only previously working because dagger/dagger gets cloned in other places, so we already had all those tags. But the logic needs to be in both places.
What is the issue?
Running Diff on two Directory types that point to the same underlying folder throws an error indicating that the directory was not found. Changing the contents of the underlying directory between calls fixes this issue.
Dagger version
dagger v0.18.18 (image://registry.dagger.io/engine:v0.18.18) linux/amd64
Steps to reproduce
Calling dagger call foo entries throws this error:
func (m *Testing) Foo(ctx context.Context) *dagger.Directory {
ctr := ...
This was causing dependent pipelines, like publish, to fail with:
Error: /home/runner/_work/dagger/dagger/./.github/actions/call/action.yml: (Line: 16, Col: 14, Idx: 290) - (Line: 16, Col: 17, Idx: 293): While parsing a quoted scalar, find unknown escape character.
Upgrading to PHP SDK runtime from 8.3 to 8.4
No significant breaking changes unless someone out there is trying to use a PHP Dagger Module as a mail client.
- Evaluate quotes by default:
foo="a b c" - Support default values in variables:
foo=${bar:-baz} - Cleaner implementation, with a low-level go package
- Lots of tests
- Optional "raw" mode
Azure Repos serves the org login page (HTML) when an unauthenticated HTTPS ref lacks the {org}@ information:
curl -i https://dev.azure.com/daggere2e/private/_git/dagger-test-modules.gitreturns HTML as a 200curl -i https://daggere2e@dev.azure.com/daggere2e/private/_git/dagger-test-modules.gitreturns a 401
When authenticating for a private azure module, we inadventendly stop earlier (before the git credential's session attachable logic) because go-gitโs pktline parser raises `...
See https://github.com/dagger/dagger/pull/11073
Essentially, we never really had a consistent behavior here - now everything at least pulls the tag history.
But it's not fully consistent:
doFetchshould be set if we need to rework the tag history- The resulting fetch should still be set to a consistent view of the tag history (from the ls-remote we did earlier)
- Even if tags got updated between resolution and fetch
Opening to track, but don't have time to work on this properly no...
See https://github.com/dagger/dagger/pull/10991#issuecomment-3257828892
This image is maintained by the same maintainer as the official docker image.
The difference is this image is ~75Mb smaller,
it is designed specifically for copying the binary.
See https://github.com/dagger/dagger/issues/10812.
Removes both:
Host.setSecretFileLocalCache.keeyBytes
Because both of these fields are hidden from module SDKs, they fall outside our module compat guarantees - so no views to access these from older clients is provided.
Older clients connecting to dagger will break anyways because of https://github.com/dagger/dagger/pull/11039.
This was recently updated to use an internal package. Which cannot be accessed externally. YAY go.
We can just use the shiny new rand.Text here, it's just for testing caching-y things.
When calling a module in CI (like here), you can choose between either:
-
Addressing it via ref
$ dagger -m github.com/dagger/dagger@mainThis is bad for handling git events because it's unpinned; between receiving the event and dagger processing the event,
mainmight get updated causing CI to run on the wrong commit. -
Addressing it via commit sha
$ dagger -...
What is the issue?
Given the following sample project:
-- main.go --
package main
import (
"context"
"dagger/socket/internal/dagger"
)
type Sockettest struct {
}
func (t *Sockettest) ReproduceSocketError(ctx context.Context, socket *dagger.Socket) error {
repo := dag.Git("git@github.com:dagger/dagger-test-modules.git", dagger.GitOpts{
SSHAuthSocket: socket,
})
root, _ := repo.Branch("main").Tree(dagger.GitRefTreeOpts{
DiscardGitDir: true,
}).Sync(ctx)
_, err := dag.R...
- Would be nice to know why I can't pin this.
I think there's some weird instability I recently introduced (noticed by @eunomie):
Keeping track of the shallow file seems to resolve the problem?
(also a couple of other little fixes that I hit while trying to debug this)
TestPrivateDeps/golang started failing in CI due to Alpine's recent security update in 3.22.1, addressing CVE-2025-4575 (details here: https://alpinelinux.org/posts/Alpine-3.19.8-3.20.7-3.21.4-3.22.1-released.html).
Our module generator containers were still pinned to Alpine 3.22.0 (see engine/distconsts/consts.go:27), causing an OpenSSL mismatch when installing the latest git package. Specifically, when the code generator ran go mod tidy during post-commands (cmd/codegen/generator/go/...
What are you trying to do?
Building images, we get a lot of failures due to 429s from Docker Hub. Running with higher verbosity, it appears like there is a huge amount of simultaneous pull-requests being sent - including for images where we already have the latest version.
Two mitigations come to mind:
- Add CLI-flag to configure pull-behavior (
always=like now,missing=only pull missing images,never=never attempt to pull base images from remote) - Reduce number of simultaneous ...
I opened an issue with some suggestions for improving the situation:
Nesting is now considered stable and safe. Therefore we can enable it by default.
This allows any containerized tool or service executed by Dagger to open a client session to the same Dagger engine,
without accessing parent resources. This is similar to a unix process being able to make system calls, without
accessing the context of its parent process.
- Deprecate
experimentalPrivilegedNestingargument. It can safely be omitted - Keep the plumbing for simplicity. It's simply enabled at th...
Bumps the sdk-java group with 5 updates in the /sdk/java directory:
| Package | From | To |
|---|---|---|
| org.apache.commons:commons-lang3 | 3.18.0 |
3.19.0 |
| org.assertj:assertj-core | 3.27.4 |
3.27.6 |
| org.mockito:mockito-core | 5.19.0 |
5.20.0 |
| org.codehaus.mojo:versions-maven-plugin | 2.19.0 |
2.19.1 |
| [com.spotify.fmt:fmt-maven-plugin](http... |
- llm: fix hiding builtin tool spans
- llm: fix DeclareOutput
- evals: add DeclareOutput coverage
This fixes some deprecations showing up about optional arguments being put before required ones.
BEFORE:
public function search(
?array $paths = null,
?array $globs = null,
string $pattern,
?bool $literal = false,
?bool $multiline = false,
?bool $dotall = false,
?bool $insensitive = false,
?bool $skipIgnored = false,
?bool $skipHidden = false,
?bool $filesOnly = false,
?int $limi...
the current VersionPrinter was printing some old buildkit constants
which are not relevant anymore since we're slowly moving a bunch of
those pats into the Dagger codebase
Signed-off-by: Marcos Lilljedahl
Bumps the docs group in /docs with 12 updates:
| Package | From | To |
|---|---|---|
| @docusaurus/core | 3.8.1 |
3.9.1 |
| @docusaurus/mdx-loader | 3.8.1 |
3.9.1 |
| @docusaurus/plugin-content-docs | 3.8.1 |
3.9.1 |
| [@docusaurus... |
Bumps the engine group with 11 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.80 |
0.17.81 |
| github.com/Azure/azure-sdk-for-go/sdk/azidentity | 1.7.0 |
1.12.0 |
| github.com/Azure/azure-sdk-for-go/sdk/storage/azblob | 0.4.1 |
1.6.2 |
| [github.com/aws/aws-sdk-go-v2](https://github.com/aws/a... |
Bumps the sdk-python-docker group with 1 update in the /modules/ruff/build directory: astral-sh/ruff.
Bumps the sdk-python-docker group with 1 update in the /sdk/python/runtime directory: astral-sh/uv.
Updates astral-sh/ruff from 0.13.0 to 0.13.2
Release notes
Sourced from astral-sh/ruff's releases.
0.13.2
Release Notes
Released on 2025-09-25.
Preview features
[flake8-async] Implement blocking-path-method (ASYNC240)...
Bumps the sdk-typescript group with 8 updates in the /sdk/typescript directory:
| Package | From | To |
|---|---|---|
| tar | 7.4.3 |
7.5.1 |
| @types/node | 24.5.1 |
24.5.2 |
| @typescript-eslint/eslint-plugin | 8.44.0 |
8.44.1 |
| [@typescript-eslint/parser](https://githu... |
This PR includes all v0.19.0 changes that were merged into the v0.19.0 branch instead of main because they were breaking.
All of these PRs have already been approved, but since v0.19.0 is tomorrow, we should bring them into main.
Currently, if a separate client (e.g. dagger CLI when you call .compact) tries to re-evaluate an LLM's env, the withCurrentModule will resolve to a different module, or no module.
Now, the API just calls withModule with the current module's ID, ensuring the resulting Env will have the same behavior wherever it gets loaded.
$description has been deprecated in favour of the Doc attribute, This has been deprecated for a long time and is not used in documented examples.
Updated in https://github.com/dagger/dagger/dagger.io/pull/4611, needs to be updated here so that the bump call doesn't fail!
This allows to build Go apps that use vendoring, using Dagger's Go module. Useful when making local modifications to vendored libraries.
We send the module, function name and command being executed to the API and let it make the decision for how to provision an engine.
Return the underlying module from the current module to allow direct access. This is useful for accessing generated code without incurring a performance hit.
sigh
In #11145 I bumped the version that we test, but not the actual default version that we ship. :upside_down_face:
Bumps the engine group with 11 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.80 |
0.17.81 |
| github.com/Azure/azure-sdk-for-go/sdk/azidentity | 1.7.0 |
1.12.0 |
| github.com/Azure/azure-sdk-for-go/sdk/storage/azblob | 0.4.1 |
1.6.2 |
| [github.com/aws/aws-sdk-go-v2](https://github.com/aws/a... |
When creating a clone of a private repo we do a fun little dance to mixin the content hash of the clone so that we avoid mixing up two repos with the same content, but different URLs. This scenario appears frequently with out module tests (with mirrored versions of the same repo in multiple places).
When we introduced maintainContentHashing in https://github.com/dagger/dagger/pull/10761, the intention was to ensure that a Directory that was previously content-hashed (e.g. on load from ...
This query was causing a hang when calling a tool that had a somewhat significant amount of child spans. Adding a DISTINCT fixes the issue straight away.
Bumps the sdk-python-docker group with 1 update in the /modules/ruff/build directory: astral-sh/ruff.
Bumps the sdk-python-docker group with 2 updates in the /sdk/python/runtime directory: python and astral-sh/uv.
Updates astral-sh/ruff from 0.13.0 to 0.13.2
Release notes
Sourced from astral-sh/ruff's releases.
0.13.2
Release Notes
Released on 2025-09-25.
Preview features
[flake8-async] Implement blocking-path-metho...
cc @vito
Originally reported in https://github.com/dagger/dagger/issues/11095#issuecomment-3353652479.
Reproducer:
โฏ dagger version
dagger v0.19.0 (image://registry.dagger.io/engine:v0.19.0) linux/amd64
โฏ dagger -c 'container | from alpine | with-exec vi /foo'
โถ connect 0.4s
โถ detect module: . 0.1s
โ loading type definitions 0.3s
โ container: Container! 0.0s
$ .from(address: "alpine"): Container! 0.9s CACHED
โ .withExec(args: ["vi", "/foo"]): Container! 0.3s
Caught panic:
runtime ...
Implements https://github.com/dagger/dagger/issues/10895.
[!WARNING]
This is not ready, opening a PR to track work.
Problem
When dagger call calls a function that returns a Changeset, the CLI prompts the user to apply the changes to the local filesystem.
Unfortunately, the changes are applied relative to the CLI's working directory, which is brittle and often surprising.
This means that the same command will fail or succeed (or worse, silently dump data in the wrong place) depending on the workdir.
This is surprising because the rest of dagger call doesn't behave differently based on workdir, ...
- Fix static method calling tools being discarded
- Add eval coverage, by just re-using the BuildMulti eval + assertion by configuring it for static calling (this worked out nicely!)
Helps avoid this scenario:
fixes #11157
repro:
dagger-dev -M -c 'container | from alpine | with-exec vi /foo'
This doesn't actually work since it just runs vi which realizes it has no stdin and exits. But it doesn't panic anymore.
This adds functionality to init a module from a template, or to "eject" from a blueprint.
Today if you use a blueprint, you might eventually run into limitations where you need to write customize your module. There's currently no easy path to go from a blueprint to a custom module, you have to start from scratch or copy code.
To solve this, "ejecting" from a blueprint means you will switch your module to an SDK module that implements the original blueprint as a dependency, allowing you ...
Follow-up PR with improvements to #11034
- env-file: customize env file name
What is the issue?
Both ./foo and ./bar/baz files exist. However, Changes() handle directory deletion in unexpected ways:
func (l *Mod) One(
// +defaultPath="."
source *dagger.Directory,
) *dagger.Changeset {
return source.WithoutDirectory("bar").Changes(source)
}
func (l *Mod) Two(
// +defaultPath="."
source *dagger.Directory,
) *dagger.Changeset {
return source.WithoutFile("foo").Changes(source)
}
func (l *Mod) Three(
// +defaultPath="."
source *dagger.Directory,...
cc @marcosnils
Got this far investigating the weird nil issues.
I think this is due to something wrong in a dagop somewhere. I suspect LLB and Result on a single Directory are somehow ending up nil, but I can't quite work out what that is.
This should help debug the issue though:
- We'll get an error, which should propagate to a specific schema handler, so we're able to reproduce more easily.
- We'll get some more detailed logs.
- Upgraded dependencies
- Moved graphql and code generation from "require-dev" to "require" since they absolutely are required by all users.
- Use
composer install --no-devin the SDK runtime, which should reduce the memory size of the SDK for end-users.
Looks like this was missed during https://github.com/dagger/dagger/pull/11150.
There are still a few versions that need manually bumping and aren't automated.
This was causing publish to fail on main.
this speeds up module loading considerably when you have dirty files
in your working directory
Signed-off-by: Marcos Lilljedahl
What are you trying to do?
In a production environment, you want to pin specific versions, equally so with Dagger.
It's quite annoying to have dagger nag you everytime about a new version being available. It clutters the CI output.
Why is this important to you?
No response
How are you currently working around this?
No response
The Dagger Python SDK contains everything you need to develop CI/CD pipelines in Python, and run them on any OCI-compatible container runtime.
Bumps the sdk-java group in /sdk/java with 5 updates:
| Package | From | To |
|---|---|---|
| io.smallrye:smallrye-graphql-client-api | 2.14.1 |
2.15.0 |
| io.smallrye:smallrye-graphql-client-implementation-vertx | 2.14.1 |
2.15.0 |
| com.github.javaparser:javaparser-core | 3.27.0 |
3.27.1 |
| org.junit:junit-bom | 5.13.4 |
6.0.0 |
| [org.codehaus.mojo:exec-maven-plugin](https:/... |
Bumps the sdk-typescript group in /sdk/typescript with 8 updates:
| Package | From | To |
|---|---|---|
| typescript | 5.9.2 |
5.9.3 |
| @types/node | 24.5.2 |
24.6.2 |
| @typescript-eslint/eslint-plugin | 8.44.1 |
8.45.0 |
| [@typescript-eslint/parser](https://github.... |
Bumps the docs group in /docs with 5 updates:
| Package | From | To |
|---|---|---|
| posthog-js | 1.268.6 |
1.271.0 |
| react | 19.1.1 |
19.2.0 |
| react-dom | 19.1.1 |
19.2.0 |
| typescript | 5.9.2 |
5.9.3 |
| [@types/node](https://github.com/DefinitelyTyped/D... |
Bumps the sdk-python-docker group with 1 update in the /modules/ruff/build directory: astral-sh/ruff.
Bumps the sdk-python-docker group with 2 updates in the /sdk/python/runtime directory: python and astral-sh/uv.
Updates astral-sh/ruff from 0.13.2 to 0.13.3
Release notes
Sourced from astral-sh/ruff's releases.
0.13.3
Release Notes
Released on 2025-10-02.
Preview features
Display diffs for ruff format --check and ad...
Bumps the engine group with 18 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/99designs/gqlgen | 0.17.80 |
0.17.81 |
| github.com/Azure/azure-sdk-for-go/sdk/azidentity | 1.7.0 |
1.12.0 |
| github.com/Azure/azure-sdk-for-go/sdk/storage/azblob | 0.4.1 |
1.6.2 |
| [github.com/aws/aws-sdk-go-v2](https://github.com/aws/a... |
During https://github.com/dagger/dagger/pull/11128, we moved the Kubernetes and OpenShift pages to a new Deployment section, which fits them better. See the justification here: https://github.com/dagger/dagger/pull/11128#discussion_r2379448890.
However, I didn't update the slugs, so the pages were still at the same place.
This patch moves them to the new locations, and updates the redirects.
- Upgrades PHPUnit to the latest release
- Tweaks PHPUnit config to use a .cache/ directory
- The idea is to transition each CI tool's cache to this directory, minimizing boilerplate ignores and excludes elsewhere (i.e. dagger.jsons, Ignore decorators, .gitignores)