#github-feed

1 messages ยท Page 17 of 1

ornate vigilBOT
vivid lintelBOT
vivid lintelBOT
#

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 rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • `@dependabot ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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...
vivid lintelBOT
#

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...
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
ornate vigilBOT
vivid lintelBOT
#

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()....
ornate vigilBOT
#

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...

vivid lintelBOT
#

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 rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • `@dependabot ...
vivid lintelBOT
#

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 rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • `@dependabot ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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:

vivid lintelBOT
#

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...

vivid lintelBOT
ornate vigilBOT
vivid lintelBOT
#

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 GitRepository or Service. We should expose this implied interface as a real int...
#

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...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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

  1. Create a module
  2. Run dagger shell
  3. With the shell open, add a ...
vivid lintelBOT
vivid lintelBOT
#

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...
vivid lintelBOT
#

(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

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...
vivid lintelBOT
#

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.

vivid lintelBOT
#

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.

vivid lintelBOT
vivid lintelBOT
#

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.

vivid lintelBOT
vivid lintelBOT
#

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.

vivid lintelBOT
#

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
vivid lintelBOT
vivid lintelBOT
#

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 ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...
vivid lintelBOT
#

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.

vivid lintelBOT
vivid lintelBOT
#

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 ...

ornate vigilBOT
#

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

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...
vivid lintelBOT
#

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,...

vivid lintelBOT
vivid lintelBOT
#

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. Supports tcp://, ssh://, unix://, container://, kube-pod://. no provisioning, no special URL flags
  • New: DAGGER_ENGINE_IMAGE: if provisioning from an image, override which ima...
ornate vigilBOT
#

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:

  1. Promote the escape hatch to a fully supported feature. This means replacing `_EXPERIMENTAL_DAGGER_RU...
ornate vigilBOT
#

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:

  1. 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.

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...
vivid lintelBOT
vivid lintelBOT
#

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...
vivid lintelBOT
#

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-...

