#github-feed
1 messages · Page 11 of 1
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.
Fixes https://github.com/dagger/dagger/issues/7722.
The examples here are not particularly discoverable, and they're also mostly out of date.
As @shykes suggested in #7722, if we miss any of the content, we can bring it back in the cookbook.
Spans that cause non-fatal errors should only appear in the logs if their parent fails out (the encapsulated behavior). Otherwise, they just contribute noise.
See the discord discussion here: #1255153783470821488 message
Github actions doesn't support them :cry:
See https://github.com/openmeterio/openmeter/actions/runs/9572449099/job/26391770769?pr=1031#step:3:2161.
In the raw logs, we can see:
2024-06-18T21:40:49.1751535Z [1mFull trace at [0m]8;;https://dagger.cloud/\https://dagger.cloud/]8;;\ (rotate dagger.cloud token for full url)
We just can't have hyperlinks here, I missed this before.
To merge after https://github.com/dagger/dagger/pull/7293 is released (v0.12).
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.
- This was the autogenerated bump PR (that I later re-used for forward porting several commits from the release branch to main)
- [This was the PR I had to manually create](https://gi...
#7586 introduces breaking changes, and adds features - so this should be changelogged.
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...
- Detect when a query's sole purpose is to get an ID, and just statically return it rather than evaluating each intermediate call
- Look deeply within a query for ID inputs and evaluate them all in parallel
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...
What is the issue?
If you set up a Jenkins pipeline following the instructions in our docs then the trace does not show up in the Dagger Cloud UI home page.
Dagger version
dagger v0.11.9 (registry.dagger.io/engine) linux/amd64
Steps to reproduce
No response
Log output
No response
this commits triggers the quickstart flow when the user which is login
in does not belong to any organization. It'll redirect the user to
Dagger Cloud so the organization creation flow can continue there.
Signed-off-by: Marcos Lilljedahl
- pipelines: harmonize dagger module layout
- pipelines: simplify sub-module paths
- pipelines: move linters/markdown to dev/markdown
Immediate motivation here is to add integ tests for the bug where local cache wasn't getting pruned.
Secondary motivations:
- Setup for CLI commands that show cache state and enable manual pruning
- Setup for the pruning control we'll want as part of https://github.com/dagger/dagger/pull/7646
TODOs:
- Rebase after https://github.com/dagger/dagger/pull/7749 is merged (included here atm)
- Fill in missing API docs
- More tests (ha...
To merge after https://github.com/dagger/dagger/pull/7136 is released (v0.12).
Note: if there's no case of using useEntrypoint, then it can be rebased on top of main and merged earlier.
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
Fixes https://github.com/dagger/dagger/issues/7769.
List of env variables to detect this from is pulled from out own telemetry code:
Attempt to revive #7223, since we've had a lot of perf improvements (especially around otel :tada:)
Hopefully this workflow should run a bit faster now.
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_REFtoGITHUB_REFto get the current state of the PR as resolved by ...
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...
Around here https://github.com/dagger/dagger/blob/main/core/healthcheck.go#L57
Otherwise it can backoff to unreasonable intervals
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...
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...
Experiment to try fixing race condition that seems to have been introduced by https://github.com/dagger/dagger/commit/82b67892fa47038e85f7bf226e25dfedce0aa320.
cf. corresponding trace: https://dagger.cloud/dagger/traces/c71cecd3d42758687c7437e4b7ec98d1?span=1302c9920a784c73
Not sure about my implementation, just an experimentation atm
This was introduced #7532 in, by adding a t.Parallel to these tests. However, the multiple assignment of err has been present from before that.
What is the issue?
I enter the https://dagger.io/dagger-engine page and found that the TypeScript example looks incomplete (missing class, or have extra end bracket, I'm not sure).
Dagger version
dagger v0.11.9
Steps to reproduce
No response
Log output
No response
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...
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:
- If we pin the Wolfi image using a SHA256, what guarantees do we have that this will remain available?
- How do we consume a specific version of Go which is based on the Wolfi base image? The only option that I could find ...
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:
- You import
github.com/dagger/daggerto use dagger specific components, such asengine/cache github.com/dagger/daggerthen importsgithub.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...
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...
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:
Git has support for rewriting URLs, which can be useful for use cases like:
- Enabling a portable URL to be used that is switched based on execution environment (i.e. URL may vary from one machine to another in complex corp environments)
- Enabling the Go toolchain to access private git repos over ssh (...
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...
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.
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...
Bumps the engine group with 6 updates:
| Package | From | To |
|---|---|---|
| github.com/a-h/templ | 0.2.707 |
0.2.731 |
| github.com/charmbracelet/bubbletea | 0.26.5 |
0.26.6 |
| github.com/containernetworking/cni | 1.2.1 |
1.2.2 |
| github.com/docker/cli | 26.1.4+incompatible |
27.0.2+incompatible |
| [github.com... |
Bumps the sdk-typescript group with 17 updates in the /sdk/typescript directory:
| Package | From | To |
|---|---|---|
| @grpc/grpc-js | 1.10.9 |
1.10.10 |
| @opentelemetry/exporter-trace-otlp-grpc | 0.52.0 |
0.52.1 |
| @opentelemetry/sdk-metrics | 1.25.0 |
1.25.1 |
| [@opentelemetry/sdk-node](https://github.com/open-telemetry/open... |
Bumps the sdk-python group in /sdk/python with 7 updates:
| Package | From | To |
|---|---|---|
| docutils | 0.20.1 |
0.21.2 |
| googleapis-common-protos | 1.63.1 |
1.63.2 |
| importlib-metadata | 7.1.0 |
8.0.0 |
| mypy | 1.10.0 |
1.10.1 |
| protobuf | ... |
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...
Signed-off-by: Marcos Lilljedahl
This fixes docs-305, add a template that is easy to copy when making a new integrations page, or to reference when editing an existing one.
Description
The cache manager leverages a check, provided by the cache service, to prevent pushing layers that were previously pushed. In this PR we implement the same behavior for cache mounts. If the cache mount already exists we skip pushing it.
This will significantly reduce the time it takes to shut down an engine for orgs that have a high number of cache volumes, like ourselves.
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!
...
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...
FINALLY fixes https://github.com/dagger/dagger/issues/6747
This builds on top of all the recent refactoring and:
- Fills existing holes in secret isolation (unskips test that was previously skipped that covers this isolation)
- Isolates sockets per-client
- 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...
This commit changes the CLI so it prints a custom Dagger Cloud trace URL
when the user is not logged in or no DAGGER_CLOUD_TOKEN has been set.
Additionally, a custom message gets printed at the end of dagger init
and fro any commands that the user supplied the -v or --debug flags.
Fixes DEV-4269 DEV-4268
Signed-off-by: Marcos Lilljedahl
This is a follow-up to #7766
Add link to module and resources
Want to pick up change that enables retrieving the vertex description (and thus ExecutionMetadata for Dagger) from solve errors, to help cleanup interactive debug containers.
(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 ...
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...
(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...
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.
What happened? What did you expect to happen?
I use dagger with python. Dependencies are managed by poetry. There is a certain library I want to use in my dagger pipeline, but no matter what I try, nothing seems to work. Any ideas?
In every sync functions, load the new state using load from id function to return a type itself.
This updates #7788 since it's a fix only Elixir SDK.
When set secret source with file:~/path..., the engine will expand ~ to $HOME automatically.
Possibly fixes, or at least helps, https://github.com/dagger/dagger/issues/7786 by avoiding https://github.com/actions/runner/issues/1031
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...
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...
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
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 ...
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 ...
mostly doing this since the results currently returned by the query
are not properly organized and curated.
Signed-off-by: Marcos Lilljedahl
@jedevc raised an issue happening sometime in the TS test, it seems the 6000ms timeout isn't correctly applied for multi tests cases.
This PR aims to fix that by adding the timeout to every specific cases.
commit f8849688129535ad6c2183d6cc7ddfd4f2319691 was accidentally
overriden by an unrebased PR. Bringint it back in.
Signed-off-by: Marcos Lilljedahl
Verbosity adjustments + a couple of tweaks to align the TUI with Cloud.
-vexpands completed items;-vvand-vvvnow same as before- use "active duration" (including effects) to calcualte span duration
- hide primary output on error (same as Cloud)
:warning: Based on https://github.com/dagger/dagger/pull/7759.
Completes the work from https://github.com/dagger/dagger/pull/6680 by removing the aliases, which were really tricky to work with from a code completion perspective.
By using #7759, we can avoid breaking the daggerverse, and just apply this for v0.12 and after.
[dagger/dagger] Issue opened: #7832 ✨ Apply ignore patterns from Directory argument in `dagger call`
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 ...
This PR sets two basic Jenkins labels when the engine runs in a Jenkins context.
This is needed to complement missing Git metadata when case Jenkins runs without an explicitly checked-out repository when running a pipeline.
For more context on this see #7776
Caveats
- As opposed to the other package functions such as
WithGitHubLabels, we cannot look up aJENKINS=trueenv vari...
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.jsonbut nopyproject.tomlfile (TS haspackage.json, but in certain situations Go m...
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...
Bumps the engine group with 23 updates:
| Package | From | To |
|---|---|---|
| github.com/a-h/templ | 0.2.731 |
0.2.747 |
| github.com/containerd/containerd | 1.7.18 |
1.7.19 |
| github.com/gofrs/flock | 0.11.0 |
0.12.0 |
| github.com/goproxy/goproxy | 0.17.0 |
0.17.1 |
| [github.com/moby/buildkit](https://github.com/moby/b... |
Bumps the sdk-typescript group with 17 updates in the /sdk/typescript directory:
| Package | From | To |
|---|---|---|
| @grpc/grpc-js | 1.10.9 |
1.10.10 |
| @opentelemetry/exporter-trace-otlp-grpc | 0.52.0 |
0.52.1 |
| @opentelemetry/sdk-metrics | 1.25.0 |
1.25.1 |
| [@opentelemetry/sdk-node](https://github.com/open-telemetry/open... |
Bumps the sdk-go group in /sdk/go with 9 updates:
| Package | From | To |
|---|---|---|
| go.opentelemetry.io/otel | 1.27.0 |
1.28.0 |
| go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp | 0.3.0 |
0.4.0 |
| go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc | 1.27.0 |
1.28.0 |
| [go.opentelem... |
Bumps the sdk-python group with 8 updates in the /sdk/python directory:
| Package | From | To |
|---|---|---|
| certifi | 2024.6.2 |
2024.7.4 |
| docutils | 0.20.1 |
0.21.2 |
| googleapis-common-protos | 1.63.1 |
1.63.2 |
| importlib-metadata | 7.1.0 |
8.0.0 |
| [mypy](https://github.com... |
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 hadengineVersion)
Some fields in introspection json are not guarantee to present when it's optional. It cause the codegen crash because it expected those fields to have it. Fixed by make it optional by getting it via [key] instead.
And in this fix, include update outdated snapshot tests.
[!NOTE]
This is a work in progress
The __schemaVersion is now included in introspection.json file but it didn't get update in tests. Cause test TestIntrospection failure.
Otherwise the exponential backoff can keep going indefinitely and wait too long.
The previous logic had a few inconsistencies:
- It returned exit errors after stop was called, but other services didn't
- It read exit errors from a chan every time, which caused unneeded timeouts waiting for the chan in the case where stop gets called multiple times.
fixes #7433
We'll need to bump to v22 in October 2024
Based on multiples Discord message, we cannot ignore this dependency issue anymore, I'm fixing this now so we do not hit this issue anymore.
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",...
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...
So that there is no extra mental hop between the chart version and the Dagger Engine version. We do the same for all other artefacts that we release.
This also adds changie for the Helm chart & automates the version bump.
Resolves #7597
What happened? What did you expect to happen?
Dagger is currently using Node 21, which is breaking my pipeline because certain packages only support LTS versions of Node. This should get resolved by https://github.com/dagger/dagger/issues/7433, whenever that releases, but is there a workaround in the mean time? My CI/CD pipelines are failing due to this.
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
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...
What is the issue?
https://dagger.io/integrations
- Argo
- Github
- Gitlab
- Jenkins
- Circle
- Google Cloud Run
all end up with a "page not found"
PS: this might not be the place, but no idea where you'd like this reported
Dagger version
Steps to reproduce
No response
Log output
No response
@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).
- related discord thread: #1260319690002141286 message
This turned out to be due to the fact that dumb-init, by defau...
This PR splits our Engine & CLI tests into:
- Module tests
- 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...
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...
Follow-up to:
Currently, as we are pre-1.0, we require strict userEngineVersion >= moduleEngineVersion during compatibility checks.
Post-1.0, this should be relaxed to allow drift at the patch level, following semver.
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 ...
Previously the -m help suggested that you could point to the dagger.json file, but we expect a path the the directory containing that file. This PR fixes that.
From the context of the documentation I believe this is the right file to reference post-refactor (https://github.com/dagger/dagger/pull/7483).
Please let me know if you need anything else.
this commit introduces the following changes:
- Keystroke for web visualization is now
wfor both logged-in and
logged-out clients. - New
--webglobal 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.
- logged in: URL gets printed at the top honoring -q and -s
Signed-off-by: Marcos Lilljedahl
In some situations the c: Cloud key will work but dump a bunch of diagnostic output directly to os.Stderr in the process which breaks the TUI.
Now we'll buffer that output and only show it if opening the browser fails.
Right now the dev shell sample returns a container, adding terminal makes this a one liner that someone can use to actually get into a shell.
This makes our pipelines slightly more efficient.
Signed-off-by: Solomon Hykes
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 ...
Signed-off-by: Solomon Hykes
- pipelines: spin out a golangci module for linting Go code
- pipelines: streamline dagger codegen
- pipelines: remove utils.DiffDirectory in favor of dirdiff module
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...
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.
Notable improvements
- Experimental support for
uv.lockfor project management. 🎉 - Install uv from OCI image for better parallelization. 🚀
- Don’t install dependencies during
dagger developto avoid a catch 22 situation where you need an updatedsdkdir to update the lock but you can’tdagger developbecause 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...
Previously we would just show initialize with nothing beneath it except for a ton of spam.
Now we'll show 3 steps beneath it which hopefully let the user know a bit more about what's going on:
e.g. early/local failure like dagger login without selected org
without this, dagger login (no org) can fail silently:
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...
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...
Some cherry-picks and pieces from #7858, since that one has some issues, and is risky!
Specifically:
- Fix the process of updating a
dagger.jsonduringdagger develop(this was broken before, and now has some tests as well) - The engine should serve the CLI the API that it's
clientVersionindicates it has - this isn't super useful right now, but is quite nice in the context of #7858.
Fixes https://github.com/dagger/dagger/issues/7762
Current implementation of parseRefString does not allow local refs to have @, as it considers this character as the module version separator
However, this is not supposed to be true for local refs, to which the notion of version is not relevant
- Update our integration template to make things more consistent
- Update Jenkins example to allow anyone to run it as is without needing to worry about having a specific type of project
- 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
Expand the "Adopting Dagger" page with a framework for successful adoption.
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...
since there seem to be cases that the progress report don't cover
will bring this back along with more robust TUI error handling
Did some hand editing in this case:
- Added a few missing breaking API changes (don't return void + use
@funcinstead of@field) - Wrote an extra section under
Breaking Changeswith some more details on the new compat mode and how to upgrade modules viadagger develop - 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...
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 ...
Did some hand editing in this case:
- Added a few missing breaking API changes (don't return void + use
@funcinstead of@field) - Wrote an extra section under
Breaking Changeswith some more details on the new compat mode and how to upgrade modules viadagger develop - Reordered some of the entries to match the blog post + small misc formatting fixes
- Added a breaking changelog about the Go SDK alias removal
- In our current system, this only showed up in the Go SDK rele...
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...
Follow up from #7889
We should also serve generalized nested clients the right client API - and then have tests for this.
Specifically, go and alpine. Both of these have some security fixes, which would be good to get in.
Also, go is good as well, since then we can handle parsing go 1.22.5 directives.
This PR was not auto-generated.
cc @gerhard https://github.com/dagger/dagger/actions/runs/9909287007/job/27377007275#step:11:518
Continuing from:
TODO:
- [ ] Re-test printing objects with properly tagged cli (had issues with dev due to daggerverse dependencies)
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...
- Removes
checkVersionCompatibilitycall (via Bass bumping its Dagger dependency to v0.12) - Fixes Bass SDK telemetry (previously you'd just see nothing)
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...
I am taking this gem that @jed shared in discord the other day and adding it to a FAQ entry since this is a common question that we hear.
What is the issue?
This was reported by Nipuna in discord[1]
The terminal command seems to kick into "pre" terminal mode before the from image is pulled. So while the image is being pulled the TUI freezes on my screen.
I expected to have access to the TUI until at least the image for the corresponding container is pulled so I can watch that progress and know that it's being pulled. Pulling a large image can take time and it feels like everything is frozen while it does.
[1] ht...
What 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 ...
[dagger/dagger] Issue opened: #7914 🐞 `dagger version` inconsistent behavior (disappears) in v0.12.0
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
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:
- `WithExec([]string{"show", "...
What is the issue?
It looks like this change introduced a v in front of the the fallback default appVersion.
As the appVersion is already prefix with a v that deamonset tries to use registry.dagger.io/engine:vv0.12.0
Dagger version
v0.12.0
Steps to reproduce
https://docs.dagger.io/integrations/kubernetes
Log ou...
Fixes #7916 (which is a regression from #7854), follow-up to #7906
We should ensure that both fields are semver, and have no "v" prefix - then we can add the v prefix ourselves in the templated code.
If you start with an empty directory and git init you'll end up with a .git/ dir.
If you run dagger init --sdk typescript, for example, you'll get this:
dv ➤ dagger init --sdk typescript git:main
2024/07/14 09:49:41 WARN failed to get repo HEAD err="reference not found"
...
Fixes #7914 (thanks @nipuna-perera!)
We were avoiding direct use of Stdout/Stderr pretty well, however, not for dagger version. If we write directly to it, it has the potential to overlap with the TUI, which can cause the output to be weirdly cleared.
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).
What is the issue?
https://github.com/dagger/dagger/pull/7498 has been merged and released for 0.12, now we need to add some docs :D
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...
[dagger/dagger] Pull request opened: #7925 docker driver: log more details about engine image lookup
This helps troubleshoot especially in the case of slow internet connections, where this codepath has a massive cost. It's typical for dagger call to be slowed down by 30 seconds on slow internet connections, even with nothing new to download (latest engine already downloaded).
Signed-off-by: Solomon Hykes
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...
This is #6868 but for Elixir, when found any function that return Void, instead of return {:ok, Void}, return just only :ok atom.
This requires #7667 to be complete first because this PR may break the runtime due to return_value return type change.
In https://github.com/dagger/dagger/commit/3bedee341e04a8d92a8c9161e6e72a8ad19e1170 we introduced a change that breaks the chart when installing it since it tries to create a label of v"0.12.0" which is not a valid value:
We don't need to apply the quote in this case, it will be treated as a string. With the fix I can install it successfully:
, it generated a dagger Go module:
$ tree dagger
dagger
├── .gitattributes
├── .gitignore
├── dagger.gen.go
├── go.mod
├── go.sum
├── internal
│ ├── dagger
│ │ └── dagger.gen.go
│ ├── querybuild...
@marcosnils Accidentally didn't push this change for #7932. I blame the power outage. :man_facepalming:
Thought of a potentially even simpler fix to https://github.com/dagger/dagger/issues/7900 than what I described in the most recent comment there: just set the hostname of nested clients to a digest of their call.
There's various tradeoffs of this approach, which I'll describe if I go with it, but sending out early to get make sure it deflakes in CI too and doesn't break something else.
This commit is a breaking change on decorators.
It removes the experimentalDecorators setting in the tsconfig.json to use the official released.
This changes the prototypes of decorators to now take the target and the context as argument.
This commit also updates the generated template and has a script to update existing tsconfig.
Fixes #7499
These example had issues due to a change in the Dagger CI modules layout and an older dependency. Changed to using ruff module instead. Otherwise, very similar.
Signed-off-by: Solomon Hykes
Followup to https://github.com/dagger/dagger/pull/7933 (cc @vito)
If a single workflow run contains multiple dev-engine jobs, then uploading the artifacts will fail. To do this, we can make them unique using the runner name.
See the failing job on main: https://github.com/dagger/dagger/actions/runs/9970998498/job/27551091011#step:3:5005
We removed this last minute in https://github.com/dagger/dagger/pull/7759/#discussion_r1668419158.
However, it does seem like we need something here - so proposing this back in. Let the bikeshedding of naming/etc begin, I don't have particularly strong opinions here :tada:
Follow-up to https://github.com/dagger/dagger/pull/7939
We need to use the entrypoint explicitly here, see https://github.com/dagger/dagger/actions/runs/9971938618/job/27554089721#step:8:453
Noticed in https://github.com/dagger/dagger/pull/7872#discussion_r1680759963
There are two issues:
- Some errors have an empty "Severity" - not entirely sure why, but some of the code was handling this correctly, but Assert wasn't.
- The
GOLANGCI_LINT_CONFIGdoesn't seem to have been being respected, I can't find any reference to it. So we can just use the suggested use of from the docs.
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 inargs)withFile,withNewFile,withDirectory,withoutDirectory,withoutFile,withMountedXXX... (expand variables inpath)
I have personally needed this argument in withExec and withNewFile
Ruff is a single binary that doesn't need Python to install or even use.
It has a docker image which is the best way to install it with Dagger.
Used a Dockerfile so that dependabot can help keep it up to date.
Problem
- When
Container.withExecis 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
withExecspan is an improvement, but it's not enough - By showing to the user a
withExecspan and a separateexecspan, ...
After applying #7904, we've seen jobs hang weirdly.
See an example:
- https://github.com/dagger/dagger/actions/runs/9970573229/job/27549768418?pr=7936#step:3:89
- https://dagger.cloud/dagger/traces/6573dc5045a64c4d4e20b7e8b521b76a
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...
These were previously able to overlap / end multiple times, which is confusing. This was introduced in #7881 in v0.12.0.
Maybe this isn't the cause of all the weird failures in https://github.com/dagger/dagger/issues/7954, but this isn't quite right.
The resolveSpan could be ended multiple times.
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...
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.
###...
As mentioned :tada: :tada:
@vito I'm sure you'll love this, but also now, I want the vim fold operators :laughing: zo, zc, all that.
We no longer have a website dir since:
It's been merged into docs.
When getting a terminal in Debian based containers, the working directory does not show up correctly:
This is especially visible when using non alpine golang or debian images.
To reproduce simply do dag.Container().From("golang").Terminal()
This change in PS1 does not use parameter expansion but pwd and sed to replicate the same behavior.
Problem
If I call dagger -m ./foo functions, and ./foo doesn't exist, Dagger fails to let me know, and loads the current module instead.
Updates our special telemetry-only token to use the new format, so we don't get constantly prompted to rotate our creds.
Thanks @marcosnils for the token :tada:
I'm playing around PowerShell script and found that they have a tool called PSScriptAnalyzer to lint and format the PowerShell script. So I do some a quick hack to daggerize it and share it to you all to asking for opinion.
Demo
Checking the install.ps1
$ dagger call -m ./dev/ps-analyzer check --file=./install.ps1 issues
- _type: PsAnalyzerIssue
code: 0
column: 13
columnE...
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...
This is a quick band-aid; we're seeing draining issues again, possibly as a result of c712183 (#7735). My guess is we were relying on the child-abandoning code path (as evil as it sounds) even in the happy path, and something is causing these spans to never complete:
[dagger/dagger] Pull request opened: #7967 docs: fix typescript snippets in Entrypoint Function page
There's no need to introduce @func in object properties here since it hasn't been introduced yet.
Only added confusion because it appears it's needed for the constructor.
I got some great additional feedback from Marcos after we merged #7892 so I am adding these in here now.
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...
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)
The contents of this were moved into dev/
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:
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/TestInsecureRootCapabilitesWithServicedoes docker network access, and so should be given the host's docker config if it can be found.TestModuleDevelopVersionhas some duplication withTestModuleSchemaVersion- we can remove those, since all the permutations are tricky to handle in the develop test.
A bunch of the SDK dev tests fail because different steps try to upload the dev engine logs but get an error since the logs artifact already exists.
I think that setting overwrite to true will avoid this, but can't know until I merge.
Example of failures: https://github.com/dagger/dagger/actions/runs/9997156850/job/27633082976
Same as v0.12.0, need to manually create this since the automated bump engine PR hits permission issues:
- Last manually created PR: https://github.com/dagger/dagger/pull/7903
- Permission error during publish: https://github.com/dagger/dagger/actions/runs/9998101150/job/27636218600#step:11:526
Following RELEASING.md, so need to open as draft to get PR number, make a few more updates and then push.
Started seeing this one a bunch recently:
- Cloud trace: https://dagger.cloud/dagger/traces/ce4f383ede89e9bf39d00fe89aacd444?span=087b98784bf05440#909ebe7a106b977f
- GHA job: https://github.com/dagger/dagger/actions/runs/9998434018/job/27637312803?pr=7978
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 ...
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...
[dagger/dagger] Pull request opened: #7981 Change default module source directory from ./dagger to .
- Change default module source directory from ./dagger to .
- dagger init: simplify usage message
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...
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 developbefore the instructions on updatingdev/with go mod edit/tidy fully work. Was an issue this time because I had recently rungit clean, which resulted in errors - We really need to fix the permissions issue with the bump engine PR...
v0.12 adds support for Git servers beyond Github. Updating docs to reflect this new capability.
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 ...
Use custom spans to make traces more readable
Signed-off-by: Solomon Hykes
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, ...
What happened? What did you expect to happen?
We tried to load Dagger module from our private Github repository but failed. We'd like to know whether this capability supported now? Or is there any plan to support this in the future?
Replaces the live one-shot pub/sub approach with saving telemetry to a per-client database.
Could maybe use this per-client database for more things in the future. It's kinda neat.
- [ ] delete more
PubSubcode - [ ] fix logs
- [ ] figure out nested clients
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...
What is the issue?
When working on Python pipelines with Dagger, I frequently reference the SDK's documentation, and it's a very helpful resource. During my work, I discovered the dagger.Host object and the dagger.Client.host method, which suggested that these ...
What is the issue?
Reported by Mike, in Discord.
When calling a Dagger Function with an enum as a parameter's default value, omitting its flag returns an error.
Using --debug I can confirm that the CLI is sending an empty string to the API:
# dagger call test-func
{
enumDefault {
testFunc(env: "")
}
}
Dagger version
dagger v0.12.1 (registry.dagger.io/engine) darwin/...
A silly var capture issue. :grimacing:
Fortunately the command itself still fails, so everyone's CI should be doing the right thing, but traces and GitHub checks currently never fail.
Went for minimal changes here to maintain correctness. I think each of these makes sense in context but could use a double check.
Also remove requirements.txt since it's a zombie at this point (just points to a file that was rm'd).
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...
Manually wrote the notes for #8001, and reworded the note for #7824
This PR was auto-generated.
Not sure what's supposed to do this normally, but it was missed during the release process.
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...
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
...
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...
So that we can reference it in our runs-on CI runner configurations.
Setting DAGGER_COMMIT=head will pull the latest CLI built from main. We are not templating the branch name on purpose. When we introduce release branches, we should revisit this. For now, we are keeping this as simple as possible for as long as possible.
[!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")...
See the raw trace from a basic container-echo call:
Note, the remotes.docker.resolver.HTTPRequest spans should be attached to the Container.From span - however, these are from lazyRefProvider, and so are only pulled on-demand, by CalcSlowCache's PreprocessFunc.
Buildkit had a very similar looking issue in https://github.com/moby/buildkit/issues/1755 - now, for some reason... this doe...
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 moduleunderinitializing. - 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...
A while ago in Discord, a user expected that dagger call exited with the same exit code of the test suite tool they were using in the function. I thought why not, and it's easy to add.
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: ...
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...
The existing dev module documentation instructs developers to run a test which doesn't exist. This PR updates the example to point at the renamed test, with the added side benefit of making it clear that many core/integration tests are subtests.
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...
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...
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:
- https://github.com/moby/buildkit/compare/981d4fcf403df4d7a43934aea68f0d5bf4c7b3e9...ffadc9ff1531c8573e8522b03611833811f4abdf
- Function signature of
session.NewSessionhas changed, thenameparameter was unused
Containerd update:
- https://github.com/containerd/containerd/compare/v1.7.18...v1.7.20
github.com/containerd/containerd/platformshas been moved intogithub.com/containerd/platforms-
github.com/containerd/containerd/errdefshas been moved into...
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...
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...
I saw this flake on main (Traces) and got very sad since it was in TestLegacy which should have been fixed.
But this flake appears to be distinct from the old one, even though part of the error message is the same:
- The mismatch in files occurs in
TestLegacyExportAbsolutePathand crucially ...
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 ...
This adds more visibility to debug:
Related:
I've run the PRs above multiple times now, and never hit the flake in the PRs. Now I suggest commiting this one to main, to cover more ground.
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...
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...
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...
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
HEALTHCHECKdocker/oci directive- D...
This PR was auto-generated.
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...
Dagger Cloud is only mentioned at the start of the quickstart, so added an reminder at the end.
- Main Dagger module is now github.com/dagger/dagger
- Sub-modules moved to the root of the repo
- The rest is in .dagger
- FIXME: had to (temporarily) uninstall sdk/python/dev, because of a mysterious error
Signed-off-by: Solomon Hykes
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
...
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...
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...
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)...
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...
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
privateboolean flag todagger.json dagger init --privatesets the flag- Daggerverse honors the flag by hiding (partially or totally) private modules in search results
dagger installreturns an error o...
The use case of:
- Building Dockerfiles via the
Container.buildorDirectory.dockerBuildAPIs - That have secrets attached
- That were created by modules and returned as
Containervalues
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...
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...
This seems to have been accidentally added when removing go aliases (https://github.com/dagger/dagger/pull/7831/files#diff-9071102708f2192ab3f79607ad8aa444993a76461970710294b407e9db34289cR397-R399)
That was a mistake, and it shouldn't be there.
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
Makes it easier to manage, and brings back codegen's tests into CI.
Includes dependency updates.
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 ...
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 ...
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 ...
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
- Have a wsl2 + podman >= 5.1.2 setup
- Perform a
dagger init --sdk $sdkon an already existing project
Log output
! failed to export: rpc error: code = Canceled des...
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...
These values are commonly known, so don't need to be secrets.
They should be accessible from a PR context, and also shouldn't be censored in the logs.
Fixes the following flake:
- Github actions: https://github.com/dagger/dagger/actions/runs/10149286653/job/28063879193
- Dagger trace: https://dagger.cloud/dagger/traces/3081ce038ac6bdc1af29ca8b3925a226
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...
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:
repoRootForImportPathdoes work well on refs leading to a repo, infering properly the vcs provider used- But,
go-get=1returns a 500 when a subpath is included - 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...
These have been no-ops since https://github.com/dagger/dagger/pull/6835:
The
pipeline()APIs are now no-ops.
This PR:
- Removes our own usage of
pipeline()from our tests - Removes the unused
core/pipelinepackage which was no longer being used - Deprecates the
pipeline()APIs to remove in v0.13.0
v0.13.0 allows for breaking API changes (as long as we use the versioning compat views to keep old modules working).
So we can remove the following APIs:
pipeline()APIs, deprecated in https://github.com/dagger/dagger/pull/8064
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.
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 ...
We want to mirror the setup we have for SDK checks + test all but with dev-engines. This means making the current dind runners be shared and adding a new dind single tenant on-demand runner for testdev.
What is the issue?
The new enum support in 0.12 is great, but there is no mention of it that I can find in our docs.
https://dagger.io/blog/dagger-0-12
We should add this to the dev manual and also show a usage example
Fixes the failing publish job on main: https://github.com/dagger/dagger/actions/runs/10196735570/job/28208078629 (introduced by merging #7858)
We need to strip the newline at the end, otherwise we end up with the trailing tee on a line by itself (which isn't what we want).
This isn't visibile to the user until we solve:
This is an historical feature from early days if Modules development. We hid it before the Modules launch, so it was never documented. The important thing here is just the announcement and the change log, to give a heads up that it will be removed.
When publishing commits, the Tag field will be set to a commit. We should check using git to see if the tag actually exists, and if not, set the dummy release version.
Properly unset the tag, so that we don't attempt to generate release notes for a nightly release.
Note! This is using our new process detailed in https://github.com/dagger/dagger/pull/7705.
This means that there will be no bump-engine PR later. So we need to update all of our changelogs, and do the versioning bump here now.
- [x] Add a module under sdk/php/dev, using the PHP SDK, to test the PHP SDK.
- [x] Fix previous refactoring oversight left in existing unit test.
- [x] Implement
unit-testfunction to run unit tests only - [ ] Implement
integration-testfunction to run integration tests only - [ ] Implement
testsfunction to provide output from both unit and integration tests.
[!WARNING]
The v0.11.4 release has not been made yet.
This can help manually check that it's all correctly working and everything :tada:
See https://github.com/Homebrew/homebrew-core/pull/179252#discussion_r1700461628 for the context for this.
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 ...
Add Netlify publishing steps for doc deploys
It has been a while, releasing 0.11.9, with included breaking changes to the rust sdk api
fix layout: The file and contents example was not indented enough so its was not fitting the codepreview box.
What are you trying to do?
Make use of OpenTelemetry in PHP SDK runtime so we can get real-time feedback as opposed receiving all output only once complete.
Why is this important to you?
No response
How are you currently working around this?
No response
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?
Add support for custom interfaces in runtime.
Why is this important to you?
Allows for a better layer of abstraction than simply relying on custom objects.
How are you currently working around this?
Using custom objects
What are you trying to do?
Remove the following deprecations:
sdk/php/src/Connection/CliDownloader.phpsdk/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.
...
[dagger/dagger] Pull request opened: #8094 💥feat(sdk/elixir): rework on api for declaring a function
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.Modname 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...
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 ...
WIP: Had this in stash for a while, just putting it out there.
Subtle reordering and addition of a needed --force make these instructions better for releasing dagger-for-github.
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...
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:...
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:
- Make
Dagger.Core.Client.executeAPI be consistent with theDagger.Core.Client.queryfunction. - `Dagger.Core.QueryBuilder.Selecti...
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...
- Part of https://github.com/dagger/dagger/issues/6749
- Fixes https://github.com/dagger/dagger/issues/6964
[!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
This is a workaroud until the following is fixed:
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...
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 ...
[!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...
What are you trying to do?
Pass a duration value to a function using Go's native time.Duration type.
Why is this important to you?
Currently I have to use a string and manually parse it into duration which is cumbersome.
How are you currently working around this?
I use a string and manually parse it into duration.
Add PHP Code Sniffer
- Configured to lint against standards: PSR1 and PSR12
Can be called through the PhpSdkDev.Lint
Added to to Dev module in the same way as Python's Linting works.
execa will have to wait for bun@v1.1.22 since https://github.com/oven-sh/bun/issues/11716 has been merge.
Reported by @sagikazarmark in [Discord](#go message).
Enum doesn't work in constructors:
Error: make request: input: failed to get schema: failed to get schema for module "test": failed to install constructor: failed to create function: failed to find mod type for function "" arg "status" type
See failing tests. Affects all SDKs, the problem is in core (modfunc).
This will help avoid issues like https://github.com/dagger/dagger/issues/7916 in the future - this took a lot of messing around to fix, so it would be good to never hit this again.
What is the issue?
If in a dagger function you try to return a source Directory your computer will crash
Dagger version
0.11.7
Steps to reproduce
package main
import ()
type Test struct{}
func (m *Test) BuildDist(source *Directory) *Directory {
return source
}
Log output
No logs but ram is going more than 32GO of ram (my max ram)
@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 ...
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...
This fixes the hyper inflated test runtimes due to tests actually blocking on t.Parallel.
This use case actually perfectly aligns with the cause/effect system built to handle async Buildkit work. But, Cloud needs more changes to fully support and properly represent it, which is WIP.
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:
- We can customize the behavior as per our requirement
- If needed, we can easily replace the backing library in future.
- Add unit test coverage as this transformation is critical for dagger codegen and graph functionalit...
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 ...
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:
_Originally posted by @helderco in https://github.com/dagger/dagger/pull/8112#discussion_r1709402971_
Delegate codegen to /sdk/php/dev, then we don't need the duplicated base in /dev/sdk_php.go anymore. 🙂
_Originally posted by @helderco in https://github.com/dagger/dagger/pull/8112#pullrequestreview-2221860777_
The snippets indicate @v5 but the latest is now @v6.
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...
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...
When merging the new linting steps, I forgot to rebase and regenerate :(
This fixes the failing job on main: https://github.com/dagger/dagger/actions/runs/10316831631/job/28559856006
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...
This changes the way you call core functions in the CLI (currently dagger core ):
dagger call -c→ Core functiondagger 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:
dagger core→ Merged in https://github.com/dagger/dagger/pull/7310- `dagger ca...
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"
]
}
``...
Add mention of the required documentation step for our GitHub Actions release. See https://github.com/dagger/dagger/pull/8131 for past example.
Add Diego Ciangottini's community demo to Kubernetes integration page
Transition PHP integration page to the new integration template and add community call demo
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...
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=.:
- The
formatcommand begins:- The formatter (PHPCBF) returns an exit code 1, because it has to fix formatting errors.
- The
diffis returned.
- The directory is then passed into the export command.
What Happens
When my source directory has formatting errors, if I call:
`da...
See https://github.com/moby/moby/releases/tag/v27.1.1.
This release contains a fix for CVE-2024-41110 / GHSA-v23v-6jw2-98fq
that impacted setups using authorization plugins (AuthZ)
for access control. No other changes are included in this release, and this
release is otherwise identical ...
The other SDKs are all consistent in their naming of their autogenerated example methods - PHP should be the same.
What is the issue?
Following #7864 & #7852, the docs page https://docs.dagger.io/manuals/developer/typescript/356352/runtime/#nodejs should be improved to include this new capabilities on the TS SDK.
I think I'll also create a page Alternative Package Manager for the specific package.
What are you trying to do?
Of the 3 main sdks the typescript one doesn't allow for overriding the base image. Go doesn't need it and python has the discovery. Typescript should support similar functionality to the python sdk.
Similar to the python we could put the image override in the config section of the package.json
Why is this important to you?
- I want t...
So that the Engine image has the matching CLI bundle in & configured to work with the Engine.
- It addresses the primary issues raised in https://github.com/dagger/dagger/issues/6887
This change adds an extra 27MB to the final container image:
466MBbefore this change493MBafter this change (~6% larger)
FOLLOW-UPs
- Use a
dagger queryto test the healthiness of the Engine in the Helm chart (what would make a good default query?)- Tie this to https://github.com/da...
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...
[!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...
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
rangesyntax 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/...
Fixes an issue raised by @marcosnils when using dagger ts SDK inside a ts repo that has a package.json at its root.
Originally reported in discord by @matipan and @marcosnils: #maintainers message
The below code does not work:
package main
import (
"dagger/foo/internal/dagger"
"fmt"
)
type Foo struct{}
func (m *Foo) Hello() *dagger.Container {
return dag.Container().
From("ubuntu").
WithWorkdir("/home/ubuntu").
WithExec([]string{"sh", "-c", "apt update && apt install -y git-core curl"}).
WithExec([]...
Add assurance for the amount of time it takes to daggerize, and link to livestream examples.
This is the node_modules equivalent for pnpm - we should never export it, just in our tests these can end up at 100MB, which causes our exports to sometimes hang.
:thinking: Somehow, this is failing locally, but not in CI.
this PR also needs #8122, so marking it as draft PR until that is merged
update the to_pascal_case function to also replace . with _.
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...
Need to bring back the brokenness so I can demo debugging it
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:
Includes:
- Attempt to kill misbehaving subprocesses in
TestDaggerUpand similar harder, see https://dagger.cloud/dagger/traces/3e12c1a3aa6b40119ab74e136dad9e50?span=1e20b5449908ff06#0f8f4e636ab28886:L198 testctx.Tshould have a way to allow tests to repeat
Getting test repetition working is not very fun, unsurprisingly, go's wonderous test framework does not want such a convenience.
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)
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...
What is the issue?
Let's TypeDef.kind function:
It have 2 issues:
- The Typespec returns incorrect result, it should be
{:ok, Dagger.TypeDefKind.t()}instead ofDagger.TypeDefKind.t(). - The result return
{:ok, scalar_value}, thescalar_valueis string not an atom defined inDagger.TypeDefKind.t().
Dagger version
0.12.5
Steps to ...
Bumps the sdk-java group in /sdk/java with 10 updates:
| Package | From | To |
|---|---|---|
| io.smallrye:smallrye-graphql-client-api | 2.8.4 |
2.9.1 |
| io.smallrye:smallrye-graphql-client-implementation-vertx | 2.8.4 |
2.9.1 |
| org.eclipse:yasson | 3.0.3 |
3.0.4 |
| org.apache.commons:commons-lang3 | 3.14.0 |
3.16.0 |
| org.apache.commons:commons-compress | 1.26.2 |
1.27.0 |
| org.slf4j:slf4j-api | 2.0.13 |
2.0.16 |
| ... |
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...
Bumps the sdk-typescript group in /sdk/typescript with 8 updates:
| Package | From | To |
|---|---|---|
| execa | 8.0.1 |
9.3.1 |
| graphql-request | 6.1.0 |
7.1.0 |
| @types/node | 22.1.0 |
22.4.1 |
| [@typescript-eslint/eslint-plugin](https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/es... |
[dagger/dagger] Pull request opened: #8177 chore(deps): bump the docs group in /docs with 12 updates
Bumps the docs group in /docs with 12 updates:
| Package | From | To |
|---|---|---|
| @docusaurus/core | 3.4.0 |
3.5.2 |
| @docusaurus/preset-classic | 3.4.0 |
3.5.2 |
| @docusaurus/theme-classic | 3.4.0 |
3.5.2 |
| [@docusaurus/the... |
Bumps the engine group with 35 updates:
| Package | From | To |
|---|---|---|
| github.com/a-h/templ | 0.2.731 |
0.2.747 |
| github.com/adrg/xdg | 0.4.0 |
0.5.0 |
| github.com/charmbracelet/bubbletea | 0.26.6 |
0.27.0 |
| github.com/charmbracelet/lipgloss | 0.11.0 |
0.12.1 |
| [github.com/containernetworking/cni](https... |
Bumps the sdk-go group in /sdk/go with 11 updates:
| Package | From | To |
|---|---|---|
| github.com/adrg/xdg | 0.4.0 |
0.5.0 |
| go.opentelemetry.io/otel | 1.27.0 |
1.28.0 |
| go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp | 0.3.0 |
0.4.0 |
| [go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc](https://github.... |
This diff notably includes performance improvements from (either of these solves the root issue for us):
- https://github.com/moby/buildkit/commit/3c87ba1bd502986f627115c6756c257b4a0a66e9
- https://github.com/moby/buildkit/commit/157efce41a3c359f19b595699f5184c7986ac6ac
Previously a buildkit regression that I introduced in https://github.com/moby/buildkit/...
This error seems to appear as a weird little flake (see https://github.com/dagger/dagger/issues/8031#issuecomment-2260352601) - and never seems to appear legitimately.
Because of this, we should crank the verbosity up to try and understand what the go parser is actually seeing when this happens, which might give us a hint as to what is really going on.
We don't need separate services for each sdk test/generate/lint step - they can just all share together :heart:
[dagger/dagger] Pull request opened: #8183 chore: trim full stop from end of first line of changelog
It's pretty easily to accidentally add a full-stop at the end of a changelog line (e.g. https://github.com/dagger/dagger/pull/8163/files#diff-47044aed7a447d259a5a7a88046f34e4cc36740e18e64da88b4fa178a7349360L3).
We can trim this out during changelog generation pretty easily.
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.
This PR requires #8172.
Tasks
- [ ] Add lint function.
- [ ] Add test function.
- [ ] Integrate lint and test to the main module (
.dagger)
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...
Fixes #7918.
This just moves the warning down to a debug log - this can happen legitimately if there is a git directory (initialized with git init), but no commits have been created.
We don't need to warn in this case, we can just log a debug error (since it might still be useful for debugging).
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...
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.
This commit adds a new integration guide for Github. We should improve this in the future, but for now it adds a single example that explains how the PR shorthand words.
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...
#8191 may be causing a lot of failures on main and PRs based off main. Not 100% sure yet but they seem to have started with that PR being merged. Confirming by trying a revert here. Example failures:
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...
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...
The install example has been broken for some time! sudo doesn't forward environment variables by default for security purposes, and requires the -E flag to do this correctly.
Benchmark the typical UX workflow (init, call a function, make changes,
call a function again, ...)
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
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...
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...
When the dependencies of the PhpSdk update, the PhpSdkDev module does not. This is despite the PhpSdkDev module depending on the PhpSdk:
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...
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...
Splitting out this one from https://github.com/dagger/dagger/issues/8031#issuecomment-2260352601 to debug - it's quite clearly a different issue.
The first step towards understanding this was attempted in https://github.com/dagger/dagger/pull/8181, and now we have a few failure with this in TestModule/TestGoInit/from_scratch:
generating go module: bare
writing dagger....
[dagger/dagger] Pull request opened: #8208 chore: docker driver should exit immediately if cancelled
Noticed this with when sending CTRL+C to a dagger call command during the driver initialization, and we'd see the interrupt failed to immediately kick in.
This is because we have lots of expected errors from certain commands - the easy way to handle this is to just check if the error was a context cancelled error, and we can just bail out at that point immediately.
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...
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 2m15sPHPSuite: Execute ...
What are you trying to do?
Coming from: https://discord.com/channels/707636530424053791/1276185558166671431
func (it *PfTools) Publish(
ctx context.Context,
registry *dagger.Service,
) (string, error) {
addr, err := registry.Endpoint(ctx)
if err != nil {
return "", err
}
prodImage := dag.Container().
From("alpine").
// WithServiceBinding("registry", registry).
WithExec([]string{"apk", "add", "curl"})
...
Follow up to https://github.com/dagger/dagger/pull/8181 (as part of the investigation along https://github.com/dagger/dagger/issues/8207)
And some other weird fixes in the area that probably needed doing.
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
...
Continuing on from #6475, we should have withoutFiles, just as we have withFiles.
Ended up wanting this for working on an internal test, so decided to just add it :tada:
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 ...
Some eclectic fixes:
- Formatting and reflow of text, removing extraneous newlines
- Properly indenting a code block to render correctly
- Adding links between
.daggerandhackREADMEs for easy reference, see discord discussion: #maintainers message
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...
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
✔ ...
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...
Fix any functions that return enum value to convert string into atom after request successfully. And fix Typespec to be {:ok, } instead of just ``.
Fixes #8173
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...
Bumps the sdk-go group with 6 updates in the /sdk/go directory:
| Package | From | To |
|---|---|---|
| github.com/adrg/xdg | 0.4.0 |
0.5.0 |
| go.opentelemetry.io/otel | 1.27.0 |
1.29.0 |
| go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc | 0.0.0-20240518090000-14441aefdf88 |
0.5.0 |
| [go.opentelemetry.io/otel/exporters/otlp... |
Bumps the sdk-java group with 11 updates in the /sdk/java directory:
| Package | From | To |
|---|---|---|
| io.smallrye:smallrye-graphql-client-api | 2.8.4 |
2.9.1 |
| io.smallrye:smallrye-graphql-client-implementation-vertx | 2.8.4 |
2.9.1 |
| org.eclipse:yasson | 3.0.3 |
3.0.4 |
| org.apache.commons:commons-lang3 | 3.14.0 |
3.16.0 |
| org.apache.commons:commons-compress | 1.26.2 |
1.27.1 |
| org.slf4j:slf4j-api | 2.0.13... |
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 docs group with 9 updates in the /docs directory:
| Package | From | To |
|---|---|---|
| @docusaurus/core | 3.4.0 |
3.5.2 |
| @docusaurus/preset-classic | 3.4.0 |
3.5.2 |
| @docusaurus/theme-mermaid | 3.4.0 |
3.5.2 |
| [cl... |
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 ...
Bumps the engine group with 21 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/a-h/templ | 0.2.731 |
0.2.771 |
| github.com/adrg/xdg | 0.4.0 |
0.5.0 |
| github.com/charmbracelet/bubbletea | 0.26.6 |
0.27.1 |
| github.com/containernetworking/cni | 1.2.2 |
1.2.3 |
| [github.com/creack/pty]... |
Bumps the sdk-typescript group with 9 updates in the /sdk/typescript directory:
| Package | From | To |
|---|---|---|
| @opentelemetry/semantic-conventions | 1.25.1 |
1.26.0 |
| execa | 8.0.1 |
9.3.1 |
| graphql-request | 6.1.0 |
7.1.0 |
| @types/node | `22.1... |
Like other SDKs. It'll update every week with area/sdk/elixir label.
[dagger/dagger] Pull request opened: #8234 fix OTel `sdk/log` and `telemetry.Close` breaking changes
- Bump OTel dependencies everywhere so we can get past the
sdk/logOnEmitbreaking 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.Closebreaking 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:
- Caller must explicitly export the generated directory back to the client's filesystem, which is cumbersome. For example
dagger call codegen -o . - The target path is relative to the working directory, which means the command must be changed to match the current workdir - this makes the use of Dagger brittle. For example: `cd foo; dagg...
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.
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 (#...
Bumps the sdk-typescript group with 9 updates in the /sdk/typescript directory:
| Package | From | To |
|---|---|---|
| @opentelemetry/semantic-conventions | 1.25.1 |
1.26.0 |
| execa | 8.0.1 |
9.3.1 |
| graphql-request | 6.1.0 |
7.1.0 |
| @types/node | `22.1... |
Bumps the engine group with 22 updates in the / directory:
| Package | From | To |
|---|---|---|
| github.com/a-h/templ | 0.2.731 |
0.2.771 |
| github.com/adrg/xdg | 0.4.0 |
0.5.0 |
| github.com/charmbracelet/bubbletea | 0.26.6 |
0.27.1 |
| github.com/containerd/containerd | 1.7.20 |
1.7.21 |
| [github.com/containernetw... |
This is a small first step towards eventually generating 100% of our Github Actions config.
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...
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...
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, ...