#github-feed

1 messages · Page 11 of 1

vivid lintelBOT
#

Part of #7640 and co.

With changes to how we do version compatibility checks, we no longer need this check in the engine. Thankfully - we can just remove it: all of the SDKs were treating this as a warning level, and not causing a fatal error - this means that if the method is removed, it should not cause a build to fail.

The Go SDK also removes the WithoutVersionCompatibilityCheck - since now this option is always the case.

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Hit this while doing the v0.11.9 release, which was the first one we've done on a non-main branch.

Workflows ran fine in PRs and on tag pushes, but there are steps in RELEASING.md that say to wait for workflows on "main" to be green, which doesn't work now because we only run workflows on the main branch + PRs + tag pushes.

This wasn't the end of the world in the previous release, but there are a few workflows that run there which...

#

When doing a release off a non-main branch, the autogenerated bump-engine PR is only created against main and includes commits from main, which results in the need to manually create a separate PR that is against the release branch. e.g.

vivid lintelBOT
vivid lintelBOT
#

As discussed in https://github.com/dagger/dagger/issues/7640.

The essential idea here is to use the engineVersion defined in dagger.json to determine any backwards compatible schemas to serve. This will allow us to make breaking changes in a more controlled manner.

Without this, any breaking changes we make to the API will be applied everywhere - this will potentially break parts of the daggerverse, introduces module dependencies on specific dagger versions, and will prevent users f...

#