vivid lintelBOT
#

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...
vivid lintelBOT
vivid lintelBOT
#

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 mcp command should not expect clients to support dynamic tools
  • Function calls only return scalars
  • Core types can have an auto-scalar resolution. Such as `F...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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:

  1. Build a dev engine from main
  2. Run dagger functions (o...
vivid lintelBOT
vivid lintelBOT
#

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
    -...
vivid lintelBOT
#

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 ...

vivid lintelBOT
#

[!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%...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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

vivid lintelBOT
#

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...

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...
vivid lintelBOT
#

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.

vivid lintelBOT
#

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...

vivid lintelBOT
#

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...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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.setup to add the extraheader via GIT_CONFIG_* env vars instead of only passing -c args to th...
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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 --depth of a clone, we can't do this for submodules - we always go to ...
vivid lintelBOT
#

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/

vivid lintelBOT
#

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...

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

Sparked by a bug reported by @jasonmccallister.

  1. Essentially, not every SDK supports generating/displaying sourcemaps, so these fields must be nullable.
  2. 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!
vivid lintelBOT
#

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:

vivid lintelBOT
#

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:

  • Env now has a filesystem, which automatically propagates between tool calls and gets re-hydrated as contextual args to modules
  • LLM now supports MCP servers (in other words, LLM is an MCP client), which also run with the same filesystem, and even propagate changes out to subsequent tool calls
    *...
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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;
}
vivid lintelBOT
#

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...

vivid lintelBOT
#

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....

vivid lintelBOT
#

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...

vivid lintelBOT
#

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...
vivid lintelBOT
#

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...

vivid lintelBOT
#

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 ...

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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.

vivid lintelBOT
#
  • [ ] Bikeshed API changes

Changes

  • Env now has a filesystem, which automatically propagates between tool calls and gets re-hydrated as contextual args to modules
  • LLM now supports MCP servers (in other words, LLM is an MCP client), which also run with the same filesystem, and even propagate changes out to subsequent tool calls
  • LLM now captures and displays logs in each tool call response (supersedes #10768)
  • LLM now exposes its tools in "dynamic mode" by default,...
vivid lintelBOT
#

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...

vivid lintelBOT
#

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...

vivid lintelBOT
#

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 ...
vivid lintelBOT
#

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!

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
ornate vigilBOT
#

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...

vivid lintelBOT
#

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:

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
ornate vigilBOT
#

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...

ornate vigilBOT
#

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.
  • 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).

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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 ...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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 leading https://)
  • 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!

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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....

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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.

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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.

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Hi.

In this PR I add :

  • sdk.config.phpExtInstall to install additional extension for the module (such as pcntl for example)
  • sdk.config.usePie to enable or not php/pie
  • sdk.config.phpVersion to 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 $var was implicit and this is deprecated (...
vivid lintelBOT
#

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 | ...
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

This is a POC for loading default configuration from .env, and injecting it into the dagger schema.

How it works

  • Dagger automatically searches for .env by findup.
  • Each time a module is loaded, the .env is searched for variables that match the module name. For example, a module named app will match all variables starting with app_ or APP_
  • Matching variables are matched to corresponding constructor argument names

Example

cat > .env < This will l...
vivid lintelBOT
#
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...
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

In generated/Directory::search() method. $pattern is a required parameter but it is declared after two optional ones $paths and $globs which is an issue.

_Originally posted by @Neirda24 in https://github.com/dagger/dagger/issues/10991#issuecomment-3258901958_

https://github.com/dagger/dagger/blob/b9a64f6bf2dff6e9c851b9b5a73d569c163f8fa2/sdk/CONTRIBUTING.md?plain=1#L61-L64

Since PHP 8.1: Declaring required parameters after optional ones has been deprecated. ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...
vivid lintelBOT
#

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...

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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.
...

vivid lintelBOT
#

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...
vivid lintelBOT
vivid lintelBOT
#

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:
    ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
#

#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...

vivid lintelBOT
#

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.

vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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...

ornate vigilBOT
#

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...
vivid lintelBOT
vivid lintelBOT
#

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 ...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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
    ...
vivid lintelBOT
ornate vigilBOT
#

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...

ornate vigilBOT
#

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...
vivid lintelBOT
#

:warning: currently broken!

  1. 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.
  2. 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!

vivid lintelBOT
#

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 :)

#

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:

  1. Files to be loaded by the module, based on module directory + include/exclude config + gitignore rules
  2. Local dependencies (other modules in the repo which are inputs - recursively pulling in their own local inputs)
  3. Default paths for all...
vivid lintelBOT
vivid lintelBOT
#

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

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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 := ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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.git returns HTML as a 200
  • curl -i https://daggere2e@dev.azure.com/daggere2e/private/_git/dagger-test-modules.git returns 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 `...

vivid lintelBOT
#

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:

  • doFetch should 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...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

When calling a module in CI (like here), you can choose between either:

  • Addressing it via ref

    $ dagger -m github.com/dagger/dagger@main
    

    This is bad for handling git events because it's unpinned; between receiving the event and dagger processing the event, main might get updated causing CI to run on the wrong commit.

  • Addressing it via commit sha

    $ dagger -...
vivid lintelBOT
#

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...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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/...

vivid lintelBOT
#

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:

  1. Add CLI-flag to configure pull-behavior (always=like now, missing=only pull missing images, never=never attempt to pull base images from remote)
  2. Reduce number of simultaneous ...
ornate vigilBOT
vivid lintelBOT
#

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 experimentalPrivilegedNesting argument. It can safely be omitted
  • Keep the plumbing for simplicity. It's simply enabled at th...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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)...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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 ...

vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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 ...
vivid lintelBOT
#

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, ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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 ...

vivid lintelBOT
vivid lintelBOT
#

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.
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

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...

vivid lintelBOT
#

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.

vivid lintelBOT