Currently, all releases are tagged using semantic versioning - e.g. v0.11.9, the latest release. This tag is builtin to the resulting CLI and Engine binaries, and is used (among other things) for determining version compatibility (see https://github.com/dagger/dagger/issues/7640 for more information).

However, all builds cut from main are instead built using a commit SHA version, and all builds made in a local dev environment are built using a dev- version.

This is workable, but i...

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

When using a local directory which has an @ in the path name (e.g /Users/cbochs@company.com) as the source for a dagger module, dagger seems to assume it has special meaning and fails to resolve the module. This appears to be the case with dagger init as well:

dagger init --name=test --sdk=go test@test

Results in

✔ connect 1.1s
  ✔ starting engine 1.0s
    ✔ create 1.0s
✔ moduleSource(refString: "test@test"): ModuleSource! 0.0s
✔ Modul...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Immediate motivation here is to add integ tests for the bug where local cache wasn't getting pruned.

Secondary motivations:


TODOs:

vivid lintelBOT
#

What is the issue?

It's great to know that Dagger has shell completion. However, when running Dagger inside GitHub Actions or other CI environments, it generates additional logs without providing any benefit. It would be helpful to have an option to disable this output or automatically disable it when no TTY is available.

Dagger version

dagger v0.11.8

Steps to reproduce

No response

Log output

No response

vivid lintelBOT
#

Fix https://github.com/dagger/dagger/pull/7750.

See run in https://github.com/dagger/dagger/actions/runs/9697150564/job/26760624393?pr=7744.

This wasn't caught in my example runs, since I was running a PR inside a single fork.

The issues fixed here:

  • Added permissions to this workflow to mirror other workflows - we need to be able to write to the pull request to be able to add a comment
  • Modified GITHUB_HEAD_REF to GITHUB_REF to get the current state of the PR as resolved by ...
vivid lintelBOT
#

What is the issue?

Using podman, I am running a custom engine version v0.11.9 with an internal ca cert mounted in /usr/local/share/ca-certificates/.

I can successfully initialize modules for both Go and TypeScript SDKs but am facing an error when initializing a module with the Python SDK with dagger init --sdk python.

Codegen is failing at the installation of uv via pip:

Collecting uv==0.2.11 (from -r /reqs.txt (line 1))
Stderr:
...'SSLError(SSLCertVerification...
vivid lintelBOT
#

This commit updates the Jenkins instructions to work with Dagger Cloud. It fixes the issues reported in #7763

  • refactor Jenkinsfile to not require a go project for it to work, this uses a simpler example so that people can get this working right away without needing to make any changes.
  • add instructions to show how to properly checkout git branches for workign with Dagger Cloud on different types of Jenkins projects
  • add new snippet showing "the long way" to get this to work by addin...
vivid lintelBOT
#

What are you trying to do?

Today, in the Dagger API, KeepGitDir is set to false by default.
If KeepGitDir is true, the .git directory is preserved when a git repo is used as a Dagger Directory. If it's false, then the .git directory is omitted.

It seems that when a git repo ref is provided as an argument of type Directory in the dagger CLI, then KeepGitDir is set to true, which is different than when used via the API, where it is false by default.

da...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

We want this so that we can reference registry.dagger.io/engine:main in our CI, and have our runners pick up the latest Engine Image (a.k.a. dev). I didn't want to call this tag dev since:

  • it assumes there is a single dev branch (unlikely to be true for long based on the latest releasing discussions)
  • it requires us to make an extra mental jump from dev to main to understand it's true origin
  • it required me to change existing code (we are already using the dev concept when building...
vivid lintelBOT
#

This change is meant to inform us of the following:

  • How does the CI behave after a few days and at least 5 runs using this new image?
  • What changes are required to make this work?
  • What are the unknowns?

Some of the obstacles that we encountered so far:

  1. If we pin the Wolfi image using a SHA256, what guarantees do we have that this will remain available?
  2. How do we consume a specific version of Go which is based on the Wolfi base image? The only option that I could find ...
vivid lintelBOT
#

What is the issue?

Since https://github.com/dagger/dagger/pull/6843 importing dagger/dagger as a library in a go module fails due to distconsts being its own standalone module.

The gist of what happens is:

  1. You import github.com/dagger/dagger to use dagger specific components, such as engine/cache
  2. github.com/dagger/dagger then imports github.com/dagger/dagger/engine/distconsts, however, since its within the same top level module in the context of the import Go tries...
#

What is the issue?

I can generate a new go module using

dagger init --sdk=go

But when I try to use the python or typescript SDK I get similar errors.

Dagger version

dagger v0.11.9 (registry.dagger.io/engine) linux/amd64

Steps to reproduce

dagger init --sdk=python

or

dagger init --sdk=typescript

Log output

Typescript

levlaz@framework:/tmp/ts$ dagger init --sdk=typescript
Full trace at https://dagger.cloud/levs-test-org/traces/191b1333b58c...

vivid lintelBOT
#

Most recent example here: https://github.com/dagger/dagger/actions/runs/9717679155/job/26824096680#step:6:9

Dev engine fails to start when trying to run some sed command in the entrypoint script that sets up nested cgroup support:

sed: write error
#!/bin/sh
set -e

cat $0

# cgroup v2: enable nesting
# see https://github.com/moby/moby/blob/38805f20f9bcc5e87869d6c79d432b166e1c88b4/hack/dind#L28
if [ -f /sys/fs/cgroup/cgroup.controllers ]; then
	# move the processes from the...
vivid lintelBOT
#

I am not entirely sure what's precisely going on here yet, so just going to list the details I've gathered so far. The end effect is that we seem to be getting multi-minute hangs in GHA when printing certain output. The tests still pass thankfully but it appears to possibly be increasing CI test job time a lot.


One example:

  1. Cloud traces: https://dagger.cloud/dagger/traces/dda1b716e38a06eee8f434b500b6c16e#87f6ab6bc7234db9
  2. GHA job): https://github.com/dagger/dagger/actions/run...
vivid lintelBOT
vivid lintelBOT
#

A tangential issue I noticed during some adventures with https://github.com/dagger/dagger/pull/7767

At least in the Go SDK, the generated Sync method will just return the query it has built so far, e.g. https://github.com/dagger/dagger/blob/adca4e6cb4cd28090bfe5a87c497c93561c9161f/sdk/go/dagger.gen.go#L2102-L2106

However, this does not play nicely with our core APIs that rely on returning a dagql.Instance of a different API call, e.g. https://github.com/dagger/dagger/blob/adca4e6cb4...

#

Another tangential issue I noticed during adventures with https://github.com/dagger/dagger/pull/7767

An impure dagql API that has a list return value in the chain does not appear to work correctly.

Because it's impure, the query will be re-evaluated if submitted to the server again. However, if there were selections on the list, then the ID for the query will still include nth fields in that ID, but using the nth values from the first call to the API.

That seems like a bug becaus...

vivid lintelBOT
#

What is the issue?

@func()
    legendEngine(source?: Directory, useCachedContainer: boolean=false, configJson?: File): Container {        
        let ctr = this.engineBase(source, useCachedContainer)
        const cfgPath = "./config.json"
        if (configJson) {
            ctr = ctr.withFile(cfgPath, configJson)
        }
        else {
            ctr = ctr.withNewFile(cfgPath, {contents: this.engineConfig})
        }
        return ctr
root@hevv...
#

This fixes up some nasty code in the internal codegen of the rust sdk. It not only makes it more ideomatic, but also faster because of fewer allocations.

I also yak shaved a bit as I went, so I removed all the warnings in the codebase that had been around for a while. Clippy sometimes adds new lints, which we can optionally implement. Some of them are more relevant than others.

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 org.junit:junit-bom.

Updates io.smallrye:smallrye-graphql-client-api from 2.8.4 to 2.8.6

Updates io.smallrye:smallrye-graphql-client-implementation-vertx from 2.8.4 to 2.8.6

Updates io.smallrye:smallrye-graphql-client-implementation-vertx from 2.8.4 to 2.8.6

Updates org.junit:junit-bom fr...

vivid lintelBOT
#

What is the issue?

I'm using a module (https://daggerverse.dev/mod/github.com/cloudnative-pg/daggerverse/commitlint) that uses the git history to identify the commits between the PR head and the base ref and check if they respect a few conventions.

Since upgrading from dagger v0.10.3 to v0.11.9 (but I've then tracked down the breaking change to v0.11.2) running the module on a PR checkout checks only the latest commit, instead of all the commits between main and HEAD. On `workflow...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Problem

In main, output from the TUI stays on the terminal after completion. This is different from the behavior on the current stable release, 0.11.8.

  • On 0.11.8:
$ dagger call -m github.com/shykes/hello hello
hello, world!
  • On main (3767c8f0b3076a41c218c545c96641080b0e819b):
$ dagger call -m github.com/shykes/hello hello
✔ connect 0.1s
✔ initialize 3.1s
✔ prepare 0.0s
✔ hello: Hello! 0.0s
✔ Hello.hello: String! 0.2s

hello, world!
...
vivid lintelBOT
#

Relating traces generated by the Dagger engine based on external metadata is a good way to browse traces in Dagger Cloud, as we'll have to scroll through a list where it's hard to determine the origin of said traces otherwise.
Today, in Dagger Cloud, we are leveraging on Git metadata to be able to establish a relationship between individual traces and add contextual information.

However, it's possible that this Git metadata is not present, mostly when executing traces locally or in a CI e...

vivid lintelBOT
vivid lintelBOT
#

FINALLY fixes https://github.com/dagger/dagger/issues/6747

This builds on top of all the recent refactoring and:

  1. Fills existing holes in secret isolation (unskips test that was previously skipped that covers this isolation)
  2. Isolates sockets per-client
  3. Adds support for passing sockets as args using dagger call (e.g. dagger call --docker-sock /var/run/docker.sock)

Will flesh out commit messages+descriptions, but high level idea is that these session resources are now...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

(Spinning this commit out of https://github.com/dagger/dagger/pull/7804 because it's super tedious+boring and bloating that other PR too much on top the actual interesting parts.)

To fully isolate client-specific resources within a session, we need to move off of storing things like the SecretStore as fields on Query. This is because the dagql cache is shared across a session, meaning it can return objects from other clients that should not be used.

I just went ahead and got rid of all ...

vivid lintelBOT
#

Context

Thanks to the magic of GraphQL, it's very easy to build a "fan-out pipelines": pipelines where one step returns an array of objects, and the next step applies the same function to all objects in the array.

For example, given this module code:

package main

type Foo struct {}

// Receive a list of messages, and produce a corresponding list of files
func (foo Foo) Files(messages []string) []*File {
  files := make([]*File, len(messages))
  for i := range me...
vivid lintelBOT
#

(Not sure who to request reviews from while Vikram is on PTO, just chose a couple obvious candidates)

Filling in docs on this support now that it has baked with reports of successful usage for a bit.

NOTE: I'm purposely leaving out the experimental GOPROXY support from here for now since it's still in the "hacky _DAGGER_ENGINE_SYSTEMENV_GOPROXY" stage that is more of a bandaid than the http proxy+CA support, pending further work to formalize and stabilize it.

  • If we're okay with inclu...
vivid lintelBOT
#

In the quickstart, the Go SDK example has the correct exposed Nginx port of 80, but the Python and TypeScript examples incorrectly have 8080.

This means that if a user follows the TS or Python examples and runs this as a service by following

dagger call build --source=. as-service up --ports 8080:80

They will never get to connect to Nginx from their local browser.

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Currently if you run with --debug the CLI will go into a loop constantly logging the same log line repeatedly until it's eventually just a bunch of \\\\\\\\\\s from escaping strings in strings.

This was introduced by the recent TUI changes which directed logs to go to the primary span rather than to a separate TUI-only pane. Unfortunately, as part of the log handling (TUI consumes logs), we were logging at debug level, hence --debug introducing an infinite loop for any log line print...

vivid lintelBOT
#

Context

Since #6515, the CLI prints objects returned by a pipeline. To do this, it calls certain functions in the returned object, specifically functions which 1) return a printable value, and 2) have no required arguments.

Problem

When a pipeline returns a Container object, the CLI calls Container.stdout() and Container.stderr(), which causes the execution of the container. This is not the expected behavior.

For example:

dagger call -m github.com/dagger...
vivid lintelBOT
#

CLI verbosity scheme is now:

  • -s/--silent: total silence, no progress displayed ever
  • -q/--quiet: show progress, clean up completed ite
  • default: show progress, keep completed items
  • -v: show internal and encapsulated progress
  • -vv: show spammy progress, reveal digests
  • -d/--debug: show everything, set debug log level, reveal span IDs and other misc things

note: this also fixes the final render ignoring -s

vivid lintelBOT
#

Noticed that while debugging some flakiness in https://github.com/dagger/dagger/pull/7804

https://github.com/dagger/dagger/commit/ae1175dbaf1026511403943eb49132012dc6a942 (merged earlier today) improved session shutdown to happen quicker by disconnecting the attachables right when /shutdown is called.

/shutdown isn't called by nested module clients. However, it's valid when using other nested execs with a full blown CLI for them to call /shutdown. This wasn't handled well by that ...

vivid lintelBOT
#

Previously, DumpID was producing bad output, after lots of refactors to the frontend. Specifically, we were no longer sending newlines after renderCall which meant that everything appeared on the same line (additionally, DumpID wasn't taking into account that the client terminal is in raw mode, so needs \r at each newline).

To resolve this, we create a new little helper struct called Dump, which allows configuration of basic options, and can be configured by the dagger engine to ...

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

With https://github.com/dagger/dagger/pull/7744 we can define ignore patterns to apply when loading a default directory from the context. See:

However, if you specify a directory explicitly with dagger call, those patterns won’t be applied. Module authors need to continue setting views and tell end users to specify it next to the path.

If there are ignore patterns for a Directory type, the CLI can use them. If a view is passed, use i...

#

fixes #7007

  • remove a couple of not really helpful error wrapping spots (invoke:, response from query:)
  • specifically for modules, stop printing ExecErrors and GraphQL errors, so that we don't have redundant output with the trace visualization
    • cc @helderco @TomChv - we should make sure the equivalent is done by Python and TypeScript SDKs too. Basically, the module entrypoint should just skip logging things that look like "typical" errors (exec error or GraphQL API error). Not ...
#

The Python SDK tries to detect if a module is being created or not, in order to not create files from the template otherwise. Not doing this leads to:

We don’t have a reliable way to know if sources are being created for the first time. Here’s what Python does today:

  • When there’s no dagger.json, it’s definitely a new module.
  • If there’s a dagger.json but no pyproject.toml file (TS has package.json, but in certain situations Go m...
vivid lintelBOT
#

This supersedes:

IDs are hidden from the CLI for a reason (see https://github.com/dagger/dagger/issues/6710). However you can get the ID by calling sync. A better alternative is to follow the SDKs on how they handle sync by returning the Container corresponding to the resulting ContainerID using loadContainerFromID().

After https://github.com/dagger/dagger/issues/6515 it doesn’t seem necessary since a chain ending in a `Conta...

vivid lintelBOT
#

Collection of various follow ups from #7759:

  • Cloning issues - without doing cloning in the right way, we can get all sorts of fun issues, where deps are shared in confusing ways.
  • Update golden testdata for dagql
  • Elegantly handle a dagger.json without an engineVersion (assume it's from an older dagger version, before we had engineVersion)
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

As the TS runtime is using yarn as package manager to download SDK & user's dependency, it's best to use yarn as package manager until we ship a way to configure the package manager inside the TS SDK runtime.

We could also benefit from this system to allow configure the node runtime.

What we could do is setting a field in the same way we can configure the runtime:

{
  "dagger": {
    "packageManager": "npm@xxx | yarn@xxx | pnpm@xxx",
    "runtime": "bun@xxx | node@xxx",...
vivid lintelBOT
#

Context

Since https://github.com/dagger/dagger/issues/6515, the CLI prints objects returned by a pipeline. To do this, it calls certain functions in the returned object, specifically functions which 1) return a printable value, and 2) have no required arguments.

Problem

When a pipeline returns a Container object, the CLI calls Container.stdout() and Container.stderr(). This makes the CLI output 1) potentially very large, and 2) potentially mixed with binary data.

See [th...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

Right now when you call dagger version we send a trace to the cloud. This seems a bit silly and for larger teams contributes to the noise. We should supress these traces from being sent.

Why is this important to you?

Reducing signal vs noise in cloud is a good thing, this feels like a small but easy win.

How are you currently working around this?

No response

vivid lintelBOT
#

Fixes https://github.com/dagger/dagger/issues/7760

Instead of just using commit hashes and directory IDs, which produces nearly incomprehensible versions (which is more of a pain, now that engineVersion is actually important). This makes it a bit clearer when and where a non-tagged build came from by using changie to get the last release we built.

Frustratingly, it seems non-trivial to do version comparison on these, so we keep skipping these. In the future, we should work out on co...

vivid lintelBOT
vivid lintelBOT
#

@matipan noticed that in some integration tests where the engine is run as a service, when SIGTERM is sent to the engine it was also being sent to dnsmasq, which caused it to shutdown quickly and interfere with the engine's attempt to gracefully shutdown (e.g. flush cache, which can rely on dnsmasq still existing).

This turned out to be due to the fact that dumb-init, by defau...

vivid lintelBOT
#

This PR splits our Engine & CLI tests into:

  1. Module tests
  2. Everything else

We now run them as separate CI jobs which splits the test data and makes it easier to understand where the slowness is coming from. It should also make it easier to focus our test refactoring efforts on module tests since the rest of our test suite doesn't seem to be a problem.

Furthermore, before this change, running all these tests in CI was putting pressure on a bunch of components as they generate **a l...

vivid lintelBOT
#

Following up on https://github.com/dagger/dagger/pull/7852, this PR uses the packageManager field of the package.json to use the correct package manager.
If not, it detect the used lockfile.

This PR also includes a change to generate a lockfile (yarn v1 by default) but it can also generate a lockfile for pnpm or npm with the right version.

⚠️ It seems yarn v4, and specially corepack with yarn v4 isn't working well with Dagger, I'm writing tests for everything except yarn v4 and ma...

vivid lintelBOT
#

Problem

Now that the TUI "lingers" in the terminal (#7801), it becomes more important to avoid noise. Overall the current situation is good, except for 2 specific lines: ModuleSource.resolveFromCaller and ModuleSource.resolveDirectoryFromCaller.

✔ ModuleSource.resolveFromCaller: ModuleSource! 0.4s
✔ ModuleSource.resolveDirectoryFromCaller(path: "..", viewName: "default"): Directory! 0.0s

These lines shouldn't be visible at the default verbosity, because they ...

vivid lintelBOT
vivid lintelBOT
#

this commit introduces the following changes:

  • Keystroke for web visualization is now w for both logged-in and
    logged-out clients.
  • New --web global flag visualize trace in web browser.
  • Trace URL display:
    • logged in: URL gets printed at the top honoring -q and -s
      flags
    • logged out: Same as logged in with the ability to disable the
      message by setting an environment variable.

Signed-off-by: Marcos Lilljedahl

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Realized this while working through some stuff here: https://github.com/dagger/dagger/pull/7804#issuecomment-2221621579

Right now if you use interfaces and select a field, dagql caches the result, but the cache is completely separate from the equivalent field selection on the underlying type (and from equivalent selections on other interfaces wrapping the same underlying type).

I'm not sure how obscure this is yet, but we are definitely leaving some performance benefits on the table by ...

vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

Since the dagger documentation only mentions installing modules from github, I tested if you could also install a module from another git hoster, like gitlab in my example. I tried installing from a repository with a path of the form group/subgroup_1/subgroup_2/project. But since dagger (probably) assumes the repo path to be like github's, as in /project, it tried to pull the project group/subgroup_1, which obviously doesn't exist.

Why is this import...

vivid lintelBOT
vivid lintelBOT
#

Without this, we're just writing directly on top of the TUI, oops!

Before:

❯ dagger login jedevc

─   ←↑↓→: move  home: first  end: last  enter: zoom  +/-: verbosity=1  q: quit ────────────────────────
To authenticate, visit:
                       	https://auth.dagger.cloud/activate?user_code=XHSW-TXFD
Success.

After, this all collapses down neatly.

vivid lintelBOT
#

Notable improvements

  • Experimental support for uv.lock for project management. 🎉
  • Install uv from OCI image for better parallelization. 🚀
  • Don’t install dependencies during dagger develop to avoid a catch 22 situation where you need an updated sdk dir to update the lock but you can’t dagger develop because you need an updated lock.
  • Use the system’s certificate chain for TLS in uv rather than the Rust library it comes with which may not work correctly when our custom...
vivid lintelBOT
vivid lintelBOT
#

We keep seeing this error over-and-over: https://dagger.cloud/dagger/traces/fac54672078ee95878b8684af05a814b?span=4c9874e76c2371de#ca88400300bc5d96

Lots of things of the form:

	            	error: moving "binary-extensions" to cache dir failed: PathAlreadyExists

	            	  From: .544670b85583f3c2binary-extensions

	            	    To: binary-extensions@2.3.0

Something doesn't seem very right there, but given it's flakiness, I suspect it's something to do with con...

vivid lintelBOT
#

In theory schemas should be loadable based on prior validation by the time a query that loads them gets called, but we do see errors returned on schema load sometimes.

Previously, these were just getting turned errors with the message written direct to the body of the response, but that confuses graphql clients who expect a json format.

This updates these errors to use the write format so clients see actual comprehensible errors.


Since it's not really expected for these errors...

vivid lintelBOT
#

Some cherry-picks and pieces from #7858, since that one has some issues, and is risky!

Specifically:

  • Fix the process of updating a dagger.json during dagger develop (this was broken before, and now has some tests as well)
  • The engine should serve the CLI the API that it's clientVersion indicates it has - this isn't super useful right now, but is quite nice in the context of #7858.
vivid lintelBOT
vivid lintelBOT
#
  1. Update our integration template to make things more consistent
  2. Update Jenkins example to allow anyone to run it as is without needing to worry about having a specific type of project
  3. Fill out integration template for Jenkins

There are a couple more thing that I want to do in the near future to improve this even further, but I think this PR is a good iteration that improves the existing Jenkins guide.

Fixes docs-298

#

Problem

When I use dagger call ... up to open a tunnel from a Dagger service to my local system, it's not easy to open one of the service endpoints in my web browser.

  • The URL is not reliably printed on the terminal
  • The CLI doesn't automatically open a browser for me
  • The TUI doesn't give me a clickable link or hotkey to open the browser either

These may not be practical, or a good idea. All I know is that I wish it were easier to go from dagger call [...] up to a browse...

#

What is the issue?

While reviewing a PR I noticed that H1 and H2 appear to have the same font-size, looking in chrome dev tools I see some conflicting rules for h2, it looks like its being set to 2rem instead of using the variables.

h1  font-size: var(--ifm-h1-font-size);
.markdown>h2 {
    --ifm-h2-font-size: 2rem;
    margin-top: calc(var(--ifm-h2-vertical-rhythm-top)*var(--ifm-leading));
}
h2 {
    font-size: var(--ifm-h2-font-size);
}

It's not clea...

vivid lintelBOT
#

Did some hand editing in this case:

  1. Added a few missing breaking API changes (don't return void + use @func instead of @field)
  2. Wrote an extra section under Breaking Changes with some more details on the new compat mode and how to upgrade modules via dagger develop
  3. Reordered some of the entries to match the blog post + small misc formatting fixes

Would like to link to blog post here, but catch-22, so we can edit the release notes after the blog post is out with that link...

vivid lintelBOT
#

What are you trying to do?

Right now if I add a tag to dagger.json, it will install the correct version of my module, but it will overwrite the dagger.json to show the whole git sha. It would be nice to keep the tag visible because it's easier for me to look at a module with many installed modules and look at the human readable version to see what version I am on.

Why is this important to you?

Keeping the human readable version around is a smoother DX because it reduces cognitive ...

vivid lintelBOT
#

Did some hand editing in this case:

  1. Added a few missing breaking API changes (don't return void + use @func instead of @field)
  2. Wrote an extra section under Breaking Changes with some more details on the new compat mode and how to upgrade modules via dagger develop
  3. Reordered some of the entries to match the blog post + small misc formatting fixes
  4. Added a breaking changelog about the Go SDK alias removal
    • In our current system, this only showed up in the Go SDK rele...
vivid lintelBOT
#

Started hitting a lot of flakes in the new TestLegacy suite, errors look like:

input: module.withSource.initialize resolve: failed to initialize module: failed to call module "test" to get functions: call constructor: process "go build -o /runtime ." did not complete successfully: exit code: 1
                            
Stderr:
main.go:3:8: package dagger/test/internal/dagger is not in std (/usr/local/go/src/dagger/test/internal/dagger)

Could be unrelated, but it smells a...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Found this one during releasing, sadly didn't hit it before :cry:

When calling a v0.11.9 module from a v0.12.0 CLI+engine using the -m flag, the CLI is served a v0.11.9 API to match the module. I originally thought that this made the most sense.

However, it, really doesn't:

$ dagger call -m dev --source=.:default helm set-version --version=v0.12.0 -o ./helm/dagger/Chart.yaml
✔ connect 0.7s
✔ initialize 3.0s
✔ prepare 0.3s
✔ daggerDev(
    source: ✔ ModuleSource.reso...
vivid lintelBOT
vivid lintelBOT
#

What is the issue?

When calling Terminal() on a dagger engine with custom certs mounted in /usr/local/share/ca-certificates it either exits or times out. I have tested with a normal dagger runner and a custom runner without the mounted certificates and there are no issues. I believe it also affects the -i command because nothing happens when running that command with custom certs.

Dagger version

v0.12.0

Steps to reproduce

Follow these instructions to setup a runner with a...

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

This was reported by Nipuna in discord[1]

The terminal command seems to kick into "pre" terminal mode before the from image is pulled. So while the image is being pulled the TUI freezes on my screen.

I expected to have access to the TUI until at least the image for the corresponding container is pulled so I can watch that progress and know that it's being pulled. Pulling a large image can take time and it feels like everything is frozen while it does.

[1] ht...

vivid lintelBOT
#

What is the issue?

There were some work done to clean up the --progress=plain output to improve clarity in v0.11.x. However, it seems to have regressed in 0.12.0. Now the output displays codegen and introspection steps which can be considered noise in most instances.

Discord discussion: https://discord.com/channels/707636530424053791/1261532210205294702

Dagger version

dagger v0.12.0 (registry.dagger.io/engine) darwin/arm64

Steps to reproduce

Run `dagger call mymodule ...

#

What is the issue?

dagger version does not seem to always print the version. I see something flashing on the screen and disappear. If I keep
running it, the version may be shown intermittently but most of the time it prints a blank.

Dagger version

dagger v0.12.0 (registry.dagger.io/engine) darwin/arm64

Steps to reproduce

dagger version. Run it a few times. Observe output.

Log output

No response

vivid lintelBOT
#

What is the issue?

Need docs (and maybe tooling) for users with existing Go SDK modules who want to adopt Dagger v0.12

import

Could be as simple as:

Check what’s in go.mod and follow the module’s file structure from there. Basically /internal/dagger.

{Type} -> dagger.{Type}

dagger function or script or process

How to deal with WithExec() change to not invoke entrypoint by default

Have to change the code to one of these:

  1. `WithExec([]string{"show", "...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Problem

In Dagger 0.12, dagger login prints an auth URL, but doesn't let me click on it. I also can't select any text anywhere in that terminal window. After I exit the TUI with q or ctrl-C, the link becomes clickable.

I tried this on 2 different terminal emulators (Zed and Ghostty on MacOS).

vivid lintelBOT
#

What are you trying to do?

This request was inspired by the addition of Enum support in 0.12.

@dagger.enum_type
class Severity(dagger.Enum):
    """Vulnerability severity levels"""

    UNKNOWN = "UNKNOWN", "Undetermined risk; analyze further"
    LOW = "LOW", "Minimal risk; routine fix"
    MEDIUM = "MEDIUM", "Moderate risk; timely fix"
    HIGH = "HIGH", "Serious risk; quick fix needed."
    CRITICAL = "CRITICAL", "Severe risk...
#

The client is expecting a given API - loading a module shouldn't update the version of the API that it's served. This was a minor design mistake, and just doesn't make sense as is.

With that patch, there are now no fields on the Terminal type that are served to a v0.12 CLI. This is an issue, because now, nothing forces the evaluation of the type!

To avoid this, we add Terminal.sync, which allows the CLI to force execution of a Terminal type, with a special field just for t...

vivid lintelBOT
vivid lintelBOT
#

This hack should buy us a bit more time for browse-by-function.

We initialize the Frontend/TUI/root span very very early in the CLI lifecycle - before even parsing os.Args, which requires loading modules, which needs to be beneath the root span.

So, we have to resort to hacks/heuristics to get a shorter name.

For dagger call specifically, statically parse os.Args with the following rules:

  • Drop all flags passed before call (e.g. -m, --debug)
  • Drop all flags passed a...
vivid lintelBOT
#
  • Drop Elixir v1.14 and add Elixir v1.17.
  • Improve Elixir version management by using map instead of slice of string. With map, we can freely manage OTP version and OS separately.
  • Visualization improvement, just using errgroup.Go is quite hard to read on the TUI visualization. In this changes, add the tracer to it by labeling it with test - elixir/ pattern.
  • Add dagger_codegen test by running only elixir latest version. And add tracer to separate between dagger SDK and `dagger_...
vivid lintelBOT
vivid lintelBOT
#

What is the issue?

This and similar no longer works

dagger -m github.com/dagger/dagger/linters/markdown@88d89e8d15ab6ad9ca4043a920d3cd735a6405fd call rules contents

Need to find them all and fix 'em!

Dagger version

dagger v0.12.0

Steps to reproduce

run it

Log output

➤ dagger -m github.com/dagger/dagger/linters/markdown@88d89e8d15ab6ad9ca4043a920d3cd735a6405fd call rules contents



Full trace at https://dagger.cloud/dagger/traces/05d8c859146ced70c50...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

:cherries: Cherry-picked out of #7438, since that one is kinda stalled, not really sure what to do with it.

In the process of the above PR, I'd attempted to add a required enum arg, which the typescript codegen hadn't previously covered - so I added this case.

While this isn't used by any API at the moment, it's useful to cover it anyway, so when we inevitably do, we don't spend any time on hunting down why it's not working.

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What happened? What did you expect to happen?

Hey! I'm testing out Dagger for the first time and followed the quickstart guide.

When I ran dagger init --sdk=go in the root of my existing repository (not hello-dagger), it generated a dagger Go module:

$ tree dagger
dagger
├── .gitattributes
├── .gitignore
├── dagger.gen.go
├── go.mod
├── go.sum
├── internal
│   ├── dagger
│   │   └── dagger.gen.go
│   ├── querybuild...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Problem

Container.withEnvVariable can expand env variables with an optional expand argument (#7171). But this is not supported in other Container operations that may need it:

  • withExec (expand variables in args)
  • withFile, withNewFile, withDirectory, withoutDirectory, withoutFile, withMountedXXX... (expand variables in path)

I have personally needed this argument in withExec and withNewFile

vivid lintelBOT
#

Problem

  • When Container.withExec is called, it emits an otel span. When it returns a (lazy) container ID, that span ends.
  • Later, this may cause an actual exec, with a separate span
  • These two operations are highly coupled, but having them in separate spans does not convey that
  • The current stopgap of "transplanting" the exec span as a child of the withExec span is an improvement, but it's not enough
  • By showing to the user a withExec span and a separate exec span, ...
vivid lintelBOT
#

After applying #7904, we've seen jobs hang weirdly.

See an example:

Side note: somehow, I did reproduce locally, not sure how, I can't get it to happen again :scream:

Something is bizarrely wrong here - the hanging at the end feels reminiscent of a telemetry draining issue from where we saw them before.

A couple not...

vivid lintelBOT
#

Context locks were introduced (in #7272) as a way to prevent needless switching between two spans: e.g. suppose that span A and span B were running at the same time producing logs. If they both produce high volumes of logs, we want to ensure that we switch between them at a "reasonable" rate, and not switch back and forth immediately as they become available (which is significantly harder to read).

However, this initial implementation was slightly flawed: once a span acquired a lock, it wo...

vivid lintelBOT
#

What is the issue?

Cannot use dagger go sdk version 0.11.7.
When bumping the version, I get the below error

dagger.io/dagger: dagger.io/dagger@v0.11.7: parsing go.mod:
        module declares its path as: github.com/dagger/dagger
                but was required as: dagger.io/dagger

Can successfully use older and newer versions of the SDK, but we specifically need 0.11.7 as it is the only version where the engine is using nftables instead of the deprecated iptables.

###...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

I updated from 0.11.8 to 0.12.0 in a Typescript project. Of course there were some breaking changes, but my IDE and other checks didn't pick up anything. This is because the SDK that is downloaded in my module was still for 0.11.8. Well, I couldn't for the life of me figure out how to update the SDK. I can't find anything in documentation, and if the CLI has a tool for this, I can't find it. Performing dagger init again just says it's already been initialized...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Fixes https://github.com/dagger/dagger/issues/7910

Custom CAs were not working with Terminal due to the fact that
installing custom CAs required running setup/teardown execs. Those execs
were getting inconsistent configuration that partly configured terminals
to be setup but also partially not (specifically, runc was told to setup
a tty but did not find /dev/tty).

The fix here is to just fully disable terminals on those setup/teardown
execs.

Majority of the diff here is to add i...

vivid lintelBOT
#

Support for unix sockets as function args was merged here: https://github.com/dagger/dagger/pull/7804 so it will be in the upcoming release.

I created a tiny demo module that I reference in the docs; it currently just lets you pass a host docker unix sock as an arg and then calls "docker version" on it: https://github.com/sipsma/daggerverse/blob/c19ee68f84b228942bac8047a9d8337fc22a3479/docker-client/main.go

Should not be deployed until next release (0.12.1)

vivid lintelBOT
#

This is part of an effort to start writing better changelogs! Just added some people to review who I've chatted to about this before :tada:

Changie supports multiline bodies, that looks something like this:

image

The idea is to have more extensive changelogs as we go forward, essentially trying to follow something like a "git commit" format:

  • The first line should be a summary of the change
  • Any...
#

Problem

dagger --interactive is awesome, but sometimes it doesn't work because the container being inspected doesn't have /bin/sh and as a result, the terminal fails.

Solution

Let me customize the command to execute in the interactive container, or, perhaps, fall back to executing the default container with the target container's workdir and/or rootfs mounted? That way, I can at least look at the files.

#

While merging a lot of the things for v0.12.1, a few things got lost in the noise:

  • TestContainer/TestInsecureRootCapabilitesWithService does docker network access, and so should be given the host's docker config if it can be found.
  • TestModuleDevelopVersion has some duplication with TestModuleSchemaVersion - we can remove those, since all the permutations are tricky to handle in the develop test.
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Started seeing this one a bunch recently:

From what I can tell looking in the engine logs above it, it does appear the expected error is likely getting hit, it's just not getting relayed to the clients as expected.

cc @vito @jedevc no initial clues what changes would have ...

vivid lintelBOT
#

This one has been affecting us for a while, just noticed we don't have an issue for it.

The MacOS provisioning job (which verifies SDKs can provision engines when running natively on MacOS; only runs on main + bump engine PRs) fails more often than not before dagger is even involved when it tries to install docker.

It will just hang on Waiting for the essential requirement 1 of 2: \"ssh\"" repeatedly until it times out.

Example: https://github.com/dagger/dagger/actions/runs/99984...

vivid lintelBOT
#

Most recent example: https://github.com/dagger/dagger/actions/runs/9999104348/job/27639432208#step:7:645

This has been seen a handful of times recently (first known was here: #1254757484057464975 message).

Pretty rare and ephemeral but not just a one-off at this point. Have not ever encountered it locally yet though, only CI.


Initial spelunking:

It's from boltdb: https://github.com/sipsma/buildkit/blob/d2c730c0f9ab...

vivid lintelBOT
#

More follow-ups once release is done:

  • Fix ordering of instructions to ensure that the changelog PR is always included in engine+cli tag: #1262430315683647578 message
  • I have to run dagger develop before the instructions on updating dev/ with go mod edit/tidy fully work. Was an issue this time because I had recently run git clean, which resulted in errors
  • We really need to fix the permissions issue with the bump engine PR...
vivid lintelBOT
vivid lintelBOT
#

Context

In Traces, function calls are shown with information about their status:

  • If the function returned an error, it's shown in red
  • The error message is displayed in a special box - at least in theory

Problem

The error message shown in the box is not the one actually returned by the function. Instead, it's always the same generic, and useless, message:

`call function "Foo": process "/runtime" did not complete successfully: exit ...

vivid lintelBOT
#

Possibly fixes https://github.com/dagger/dagger/issues/7979 (to be confirmed in CI since that's the only place I can get it to happen).

I also am not sure yet if this is handling expected behavior more robustly vs. just avoiding a bug. If it's just avoiding a bug we shouldn't go with it.

Basically, I noticed that these flakes appear to just be cutting off the output while it's still being received. If you look in the logs you can see most of the expected output there but not all of it, ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

When there is a long running action being displayed on the TUI, I want to zoom into it and have it take up all the horizontal and vertical space of my terminal. Right now, the "zoom in" feature does a focus but the size of the viewport doesn't change.

Dagger version: v0.12.1

Why is this important to you?

Some CLIs I run via dagger has long running log streams (eg. mvn clean install) that occupy the full terminal real estate. Following those logs via...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

This has been discussed on various internal trackers and work has been started, converting to a public issue now.

Goals

Primary: Make the cache storage of the Dagger Engine pluggable and configurable, including both local and remote cache

  • Layer caching - Users should be able to get the same seamless remote caching enabled by Dagger Cloud but with their own storage locations (as opposed to the ones created by Dagger's infra).
    • The important features to retain from Dagger Clo...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

This is a WIP PR to integrate to run the Dagger engine on HashiCorp's Nomad

It provides another dial protocol nomad-alloc:// that can be used via the _EXPERIMENTAL_DAGGER_RUNNER_HOST

e.g. nomad-alloc:// or just via the job nomad-alloc://?job=

Demo

Nomad Config

plugin "docker" {
  config {
    allow_privileged = true
    allow_caps = [
        "all" # or a defaults + sys_admin
    ]
  }
}

Deploying the engine via [nomad-pack](https://githu...

vivid lintelBOT
#

Reported in discord here: #1265136358838763561 message

Can repro in an integ test:

	t.Run("parent fields", func(ctx context.Context, t *testctx.T) {
		c := connect(ctx, t)
		ctr := c.Container().From(golangImage).
			WithMountedFile(testCLIBinPath, daggerCliFile(t, c))

		ctr = ctr.
			WithWorkdir("/work").
			With(daggerExec("init", "--name=test", "--sdk=go", "--source=.")).
			WithNewFile("main.go", `package main
...
vivid lintelBOT
#

The recent change to isolate secrets+sockets works by tracking which resources a given client should have access to based on inputs+outputs to/from function calls.

Unfortunately, on the input-side, this only handled arg value inputs, but I missed the other source of inputs: fields set in the parent object. If you had a module object with a Secret (or a Container with an embedded Secret, etc.) field, then trying to use that Secret in chained function calls usually failed.

The fix is stra...

vivid lintelBOT
vivid lintelBOT
#

[!WARNING]
This is rebased on top of:

Before

Name overrides were created as an escape hatch to allow using function, attribute, and parameter names that conflict with Python reserved words:

from typing import Annotated
import dagger

@dagger.object_type
class Test:
    from_: str = dagger.field(name="from")

    @dagger.function(name="with")
    def with_(self, import_: Annotated[str, dagger.Arg(name="import")...
vivid lintelBOT
vivid lintelBOT
#

Fixes https://github.com/dagger/dagger/issues/7913

This contains two main fixes:

  • The first fixes context sampling, so that we always take everything up to the first call. This means we can keep initializing module under initializing.
  • The second fixes the effect wake-up by removing it - we don't actually need it for plain progress, there should never be a case when the plain progress will stop rendering for a span (it's assumed to live forever really). This was causing a lot o...
vivid lintelBOT
vivid lintelBOT
#

Fixes a failure in main:

╭─ Error ──────────────────────────────────────────────────────────────────────╮
│ Function execution error: resolve: process "uv --verbose tool install        │
│ hatch==1.12.0 with uv==0.2.27" did not complete successfully: exit code: 2   │
│ Stdout:                                                                      │
│                                                                              │
│ Stderr:                                             ...
vivid lintelBOT
#

This came up while working with someone on an issue, just echoing what they brought up.

Showing Void as the return type in the TUI output is confusing. The word itself is kind of ambiguous from a end-user perspective (what does that mean? does that mean it did nothing? etc.), especially since it's just an implicit return type and hidden from code they write.

Seems like we could just drop it from the TUI and show no return type (which is what it means) and instead rely on the green che...

vivid lintelBOT
#

This test flakes occasionally due to timeout errors (just enough to be annoying). Looking at the traces, it seems like when under heavy load the container import step just takes a while and brings it close enough to the 1 minute timeout to hit it during the test.

This updates the test case to first do a synchronous import of the engine container and only after that apply the timeou...

vivid lintelBOT
#

What is the issue?

Dagger, in version 0.12.2, no longer manages to check out a Git repository as "WithDirectory". It seems as if it parses the path, considers the protocol ("http"/ "https") as a folder, and tries to use that locally.
This still worked with 0.12.1.

0.12.2

vscode ➜ /workspaces/terraform (main) $ dagger --interactive -m daggerform call tf-plan-get --terraform-debug-local=true --terraform-module=https://${GITLAB_USERNAME}:${GITLAB_TOKEN}@/ --gitlab-token=env:GI...
vivid lintelBOT
#

The CLI should support loading images into the local container image store - whether that's docker, containerd through ctr/nerdctl, podman, etc.

Today, this might look something like:

$ dagger call container-echo --string-arg=foo -o ./image.tar
$ docker load -i ./image.tar

However, we should really have a native way to do this - something like:

$ dagger call container-echo --string-arg=foo --load :

Why?

  • Makes it easier for dagger to exist as a full...
#

Buildkit update:

Containerd update:

vivid lintelBOT
#

The recent changes to dagger codegen (#7872) meant that locally generated dagger.gen.go files were overwriting the generated files. This was because GeneratedContextDirectory takes the entire context directory (including any local dagger.gen.go files), and applies it's changes on top. So if dev/go/dagger.gen.go was generated on an old version of dagger, then it would be applied as part of a later codegen step, e.g. from sdk/typescript/runtime :scream:

The reason this happened is...

vivid lintelBOT
#

Currently, a module invokes itself through the native language (e.g. self.otherFunction), which completely bypasses dagger.

Instead, dagger could provide a proper mechanism for a module to invoke one of its own functions via the engine in order to get:

  • Caching: Calling your own function should get the same caching treatment as invoking an external function
  • Observability: Invoking your own function should create a new span, visible from TUI/Cloud

This could potentially al...

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

When passing a secret to Dagger using cmd:command-to-run, if the command outputs a trailing newline, then Dagger is unable to scrub the secret in its output.

Dagger version

dagger v0.12.2 (registry.dagger.io/engine) linux/amd64

Steps to reproduce

❯ dagger call -m github.com/yann-soubeyrand/dagger-test test --secret 'cmd:echo secret'
Full trace at https://dagger.cloud/Camptocamp/traces/62d1ca4a7d3bff136de1cdf1e926a646

✔ connect 1.0s
✔ initialize ...
vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

I try to pass a GitHub token as a secret to a Dagger function which uses it as an environment variable in a container. For this, I use the cmd:gh auth token syntax. The problem is that the gh auth token command issues a trailing newline which is not stripped and appears in the environment variable value. The command using this environment variable doesn’t work then. I’d like to have a way to tell Dagger to strip the trailing newline.

Why is this import...

vivid lintelBOT
#

What is the issue?

Injecting a secret in the Directory.docker_build() function seems either broken or extremely confusing.
First, the example provided in the Cookbook (See https://docs.dagger.io/cookbook#use-secret-in-dockerfile-build in Python tab) is wrong, no dagger.DockerBuildArgs exists, only dagger.BuildArgs exists, which I suppose is the one required here as it correctly injects the build args in the Dockerfile.
Also, the example seems wrong, the id=gh-secret in the Doc...

vivid lintelBOT
#

What is the issue?

When I install dagger using homebrew:

$ brew reinstall dagger             
==> Fetching dagger/tap/dagger
==> Downloading https://dl.dagger.io/dagger/releases/0.12.2/dagger_v0.12.2_darwin_arm64.tar.gz
Already downloaded: /Users/rleone/Library/Caches/Homebrew/downloads/99fd18c03c229447e23557d450e1036a51b6d58dc24084bffb8d4b3c57b8df6b--dagger_v0.12.2_darwin_arm64.tar.gz
==> Reinstalling dagger/tap/dagger 
🍺  /opt/homebrew/Cellar/dagger/0.12.2: 5 files, 25.9MB...
vivid lintelBOT
#

Currently, services have a built-in health checker (portHealthChecker) that verifies the container ports defined in withExposedPort are reachable.

Sometimes, this is not enough for services binding ports before they're actually healthy.

Dagger could provide a way to define "custom" healthchecks.

Possible solutions:

  • Define a custom command that gets invoked in the service container to check for health
  • Same as above, but use the HEALTHCHECK docker/oci directive
    • D...
vivid lintelBOT
vivid lintelBOT
#

TODOs after release is done:

  • [ ] Fix ordering of "Update all dagger versions in docs/current_docs/partials/_install-cli.mdx to $ENGINE_VERSION"
  • [ ] Include one-liner command to update all the github yamls with new engine version, to save on toil
    • find .github/workflows/*.yml -type f -exec sed -i 's/0-12-2/0-12-3/g; s/0\.12\.2/0\.12\.3/g' {} +
  • [ ] (Maybe if time) chisel away at one manual step, e.g. automate the SDK changelog generation + engine version bump in CLI docs so tha...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Spinning this out from https://github.com/dagger/dagger/pull/8040

In the effort of slowly automating our release process towards being one-click (or at least "few-click"), this automates the SDK changelog generation, which is currently a manual step in RELEASING.md (among many others we should gradually squash over time).

I hit my timebox on this today, so a few TODOs left.

  • [ ] Figure out how to safely export deleted files (e.g. sdk//.changes/unreleased/*) back to the caller
    ...
ornate vigilBOT
#

I wanted to share some feedback from one of our engineers, who put together a basic test for running Tilt with Dagger. For the test we used Docker Engine v26.0.0 in a GCP virtual machine running Ubuntu 22.04, using Dagger v0.12.0 and the k3s v0.0.4 Daggerverse module.

Dagger was successfully able to:

  • Start a k3s cluster as a Service
  • Create an Ubuntu 22.04 build container, configured to use the k3s cluster
  • R...
vivid lintelBOT
#

Current implementation of module inclusion / exclusion can easily lead to silent conflicts between the glob patterns:

  • a module can exclude: */sdk and include: depth1/sdk/

For BuildKit, this would lead to a priority for the exclusion, but can lead to weird Dagger behavior: for example, in https://github.com/dagger/dagger/pull/8042 dagger install sdk/python/dev leads to a failure because it auto excludes itself, as the install path contains sdk

This commit ensures that Dagger fai...

vivid lintelBOT
#

When starting a service with Service.start, it's expected that the user will call Service.stop to stop the service. The user can then choose to use SIGTERM/SIGKILL, etc.

The problem is - this model works poorly with modules - if a module function returns a Service, then how can the caller know the details of this? There's a real issue if this ends up called by the cli with Service.Up - when CTRL+C is send, the service is killed (the default if the user doesn't call SIGTERM)...

vivid lintelBOT
#

Fixes https://github.com/dagger/dagger/issues/8032, and other assorted issues.

Imagine we have a secret like foo\n - we should also attempt to censor it in the output if we see foo. However, this is trickier than it initially seems - if we see foo\n, we should replace it with *** - not ***\n.

To do this, we modify the secret scrubber to be greedy, instead of eager. We now keep track of matches, and keep looking for more, instead of immediately replacing it.

Additionally...

vivid lintelBOT
#

Problem

Sometimes your Dagger module is publicly reachable, but not intended to be publicly used. There is no way to communicate this, so private modules pollute daggerverse search results, and users get no warning when installing them.

Solution

  • Add an optional private boolean flag to dagger.json
  • dagger init --private sets the flag
  • Daggerverse honors the flag by hiding (partially or totally) private modules in search results
  • dagger install returns an error o...
vivid lintelBOT
#

The use case of:

  1. Building Dockerfiles via the Container.build or Directory.dockerBuild APIs
  2. That have secrets attached
  3. That were created by modules and returned as Container values

Appears to have been broken for a while.

Before the secret isolation in v0.12.1, it was broken because these returned Dockerfiles were re-evaulated when the core ID was loaded after the function returned but the accessor was calculated again based on the caller, which resulted in a differe...

vivid lintelBOT
#

What is the issue?

Dagger.Client.host/1 function is advertised in docs, however calling it fails with an following error, and so is fails Dagger.Host.directory/2 (so I must be doing something wrong here):

# removed for brevity
Compiling 3 files (.ex)
    warning: Dagger.Host.directory/2 is undefined (module Dagger.Host is not available or is yet to be defined)
    │
 14 │       |> Dagger.Host.directory("/tmp")
    │                      ~
    │
    └─ lib/dagger_module...
vivid lintelBOT
vivid lintelBOT
#

What is the issue?

18  : Container.stdout ERROR [6m19.4s]
18  : ! process "/dev/.buildkit_qemu_emulator /bin/sh -c /ods-ci/ods-ci/run_robot_test.sh" did not complete successfully: failed to copy xattrs: failed to set xattr "security.selinux" on /tmp/buildkit-qemu-emulator2534885165/dev/.buildkit_qemu_emulator: operation not supported

Dagger version

dagger v0.12.3 (registry.dagger.io/engine) darwin/arm64

Steps to reproduce

I have the following Python script

vivid lintelBOT
#

What is the issue?

I am trying to use custom Yarn and NPM corporate registries with remote Dagger Engine. Currently my .yarnrc.yml and .npmrc on local are configured to work with my company proxies and registries settings.

But since I don't have the possibility to get Docker on my laptop, I need to run jobs on a remote Server.
Those package managers configurations are not passed to the Dagger Remote Engine.

I am currently trying to see if I can use some environments variables ...

vivid lintelBOT
#

What are you trying to do?

Sometimes your build can get into a weird state, and its often related to cache volumes,. However, its hard to troubleshoot, it would be great to have a CLI option to run the engine while ignoring all cache volumes.

Why is this important to you?

This is a painful DX, if I had a flag that allowed me to enable or disable mounting cache volumes it would be a lot easier to rule out cache volumes as the issue when things go wrong.

How are you currently ...

vivid lintelBOT
#

This still depends on the following fix to work:

But can be merged before that as the snippets weren't quite right.

Using a build arg is one approach, but you need to adjust the Dockerfile to use that as the ID. I think the approach in this PR is simpler and doesn't require changing the Dockerfile.

Suggestion for the future

Better fix would be a breaking change so that the secrets argument to the docker build would be similar ...

vivid lintelBOT
#

What is the issue?

When using podman 5.1.2 + wsl2 and trying to do dagger init on an already existing codebase, Dagger fails with a grpc client connection closed error.

Discord thread: https://discord.com/channels/707636530424053791/1267572025791090759

Dagger version

v0.12.3

Steps to reproduce

  1. Have a wsl2 + podman >= 5.1.2 setup
  2. Perform a dagger init --sdk $sdk on an already existing project

Log output

! failed to export: rpc error: code = Canceled des...

vivid lintelBOT
#
pck

What is the issue?

Mostly the emulation for arm64 containers on amd64 works great.
Unfortunately there are issues with amd64 dagger-engine hosts running linux/arm64 images.

  • Interactive terminals can't be started. (workaround: use WithExec)
  • Services cannot be bound. (no obvious workaround?)

The other direction (macos arm64 dagger-engine host with linux/amd64 images) works as expected.

Dagger version

dagger v0.12.3 (registry.dagger.io/engine) linux/amd64

Steps to rep...

vivid lintelBOT
vivid lintelBOT
#

Fixes the following flake:

Error: response from query: input: daggerDev.engine.lint resolve: call function "Lint": process "/runtime" did not complete successfully: exit code: 2

Stdout:
invoke: input: dirdiff.assertEqual resolve: call function "AssertEqual": process "/runtime" did not complete successfully...
vivid lintelBOT
#

When working on private SSH support, I realized that our support for Azure refs is broken on monorepos.

Why ?
Azure's handling of go-get=1 is not foolproof:

  1. repoRootForImportPath does work well on refs leading to a repo, infering properly the vcs provider used
  2. But, go-get=1 returns a 500 when a subpath is included
  3. Azure ref's style is explicit with the vcs being used: git is mentioned for a git based repo

If we are ok with this explicitness, we should not try to...

vivid lintelBOT
vivid lintelBOT
#

Follow-up to:

  • #7493

The path to the codegen script changed so CI needed fixing.

Also took the opportunity to:

  • Update base containers from CI and module runtime to be more similar
  • Add missing change log from the above PR

Follow up

We need to fix something else in PHP's codegen. The sdk php generate command doesn't remove files that are already there.

#

This allows users to use community/elixir to use the elixir SDK, and community/php to use the php SDK, without needing the full github.com/dagger/dagger/sdk//runtime@ URL which is very unweildy.

:warning: requires https://github.com/dagger/dagger/pull/7858 so that we can access engine.Tag which is the version of the release, so the v0.12.4 release will correctly point this to github.com/dagger/dagger/sdk//runtime@v0.12.4.

vivid lintelBOT
#

Add support for custom objects in the PHP SDK runtime.

Tested this manually with the following three classes in my module:

#[DaggerObject]
class Potato
{
    #[DaggerFunction('Get Chips')]
    public function getChips(): Chips
    {
        return new Chips(
            dag()->container()->from('alpine:latest'),
            dag()->defaultPlatform(),
            new Sauce('mayo'),
        );
    }
}
#[DaggerObject]
class Chips
{
    public function ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
ornate vigilBOT
#

First of all, thank you for spending time on doing these tests and writing it all up. This feedback is super valuable for us.

We'd love to work with you to make this POC work as you'd expect (get to 100%). In particular, we'd like to dig into networking and health check challenges you had with Service containers (more polish planned there). Let us know if you'd like to pair up on it.

Your feedback is well-taken and super appreciated. Some more notes below.

We're rapidly iterating on ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

Add support for passing constructor arguments to PHP SDK modules.

Why is this important to you?

It would allow additional arguments to be defined that may be important to multiple functions on the same module.

i.e. The every function in the PhpSdkDev module requires defining a source argument.
If instead we could rely on a constructor, it would only need to be defined once. Saving time and loc

How are you currently working around this?

Repeti...

#

Why?

The generated directory should only be generated by dagger. It should not need to exist in the repository

What Needs To Be Done?

Currently, the codegen seems to rely on an already existing Dagger\Client in order to generate the code. Once it stops depending on it, we can safely remove the generated directory from the repo.

#

What is the issue?

What and Why

The PHP SDK now has a runtime, it would be useful for people to be able to find out about this through the official documentation.

Existing Docs

Currently the only documentation for the runtime is sdk/php/README.md. Only someone looking into the codebase will find out it exists.

#

What are you trying to do?

Remove the following deprecations:

  • sdk/php/src/Connection/CliDownloader.php
  • sdk/php/src/Connection/ProcessSessionConnection.php

Why is this important to you?

Both classes use now unnecessary methods of acquiring the dagger client, downloading and manually setting up the environment variables.

With the runtime now being implemented, moving forward, the best way of setting up the environment is to simply create a module using the runtime.

...

vivid lintelBOT
#

Problems

  • Our current function declaration api is a bit verbose and hard to remember, cause me to slow down on write a function.
  • The use Dagger.Mod name is a bit too generic but it specific to build only object type.

Solution

Turns the function declaration api from module attribute to macro and change the type signature to typespec with limit type supports. The code is now changed from

@function [
  args: [string_arg: :string],
  return: :string
]
def c...
vivid lintelBOT
vivid lintelBOT
#

Reported by user in Discord.

something changed, and ive been out of loop for some time as i was not paying full attention, i was defining a go type, to simulate an enum in some ways, i.e type lang = string and then lang = Go, lang = "Csharp" etc etc, I was then using this custom type (which still is a string) as part of the dagger function API, since upgrading it no longer works and ive just rid of that concept and ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Instead of setting dag to the struct of the object type, use GenServer
to store it during invoke the function. And add import statement to
Dagger.Mod.Object to make a function can access dag instance via
dag/0 function.

And this commit change how to calling a function by temporary passing
only arguments to the function (previously it pass a struct and
arguments).

This is another breaking changes, since user don't need to declare a struct that containing dag instance and fun...

vivid lintelBOT
#

What is the issue?

While performing a dagger call in a module that has a dependency which points to a ref that doesn't exist on a branch in the target repo, the call will fail with the following message:

Error: input: moduleSource.withContextDirectory.asModule resolve: failed to create module: select: failed t
o update module dependencies: failed to load module dependencies: select: failed to load pre-configured dependencies: failed to create module source from dependency: select:...

vivid lintelBOT
#

I found the GraphQL API can be accessible by default because the struct always public, anyone can accessing it. The SDK also provides 2 types of the API, query for executing raw query, and execute that execute the query builder and get value from the leaf node. So I add the document to it to the Dagger module.

And I also do some refactoring by:

  1. Make Dagger.Core.Client.execute API be consistent with the Dagger.Core.Client.query function.
  2. `Dagger.Core.QueryBuilder.Selecti...
vivid lintelBOT
#

Here is the log from mix deps.update --all:

Resolving Hex dependencies...
Resolution completed in 0.052s
Unchanged:
  makeup_elixir 0.16.2
  nimble_parsec 1.4.0
Upgraded:
  bunt 0.2.1 => 1.0.0 (major)
  credo 1.7.0 => 1.7.7
  earmark_parser 1.4.39 => 1.4.41
  ex_doc 0.32.1 => 0.34.2 (minor)
  file_system 0.2.10 => 1.0.0 (major)
  jason 1.4.0 => 1.4.4
  makeup 1.1.1 => 1.1.2
  makeup_erlang 0.1.5 => 1.0.1 (major)
  nimble_options 1.0.1 => 1.1.1
* Updating jason (Hex pa...
vivid lintelBOT
#

[!warning]
This is a breaking change for Go SDK users when depending on a module that has a non-null function argument with a default value. With this change, the argument will change from required to optional in the client bindings (dagger.gen.go).

Todo

  • [ ] Backwards compat with older engine versions
vivid lintelBOT
#

IncludePattern was added to the ReadDirRequest options as per this discussion during the initial implementation of Directory.Glob.

While this works as intended for globstar patterns like **/*.md, it has the unintended side-effect of excluding sub-directories from being recursed for less well behaved patterns. Take a simple example: if your pattern is core/**/*.go, as soon as the recursive call to Glob en...

vivid lintelBOT
#

Refactor

This was split from https://github.com/dagger/dagger/pull/7744 in order to make the changes clearer in that PR, which includes a deprecation, but also a few more type checking fixes.

Arg deprecation

Arg as been deprecated in favor of Name, in preparation for supporting more metadata to arguments. The initial idea was to add them to Arg, but there's a reason for wanting a separate Doc and it's strange to have one specific ...

vivid lintelBOT
#

[!NOTE]

This is an alternative to https://github.com/dagger/dagger/pull/8108 - thanks @khrisrichardson for doing most of the hard investigation, but I think it was worth doing the restructuring of glob entirely, it needed doing here anyways. I've added you as a co-author to this PR :tada:

Globs weren't correctly working - the root issue here was that IncludePatterns is interpreted as relative to the Path passed into ReadDir.

This is kinda not great, since we keep the same...

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

@helderco noticed that https://github.com/dagger/dagger/pull/7937 introduced an issue in https://github.com/dagger/dagger/pull/7948#discussion_r1682570312:

Is this now always producing a diff on generate due to random ids? Might make sense to discard changes if so.

This makes sure we actually run the docs generate step! (which it doesn't look like we've been doing enough!)

To do this though we need to use a temporary fork of spectaql that has reproducible example snippets. See ...

vivid lintelBOT
#

What is the issue?

I think I found a bug with the cmd: feature on the --secret=cmd:"" feature, on the Windows version of Dagger.

env: seems to work fine, and this is how ive been passing secrets until recently as I explore and try new approaches.

I want to use cmd: and use 1Password or some other command to retrieve a secret, though what seems to be happening is its falling back to a sh/linux way of executing the cmd:.

This reminds me of a similar issue I raised a...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

This PR attempts to replace the existing strcase library with a different implementation to fix #7941

In addition to replacing the library, we are moving this implementation to a local dagger package (currently under dagql folder, more on this later), so that:

  1. We can customize the behavior as per our requirement
  2. If needed, we can easily replace the backing library in future.
  3. Add unit test coverage as this transformation is critical for dagger codegen and graph functionalit...
vivid lintelBOT
#

Problem

By default, daggerizing an existing project (either with dagger init --sdk=NAME, or dagger develop --sdk=NAME) will cause littering, by mixing Dagger-managed files with pre-existing files. This can cause frustration and confusion just as a user is familiarizing themselves with Dagger.

Experienced Daggernauts can avoid this littering by explicitly setting --source to a subdirectory. But 1) this is cumbersome 2) it prevents a shared convention on default source directory ...

vivid lintelBOT
#

A "format" function will make it easier for other maintainers that get PHP linting errors, to run the formatter in order to solve them.

You can return a Directory with the diff of the changes, like this:

https://github.com/dagger/dagger/blob/b0d27e15843341643954a4e9ef0841cd785b78b3/sdk/python/dev/src/main/__init__.py#L186-L187

_Originally posted by @helderco in https://github.com/dagger/dagger/pull/8112#discussion_r1709402971_

vivid lintelBOT
vivid lintelBOT
#

We've chatted about something like this before - the idea is that we should automagically generate Sync methods for user defined types.

Today, users can kind of fake this by calling id on an object. However, this is really hacky, and additionally with the kind of changes suggested in https://github.com/dagger/dagger/pull/7761 this would no longer be possible.

Instead, we should have a real way of forcing evaluation for a specific user object, by automatically generating Sync metho...

vivid lintelBOT
#

As reported here, in addition to there being an issue with enums in constructors, there's similarly a couple issues with interfaces in constructors.

  • installing module with an interface in the constructor results in following error
Stderr:
Error: failed to generate code: input: moduleSource.withContextDirectory.withDependencies.asModule resolve:
failed to create module: select: failed to update codegen and run...
vivid lintelBOT
#

What This PR Changes

Clearer exception messages whilst developing PHP Modules. Specifically, exceptions for missing typehints.

Current Behaviour

If you create a DaggerFunction, with an argument source, missing a typehint:

[ERROR] Dagger\ValueObject\Type::fromReflection(): Argument #1 ($type) must be 
         of type ReflectionType, null given, called in                          
         /src/sdk/php/dev/sdk/src/ValueObject/Argument.php on line 34

If you cr...

vivid lintelBOT
#

This changes the way you call core functions in the CLI (currently dagger core ):

  • dagger call -c → Core function
  • dagger call -m → Module function

Why?

TL;DR: Consistency.

This relates to:

In that issue there was a lot of discussion on the DX to call core functions from the CLI. In the end, we were left with three main options:

vivid lintelBOT
#

When a module is used as a dependency inside the same git repo, the dependency’s include/exclude patterns aren’t prefixed with the path to that module, relative to the repo root (context directory). When the module is called directly, the prefix is added correctly, which means that the patterns from dependencies

For example, suppose the sdk/python/dev module has the following exclude:

{
  "name": "python-sdk-dev",
  "sdk": "python",
  "exclude": [
    ".venv"
  ]
}
``...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Summary

I propose that asService always executes the entrypoint and default arguments, instead of only as a fallback.

Background

When we were close to releasing v0.12.0, we rushed to revert the "Default exec" because it became very easy to trigger the execution of the entrypoint undesirably, just by ending a dagger call chain in a Container object:

I’s ok if the entrypoint i...

vivid lintelBOT
#

This issue blocks #8124

What Should Happen

When my source directory has formatting errors, if I call:

dagger/sdk/php $ dagger call -m dev format --source=. export --path=.:

  1. The format command begins:
    • The formatter (PHPCBF) returns an exit code 1, because it has to fix formatting errors.
    • The diff is returned.
  2. The directory is then passed into the export command.

What Happens

When my source directory has formatting errors, if I call:

`da...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

So that the Engine image has the matching CLI bundle in & configured to work with the Engine.

This change adds an extra 27MB to the final container image:

  • 466MB before this change
  • 493MB after this change (~6% larger)

FOLLOW-UPs

  • Use a dagger query to test the healthiness of the Engine in the Helm chart (what would make a good default query?)
vivid lintelBOT
#

This was broken from the beginning when user-defined enums were introduced in #7498. ModTypeFor was refactored, and essentially always returned early before the handling of typeDef.Optional. This was incorrect, and meant that we ended up with DynamicOptionals during enum conversion - see https://github.com/dagger/dagger/pull/7498/files#diff-5eb7740241ddbf3efbef98d43f59b2081a4b6f7bfd00a3daba69d36f107d53bbL262-R287.

To resolve this, we can only return early when we've loaded the mod ty...

vivid lintelBOT
#

[!WARNING]

This PR is currently just a test, there's no associated implementation yet!

Thanks @sagikazarmark for the original bug report :tada: (I think this is the same issue? it does have a slightly different error message).

The issue appears to be that the SecretMount.Secret is marked as // +private - if this is removed, the test appears to pass with no issues. I'm guessing that what's happening is that because the field is marked as private, it's not appearing as a f...

vivid lintelBOT
#

We've been using go 1.22 for a while now: #6637. However, this introduced some really interesting features, and we've not really converted any code to use it.

This PR starts using the two main changes in the language from https://go.dev/doc/go1.22:

  • Use range syntax wherever possible
  • Avoid explicit loop capture, this is now the default

Hopefully, after #8150 lands, we can also start using the new func iterators :tada:

#

Spun out of https://github.com/dagger/dagger/pull/8115#discussion_r1716905912

Currently, a default enum value might look something like:

constructor(status: Status = "INACTIVE") {

However, ideally we would express it as:

constructor(status: Status = Status.Inactive) {

Using the actual value of the enum defined.

However, as mentioned by @TomChv, this is a bit tricksy:

I suspect this is because of [main/sdk/typescript/introspector/...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

For example, see this job: https://github.com/dagger/dagger/actions/runs/10404137513/job/28811986035?pr=8158

The job is correctly configured using a dagger token, and tracing is setup - see the top of the job. However, nested CLI calls of dagger still get this message.

We should have some way for the CLI to detect if it's nested, and if it is, disable this tracing message (it makes for more confusing logs and lots of repetition of the message). Also, it's confusing - we are tracing th...

#

If you call dagger call -m ./non-existent, then we continually call find-up, and try and find a module, so for example, if ./dagger.json exists, then we'll load the current directory as a module.

At the moment, this manifests for us as dagger call -m dev ... still continuing to work, and loading the current directory. This isn't quite the right behavior, the find-up behavior is correct, but we should fail explicitly if the path does not exist.

#

Problem

dagger call prints the URL to a full trace (or to traces setup, if logged out). It does so at the top of the output, which is cumbersome in practice. When I want to investigate a problem, usually it's after a fairly large and complex pipeline, so I need to scroll up past a large and complex output. After running a few of these in a row (very common), it's easy to scroll too far, and get lost: "is this the last trace, or the one before"? It adds to the confusion and gets in the...

vivid lintelBOT
#

What are you trying to do?

It would be nice if I could configure a bit of output to look for as a health check for a service, instead of relying solely on whether the port is bound.

For example, Postgres prints database system is ready to accept connections.

Why is this important to you?

Sometimes this is a more foolproof check than just checking if they're listening.

How are you currently working around this?

sleep 30 :cry:

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Adds the ability to override the default command (/bin/sh) when entering in interactive mode when something fails.

Fixes #7974

Note: I added shlex on the command so we can support fancy stuff like: dagger call --interactive --interactive-command='sh -c "apk update && apk add bash && bash"' (for example to setup the debug container with an external script).

Remaining:

  • [ ] adds an integration test
  • [ ] adds a changie entry (feature)
vivid lintelBOT
#

This is supersede #8094, the function is now changed the form from:

@function [
  args: [string_arg: :string],
  return: :string
]
def echo(_self, args) do
  dag()
  |> ...
end

to

defn echo(string_arg: String.t()) :: String.t() do
  dag()
  |> ...
end

The function is now support the type annotation in the function arguments and declare the return type after ::.

The technical behind the scene is the macro called defn , its compile th...

vivid lintelBOT
#

What is the issue?

Let's TypeDef.kind function:

https://github.com/dagger/dagger/blob/a453b63780d5ffb572966beda4d79c3ae3c59ca5/sdk/elixir/lib/dagger/gen/type_def.ex#L96-L102

It have 2 issues:

  1. The Typespec returns incorrect result, it should be {:ok, Dagger.TypeDefKind.t()} instead of Dagger.TypeDefKind.t().
  2. The result return {:ok, scalar_value}, the scalar_value is string not an atom defined in Dagger.TypeDefKind.t().

Dagger version

0.12.5

Steps to ...

vivid lintelBOT
#

Bumps the sdk-python group in /sdk/python/runtime with 2 updates: python and astral-sh/uv.

Updates python from 3.11-slim to 3.12-slim

Updates astral-sh/uv from 0.2.32 to 0.2.37

Release notes
Sourced from astral-sh/uv's releases.

0.2.37
Release Notes
Performance

Avoid cloning requirement for unchanged markers (#6116)

Bug fixes

Fix loading of cached metadata for Git distributions with subdirectories (#6094)

Error messages

Add env var to --link-mod...

vivid lintelBOT
#
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

This is a checkpoint in our attempt to make our Engine & CLI tests reliable & fast. It is meant to:

  • remind us why we are doing this (it's been months with many distractions, it's easy to forget)
  • collect & share observations (we've been doing this ad-hoc, mostly in private contexts)
  • tie other related issues and pull requests

Why are we doing this?

So that the dagger/dagger Engine & CLI test suite shows off the most advanced & polished Dagger use case. We want the most robus...

#

As discussed with @gerhard and it order to improve current CI, I'm making an experimentation by moving the TypeScript tests to its own suite so we can run it independently from other's suites.
The long term idea is to move group of tests into their suites so they can be run into different engine and hopefully remove flakes.

Local CI run: https://dagger.cloud/Quartz/traces/a2c3a4a24346f31efac7dc52f23b6137

I'll try to paralize some tests and see if it can also make it faster.

vivid lintelBOT
#

What is the issue?

Found from #8186. When the sync error, it returns:

%Dagger.Core.QueryError{errors: [%{"extensions" => %{"_type" => "EXEC_ERROR", "cmd" => ["mix", "lint"], "exitCode" => 1, "stderr" => "** (Mix) mix format failed due to --check-formatted.\nThe following files are not formatted:\n\n\e[1m\e[31m/sdk/elixir/lib/dagger.ex\n\e[0m\n 1  1  |defmodule Dagger do\n 2    -|  \n 3    -|\n 4  2  |  @doc \"\"\"\n 5  3  |  Connecting to Dagger.\n       |", "stdout" => ""}, "m...
vivid lintelBOT
vivid lintelBOT
#

Release notes for the cli and engine release are automagically generated by goreleaser - see https://github.com/dagger/dagger/releases/tag/v0.12.5.

However, SDK release notes currently aren't, and require manual steps, see: https://github.com/dagger/dagger/blob/69305c7677cf9a189a483e3378d6c0d0b32f2bbf/RELEASING.md#L413-L415

This PR changes that, and each SDK release step now has a github release generation step :tada:

Note, some manual intervention is still required, since due to lim...

vivid lintelBOT
#

Part of https://github.com/dagger/dagger/issues/8184, and split out of https://github.com/dagger/dagger/pull/8168, since my general approach there turns out to not be possible :cry:

Somehow, we see weird timeouts because calls to the dagger cli aren't properly exiting out: https://dagger.cloud/dagger/traces/da4d9c2d21aef7f3eb8ff0856946c0c1#7e1bbffd12a2fbe1

This is it's own problem, but we shouldn't hang the test while waiting for this, we should actually exit and fail after a timeout.

vivid lintelBOT
vivid lintelBOT
#

Problem

When upgrading Dagger, a new container engine is created (so far so good). Then the older container engine is immediately wiped. This can be very frustrating when one is, for example, switching back and forth between Dagger versions to reproduce an issue. In addition of the overhead of removing and re-creating a container a container each time, it also wipes the cache each time.

Solution

Don't wipe older container engine by default. If there is a legitimate use case for...

vivid lintelBOT
vivid lintelBOT
#

This module compares the schema of any provided remote module between the provided two engine versions.

possible enhancements (that could be done in follow up PRs):

  • allow engine/client from tip of dagger repo (this could be used by other modules in their CI)
  • allow passing this module a list of remote modules and compare the schema for all of them in one go

Also I've added this as a module under modules directory, but it has a dependency on .dagger. I was wondering if better...

vivid lintelBOT
#

What is the issue?

[ERROR] Failed to execute goal io.dagger:dagger-codegen-maven-plugin:1.0.0-SNAPSHOT:codegen (default) on project dagger-java-sdk: Execution default of goal io.dagger:dagger-codegen-maven-plugin:1.0.0-SNAPSHOT:codegen failed: Command sh -c $0 query 2>/dev/null dagger exited with code 1 -> [Help 1]

Dagger version

dagger v0.12.5 (registry.dagger.io/engine:v0.12.5) darwin/arm64

Steps to reproduce

cd sdk/java
./mvnw install

Log output

Java versi...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Fixes #6621, and kind of generally part of #7707.

The idea is to more explicitly break down each SDKs initialization steps - we should only generate the base template in Init. This avoids the annoying implicit generation of main.go when no source files exist.

TODO:

  • [ ] Implement for all the core SDKs
  • [ ] Implement for the community SDKs and/or introduce a fallback if the SDK doesn't define init
  • [ ] Cleanup
vivid lintelBOT
#

What is the issue?

From this snippet:

$ cat main.go
package main

import (
        "dagger/reproduce-bug/internal/dagger"
)

type ReproduceBug struct{}

func (m *ReproduceBug) Containers() []*dagger.Container {
        return []*dagger.Container{
                dag.Container(dagger.ContainerOpts{Platform: "linux/arm64"}).From("alpine:latest"),
                dag.Container(dagger.ContainerOpts{Platform: "linux/amd64"}).From("alpine:latest"),
        }
}

W...

vivid lintelBOT
#

First seen here: https://github.com/dagger/dagger/pull/8196#issuecomment-2301840224

  • We reverted that PR because it for some reason seems to make this more likely to get hit
  • However afaict the race condition that was detected exists independent of the changes that were reverted
WARNING: DATA RACE
Read at 0x00c002eef703 by goroutine 57880:
  testing.(*common).logDepth()
      /usr/lib/go/src/testing/testing.go:1023 +0x504
  testing.(*common).log()
      /usr/lib/go/src/test...
vivid lintelBOT
#

When the dependencies of the PhpSdk update, the PhpSdkDev module does not. This is despite the PhpSdkDev module depending on the PhpSdk:

https://github.com/dagger/dagger/blob/ea6489ef18302593539239174d7198829ef5ff90/sdk/php/dev/composer.json#L15-L18

This is because the PhpSdk isn't a real composer package, it isn't "locked" to a version, it's just copied in from the directory it was generated to:

https://github.com/dagger/dagger/blob/ea6489ef18302593539239174d7198829ef5ff90/sdk/php/d...

vivid lintelBOT
#

See discord conversation: #maintainers message

Hmm the error looks like we changed the telemetry API in a non backwards compat way in the otel refactoring recently
I guess we should have had module compat for this? But we've not had this case before, I hadn't really thought of that telemetry API as "stable" in that way before so missed this

In #7996, the signature of telemetry.Close was changed - however, this bro...

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

Since v0.12.5, the engine fails to start with this error in the logs:

#!/bin/sh
set -e

cat $0

# cgroup v2: enable nesting
# see https://github.com/moby/moby/blob/38805f20f9bcc5e87869d6c79d432b166e1c88b4/hack/dind#L28
if [ -f /sys/fs/cgroup/cgroup.controllers ]; then
	# move the processes from the root group to the /init group,
	# otherwise writing subtree_control fails with EBUSY.
	# An error during moving non-existent process (i.e., "cat") is ignored...
vivid lintelBOT
#

Run a specific suite:

dagger -m .dagger call --source=.:default test specific --pkg="./core/integration" --run="^MySuite$"

New suite after the split

  • TypescriptSuite (Done in https://github.com/dagger/dagger/pull/8185): Execute all module TypeScript tests (run in 8m)
  • PythonSuite: Execute all module Python tests (run in 8m30s)
  • GoSuite: Execute all module Go tests (run in 5m15s)
  • ElixirSuite: Execute all module Elixir tests (run in 2m15s
  • PHPSuite: Execute ...
vivid lintelBOT
vivid lintelBOT
#

I'm curious to hear feedback on this DevX concept. It's a throwback to the Magefile (or Taskfile/Makefile, etc.).

However, instead of maintaining some separate task definitions, the "tasks" are lifted out of the documentation (as long as they are cells "exported" with a name). The description is a cell's preceding paragraph in the markdown AST. Made some minimal edits to the existing .dagger/README.md.

https://github.com/user-attachments/assets/df858c80-6bb3-4508-b9d9-7151319ab911

...

vivid lintelBOT
vivid lintelBOT
#

Our comment parsing code was previously very inflexible, and didn't handle carriage returns in the comment. I originally thought I fixed this in https://github.com/dagger/dagger/pull/7121, but I guess not :cry:

This is because of this helpful little note in go's comment ast struct declaration:

// The Text field contains the comment text without carriage returns (\r) that
// may have been present in the source. Because a comment's end position is
// computed using len(Text), the ...
vivid lintelBOT
#

Since https://github.com/dagger/dagger/pull/6100#issuecomment-1809271407 that using buildctl as the healthcheck for the engine is essentially a no-op. There is an on-going discussion here of what the ideal healthcheck for the engine would be, we haven't yet reached a conclusion but now that we have the dagger CLI in the engine image and the core subcommand we can use something more suitable on our helm chart. I don't think this should be con...

vivid lintelBOT
#

What I did

dagger core directory with-new-file --contents=hello --path=hello.txt terminal

What I expected

An interactive terminal with the contents of the directory mounted.

What I got

● Attaching terminal:
    directory: Directory!
    Directory.withNewFile(contents: "hello", path: "hello.txt"): Directory!

exit 1
Full trace at https://dagger.cloud/dagger/traces/67e61d8bbbd4d7341787b64f75e9c10a

✔ connect 0.8s
✔ initialize 0.2s
✔ ...
vivid lintelBOT
#

This fix comes from accidentally add a leading slash in the generated paths during fix the Elixir issue like this:

modName := "potato" // assume the name is this.
dag.GeneratedCode(directory).
    WithVCSGeneratedPaths([]string{"/src/"+modName+"/lib/mix/tasks/dagger.invoke.ex"})

The .gitattributes produces as:

//src/potato/...

It's happens because the API prepending it without detecting the path that user given. This fixes by dropping it if the path alrea...

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

The service binding is setting 0.0.0.0 in /etc/hosts instead of the correct service address.

Additional notes on the environment:

  • M3 MacBook Air
  • Docker via
$ colima version
colima version 0.6.10
git commit: 12c0c83

runtime: docker
arch: aarch64
client: v27.1.1
server: v27.0.3

$ colima status
INFO[0000] colima is running using QEMU                 
INFO[0000] arch: aarch64                                
INFO[0000] runtime: docker...
vivid lintelBOT
#

What is the issue?

We have created a container using go sdk and trying to export to host machine using Export function but it is not working. Same operation we are doing using cli "export path " it is working fine.

Dagger version

v0.12.5

Steps to reproduce

We have created a container using go sdk and trying to export to host machine using Export function but it is not working. Same operation we are doing using cli "export path " it is working fine. ...

#

Bumps the sdk-python group with 2 updates in the /sdk/python/runtime directory: python and astral-sh/uv.

Updates python from 3.11-slim to 3.12-slim

Updates astral-sh/uv from 0.2.32 to 0.3.3

Release notes
Sourced from astral-sh/uv's releases.

0.3.3
Release Notes
Enhancements

Add uv sync --no-install-project to skip installation of the project (#6538)
Add uv sync --no-install-workspace to skip installation of all workspace members (#6539)
Add uv sync ...

vivid lintelBOT
vivid lintelBOT
#
  • Bump OTel dependencies everywhere so we can get past the sdk/log OnEmit breaking API change (log.Record -> *log.Record).
    • Note: the logging SDK is pre-1.0, so this is somewhat expected, but it's pretty unfortunate that this dependency is floating ahead like this for Go modules. We may need to deliberately pin them.
  • Undoes the telemetry.Close breaking change from #7996
    • Not actually necessary, so not worth the breakage.
#

Problem

In theory Dagger is a perfect fit for code generation (and docs generation) pipelines. But in practice the experience is a little rough:

  1. Caller must explicitly export the generated directory back to the client's filesystem, which is cumbersome. For example dagger call codegen -o .
  2. The target path is relative to the working directory, which means the command must be changed to match the current workdir - this makes the use of Dagger brittle. For example: `cd foo; dagg...
vivid lintelBOT
#

Reorder steps to not list all entries when configuring modules. Move install dependencies step & corepack init before mounting sources.
Add template after initializing dependencies.

It seems that it really improve the cache hit, putting the TS SDK near Go speed when cache hits.

I updated the sources between the 2 runs and we can see that initialize kept being quick! We need more tests but it looks really promising.

vivid lintelBOT
#

Bump graphql-request to 7.1.0 which drop CommonJS supports. This introduce a breaking change for the TS runtime that also needs to drop CommonJS support.

Bump execa to 9.3.1 which requires to bump Bun to v1.1.26 that includes support for underlying engine
call.

⚠️ This PR needs to be merge for v0.13.0 since it introduces some breaking changes (it might not impact users though)

Follow up of #8113.

#

Bumps the sdk-python group with 2 updates in the /sdk/python/runtime directory: python and astral-sh/uv.

Updates python from 3.11-slim to 3.12-slim

Updates astral-sh/uv from 0.2.32 to 0.3.4

Release notes
Sourced from astral-sh/uv's releases.

0.3.4
Release Notes
CLI

Show --editable on the uv add CLI (#6608)
Add --refresh to tool run warning for --with dependencies (#6609)

Bug fixes

Allow per dependency build isolation for setup.py-based projects (#...

vivid lintelBOT
vivid lintelBOT
#

Attempts to fix https://github.com/dagger/dagger/issues/7662, follow-up to https://github.com/dagger/dagger/pull/8051.

I think https://github.com/dagger/dagger/pull/8051 was the right approach - however, the tests weren't the issue. The paths in the tests aren't actually part of the uv cache key, so the underlying issue remains.

The real fix for this needs to be in the python sdk runtime, where we can correctly set these paths - based on the module id (or some other "unique enough" id...

vivid lintelBOT
#

What is the issue?

After a discussion on 'wait for user input' here: https://discord.com/channels/707636530424053791/1277921913058099210

I mentioned some suggestions around scripting or securing the dagger command OUTSIDE of dagger execution. However user input reminded me very much of the terminal() feature. Reading through the dagger documentation, the terminal() is documented to be very much only as a DX for debugging, because in many cases, the terminal() would not be useful...

#

What are you trying to do?

Have better control in place for when a dagger pipeline should execute, similiar to a --dry-run of sorts, however the user must provide a input into a tty before dagger would execute the pipeline function.

Why is this important to you?

CI platforms usually have controls in place prior to pipeline stages being executed. This could be user groups, form values or manual stages that need pressing. With Dagger functions being seen as an alternative or portab...

vivid lintelBOT
#

In this patch, the Elixir SDK look up an extensions from GraphQL error and converting it to ExecError and then translate an error into readable message like Go and TypeScript does.

Consider this function:

defn sample() :: Dagger.Container.t() do
    dag()
    |> Dagger.Client.container()
    |> Dagger.Container.from("alpine:latest")
    |> Dagger.Container.with_exec(~w"foobar")
end

Before this patch, the SDK returns an error that come from inspecting struct, ...