#github-feed

1 messages ยท Page 9 of 1

vivid lintelBOT
#

We display the error message instead of the whole stack trace so it's easier for the user to catch the error.

Before

(node:30) [DEP0128] DeprecationWarning: Invalid 'main' field in '/src/dagger-docs/error-handling/sdk/package.json' of 'dist/index.js'. Please either fix that or report it to the module author
(Use `node --trace-deprecation ...` to show where the warning was created)
(node:30) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userla...
vivid lintelBOT
#

What are you trying to do?

I'm trying to use dockerBuild() with a Dockerfile containing the statement RUN --mount=type=ssh ... to forward the SSH agent to the build container so I can fetch packages from private repositories.

Why is this important to you?

We can already pass the ssh agent socket when using a container so I thought this feature would be great to close the gap in feature parity when it comes down to build an image with a Dockerfile in dagger.

How are you cur...

vivid lintelBOT
vivid lintelBOT
#

This is tricky, since the scalar aliases were getting lost in our TypeDef code. We can preserve these, and then provide a custom parser.

With this, we can add validation that the target platform is valid, as well as allow a special current platform, which allows this use case:

package main

import (
	"fmt"
)

type Playground struct{}

func (m *Playground) Hello(platform Platform) string {
	return fmt.Sprintf("hello i am platform %q", platform)
}
โฏ dagge...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Found myself calling this all over the place; I don't think we really meant to leak this out since it was originally an implementation detail of the DagQL switch. Directory.asModule and ModuleSource.asModule seem like the two main APIs for loading modules so it seems like they should return a fully instantiated one.

Funnily enough this doesn't seem to be a breaking change, since you can call initialize.initialize.initialize just fine. I saw there was a TODO to remove initialize ent...

vivid lintelBOT
#

Right now you can't invoke Functions that accept args of type Socket from the CLI. In theory, this should be as simple as supporting e.g. dagger call fn --sock unix:///var/run/docker/docker.sock or dagger fn --sock tcp://localhost:1234, etc.

However, we need to be very careful when implementing this to not accidentally create a backdoor where any (malicious) module could gain access to any host socket. I think this will require explicit tracking of which modules have access to a give...

#

Before this, it was technically possible for a module to make a raw graphql query to the Host.unixSocket API and gain access to any unix socket on the main client caller's host (i.e. where the CLI is running). This is due to the fact that the socket attachable currently has to be hardcoded to always refer to the main client caller (which in turn is due to relevant grpc metadata not being forwarded by buildkit yet in those codepaths).

Now we just enforce that this API can only ever be calle...

vivid lintelBOT
#

Summary

While documenting optional and default values in Python functions I came upon some inconsistencies in implementations due to different assumptions. The term โ€œOptionalโ€ thatโ€™s used in modules is misleading.

Terminology

In Python, an argument that is optional is one with a default value because the true meaning of โ€œoptionalโ€ is that it can be omitted.

def foo(bar: str = ""): ...

In GraphQL itโ€™s mostly the same, with the exception that a **nullabl...

vivid lintelBOT
vivid lintelBOT
#

panics can result in some bizarre error reports - for example:

failed to check version compatibility: Post "http://dagger/query": context canceled
panic: get tree hash: Post "http://dagger/query": context canceled

goroutine 51 [running]:
github.com/dagger/dagger/internal/mage/util.CIDevEngineContainer({0x90a140, 0xc0002be000}, 0xc00011a9c0, {0xc0000efb00, 0x1, 0xc00011e1d0?})
	/home/jedevc/Documents/Projects/dagger/dagger/internal/mage/util/engine.go:163 +0x5db
github.com/dagg...
vivid lintelBOT
vivid lintelBOT
#

This issue found during work on wttr module [1] that is a prototype of the Elixir for Dagger Module, the error is silent when send the output from wttr back to the function call. After investigate it, it has 2 issues:

  1. The execute function silent the error. It returns ok tuple with error result, cause a function process incorrectly.
  2. The graphql builder didn't escape \ got graphql server returns 403 parse error to the client.

This patch fix those issues above.

[1] https:...

vivid lintelBOT
#

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

See individual commit messages for explanations.

Running the full TestModule suite locally now shows RSS maxing out around 1GB (still high-ish but much more reasonable than 6GB). And most importantly, whereas previously the engine's RSS stayed high after the test suite ended (it stuck around 2-3 GB RSS), now the RSS drops down to reasonable 600MB afterwards, with pprof showing reasonable usage mostly from buildkit's in memory cac...

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

Not sure why this is happening, made my best guess with the title.

When I call my github.com/vito/bass module and pass the repo as an arg, it successfully clones the repo for the module, but the subsequent clone for the arg hangs.

Dagger version

dagger v0.10.0

Steps to reproduce

dagger call -m github.com/vito/bass --src git://github.com/vito/bass unit --packages ./pkg/bass

Don't think the commit matters, but for reference HEAD is curre...

vivid lintelBOT
vivid lintelBOT
#

Thanks @vito for the suggestion: https://github.com/dagger/dagger/pull/6759#discussion_r1504696242

This now adds linting to the engine and the go sdk for go.mod consistency. An error looks something like this:

Error: Generated code mismatch. Please run `go mod tidy`:
--- go.mod
+++ go.mod
@@ -4,12 +4,9 @@
 
 replace dagger.io/dagger => ./sdk/go
 
-require (
-	dagger.io/dagger v0.10.0
-)
+require dagger.io/dagger v0.10.0
 
 require (
-	dagger.io/dagger v0.10.0
 	gith...
vivid lintelBOT
vivid lintelBOT
#

See https://github.com/dagger/dagger/actions/runs/8075163921/job/22061629460?pr=6765 (in dagger cloud: https://dagger.cloud/dagger/runs/5a27b0b5-cf3a-4d29-b357-0ca9cfa946ff)

We get this utterly incomprehensible error message:

1179    multi.go:85: 59: exec dagger --debug develop DONE
1180    module_test.go:3432: 
1181        	Error Trace:	/app/core/integration/module_test.go:3432
1182        	Error:      	
1183        	Test:       	TestModuleCodegenOnDepChange/...
vivid lintelBOT
#

What is the issue?

The error message output by this should correctly indicate that two sibling modules being referenced must live within the same git context. This will allow end users to much more easily understand why this is failing

Dagger version

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

Steps to reproduce

โ˜  /tmp  rm -rf test     
โ˜  /tmp  mkdir test
โ˜  /tmp  cd test
โ˜  test  mkdir mod1
โ˜  test  mkdir mod2
โ˜  test  cd mod1   
โ˜  mod1  dagger ...
vivid lintelBOT
#

Fixes #6743.

We have a message size limit enforced by the gRPC connection - however, we then go to host a HTTP server on that connection, and we weren't performing any restrictions on the size of the Writes.

To resolve this, for any Write that is larger than (an adjusted for headers) size limit, we split it into multiple Write calls which will split it into several BytesMessages by the grpchijack package.

Note: no such transformation is required for Reads, since go permit...

vivid lintelBOT
#

This effectively reverts #5983, since with go.work support we can't have duplicate module names inside a single namespace.

Thankfully though, we can avoid the original issue that this fixed (where go is effectively a reserved module name), by prefixing all module names with dagger/).

This helps for daggerverse-like repo structures, where the top-level go.work would ideally need to contain all the sub-modules.

vivid lintelBOT
vivid lintelBOT
#

What happened? What did you expect to happen?

Hello everyone,

I'm new to Dagger and I wanted to inquire about the process of launching modules from private repositories, if possible.
For instance, through the CLI (dagger call) or integration into various CI/CD engines.

Here's my scenario:
I have a private GitHub repository that contains Dagger modules, and I'd like to provide third parties with the ability to include them in their GitHub Actions pipeline.
Is this feasible?...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Discord ref: #daggernauts message

Previously, we suggested that users mount sensitive directories in "userspace" from their own code: https://docs.dagger.io/guides/457482/create-app-ci-module/#step-6-add-a-function-to-run-the-application-as-a-local-service

But that no longer is viable when just using dagger call.

Off the top of my head thoughts are to either:

  1. Create a new core type like SecretDirectory or some...
vivid lintelBOT
#

What is the issue?

Before Dagger modules we built a pipeline for our micro services in a Go module we named service. Trying to migrate it to modules I can generate the module with dagger init --sdk=go service however when I try to run dagger call container-echo --string-arg='Hello Daggernauts!' stdout I get the following `

โœ˜ initialize 0.5s
  โœ” ModuleSource.asModule: Module! 0.1s
  โœ˜ Module.initialize: Module! 0.2s
    โœ˜ exec go build -o /runtime . 0.2s
    โ”ƒ # main
    ...
vivid lintelBOT
#

Bumps golang.org/x/sys from 0.16.0 to 0.17.0.

Commits

914b96c windows: support ill-formed UTF-16 in UTF16PtrToString
511ec84 Revert "windows: support nil done parameter in ReadFile and WriteFile"
628365d windows: support nil done parameter in ReadFile and WriteFile
bef1bd8 unix: move mksyscall regexp to package level variables
5710a32 unix/linux: update Linux kernel to 6.7
b3ce6a3 windows: build env_windows_test.go only go Go 1.21 and above
c3fa2b8...

#

Bumps github.com/stretchr/testify from 1.8.4 to 1.9.0.

Release notes
Sourced from github.com/stretchr/testify's releases.

v1.9.0
What's Changed

Fix Go modules version by @โ€‹SuperQ in stretchr/testify#1394
Document that require is not safe to call in created goroutines by @โ€‹programmer04 in stretchr/testify#1392
Remove myself from MAINTAINERS.md by @โ€‹mvdkleijn in stretchr/testify#1367
Correct spelling/grammar by @โ€‹echarrod in stretchr/testify#1389
docs: ...

#

Bumps golang.org/x/oauth2 from 0.16.0 to 0.17.0.

Commits

ebe81ad go.mod: update golang.org/x dependencies
adffd94 google/internal/externalaccount: update serviceAccountImpersonationRE to supp...
deefa7e google/downscope: add DownscopingConfig.UniverseDomain to support TPC
See full diff in compare view

[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=golang.org/x/oauth2&package-manag...

#

Bumps github.com/rs/zerolog from 1.31.0 to 1.32.0.

Commits

147ae65 Fix prettylog piping (#644)
4d78dc5 Add forwarding close methods to several writer implementations (#636)
c1ab4ed Make Log.Fatal() call Close on the writer before os.Exit(1) (#634)
417580d add: ContextLogger Interface LogObjectMarshaler (#623)
602e90a Fixed failing tests (#626)
a9ec232 Add stacktrace to Context (#630)
3e8ae07 Refactor: change Hook(h Hook) to Hook(hooks ...Hook) (#629)
7fa45a...

#

Bumps golang.org/x/crypto from 0.18.0 to 0.20.0.

Commits

0aab8d0 all: update go.mod x/net dependency
5bead59 ocsp: don't use iota for externally defined constants
1a86580 x/crypto/internal/poly1305: improve sum_ppc64le.s
1c981e6 ssh/test: don't use DSA keys in integrations tests, update test RSA key
62c9f17 x509roots/nss: manually exclude a confusingly constrained root
405cb3b go.mod: update golang.org/x dependencies
913d3ae x509roots/fallback: update bun...

#

Bumps httpx from 0.26.0 to 0.27.0.

Release notes
Sourced from httpx's releases.

Version 0.27.0
0.27.0 (21st February, 2024)
Deprecated

The app=... shortcut has been deprecated. Use the explicit style of transport=httpx.WSGITransport() or transport=httpx.ASGITransport() instead.

Fixed

Respect the http1 argument while configuring proxy transports. (#3023)
Fix RFC 2069 mode digest authentication. (#3045)

Changelog
Sourced from httpx's changelog.

0.27....

#

Bumps pytest-httpx from 0.29.0 to 0.30.0.

Release notes
Sourced from pytest-httpx's releases.

0.30.0 (2024-02-21)
Changed

Requires httpx==0.27.*

Fixed

Switch from setup.py to pyproject.toml (many thanks to Felix Scherz).

Changelog
Sourced from pytest-httpx's changelog.

[0.30.0] - 2024-02-21
Changed

Requires httpx==0.27.*

Fixed

Switch from setup.py to pyproject.toml (many thanks to Felix Scherz).

Commits

36c5062 Merge pull request #1...

#

Bumps certifi from 2023.11.17 to 2024.2.2.

Commits

45eb611 2024.02.02 (#266)
83f4f04 fix leaking certificate issue (#265)
bbf2208 Bump actions/upload-artifact from 4.2.0 to 4.3.0 (#264)
9e837a5 Bump actions/upload-artifact from 4.1.0 to 4.2.0 (#262)
05d071b Bump actions/upload-artifact from 4.0.0 to 4.1.0 (#261)
2a3088a Bump actions/download-artifact from 4.1.0 to 4.1.1 (#260)
d4ca66e Bump actions/upload-artifact from 3.1.3 to 4.0.0 (#258)
5d1566...

#

Bumps ruff from 0.1.14 to 0.3.0.

Release notes
Sourced from ruff's releases.

v0.3.0
This release introduces the new Ruff formatter 2024.2 style and adds a new lint rule to
detect invalid formatter suppression comments.
Changes
Preview features

[flake8-bandit] Remove suspicious-lxml-import (S410) (#10154)
[pycodestyle] Allow os.environ modifications between imports (E402) (#10066)
[pycodestyle] Don't warn about a single whitespace character before a comm...

#

Bumps anyio from 4.2.0 to 4.3.0.

Release notes
Sourced from anyio's releases.

4.3.0

Added support for the Python 3.12 walk_up keyword argument in anyio.Path.relative_to() (PR by Colin Taylor)

Fixed passing total_tokens to anyio.CapacityLimiter() as a keyword argument not working on the trio backend (#515)

Fixed Process.aclose() not performing the minimum level of necessary cleanup when cancelled. Previously:

Cancellation of Process.aclose() could...

vivid lintelBOT
#

Bumps github.com/stretchr/testify from 1.8.3 to 1.9.0.

Release notes
Sourced from github.com/stretchr/testify's releases.

v1.9.0
What's Changed

Fix Go modules version by @โ€‹SuperQ in stretchr/testify#1394
Document that require is not safe to call in created goroutines by @โ€‹programmer04 in stretchr/testify#1392
Remove myself from MAINTAINERS.md by @โ€‹mvdkleijn in stretchr/testify#1367
Correct spelling/grammar by @โ€‹echarrod in stretchr/testify#1389
docs: ...

#

Bumps org.mockito:mockito-core from 5.10.0 to 5.11.0.

Release notes
Sourced from org.mockito:mockito-core's releases.

v5.11.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.11.0

2024-03-01 - 17 commit(s) by Aouichaoui Youssef, Franz Wong, Pranoti Durugkar, Rรณbert Papp, dependabot[bot]
Fixes #3281 : Add native method to exception message of MissingMethodIโ€ฆ (#3283)
MissingMethodInvocationException is thrown when mocking ...

#

Bumps org.codehaus.mojo:exec-maven-plugin from 3.1.0 to 3.2.0.

Release notes
Sourced from org.codehaus.mojo:exec-maven-plugin's releases.

3.2.0

๐Ÿš€ New features and improvements

Enable to exec:java runnables and not only mains with loosely coupled injections (#408) @โ€‹rmannibucau
Try to get rid of legacy API which can break starting with java 17 (#409) @โ€‹rmannibucau

๐Ÿ› Bug Fixes

Fix #401 - Maven v4 compatibility (#414) @โ€‹slawekjaranowski

๐Ÿ“ฆ D...

#

Bumps de.m3y.maven:inject-maven-plugin from 1.5 to 1.7.

Release notes
Sourced from de.m3y.maven:inject-maven-plugin's releases.

1.7
What's Changed

Require Maven 3.9+ #161

Full Changelog: https://github.com/marcelmay/inject-maven-plugin/compare/inject-maven-plugin-1.6...inject-maven-plugin-1.7
1.6
What's Changed

Fix path issue on Windows by @โ€‹HelmutWiedemann in marcelmay/inject-maven-plugin#160
Bump net.bytebuddy:byte-buddy from 1.14.10 ...

#

Bumps eslint from 8.56.0 to 8.57.0.

Release notes
Sourced from eslint's releases.

v8.57.0
Features

1120b9b feat: Add loadESLint() API method for v8 (#18098) (Nicholas C. Zakas)
dca7d0f feat: Enable eslint.config.mjs and eslint.config.cjs (#18066) (Nitin Kumar)

Bug Fixes

2196d97 fix: handle absolute file paths in FlatRuleTester (#18064) (Nitin Kumar)
69dd1d1 fix: Ensure config keys are printed for config errors (#18067) (Nitin Kumar)
9852a31 fix: deep m...

#

Add ExperimentalPrivilegedNesting args in DefaultTerminalCmdOpts and TerminalOpts.
Add InsecureRootCapabilities args in DefaultTerminalCmdOpts and TerminalOpts.

I did some test with a local module I made but I struggle figuring out how to test it in our integration's test.
I know we have module_terminal_test.go for terminal tests and container_test.go for inscure and nesting params but I cannot figure out a nice way to combine both because this requires extra installation...

vivid lintelBOT
#

This is a spin-off of work on https://github.com/dagger/dagger/issues/6747, which has proven itself to be a fountain side-quests all over the codebase. Splitting that effort up into separate PRs for everyone's sanity. There will be at least more pre-req PR (for improving dagql ID digest performance to support walking IDs efficiently) before the "final act" of the actual user-facing features.

This change results in each client getting its own buildkit.Client and buildkit Session. As a s...

vivid lintelBOT
#

What is the issue?

The output from when running a dagger functions command on Windows is not correctly formatted. When running with --progress plain, the output is as expected, but when running with --progress tty, it is adding D[85D[85D[85D85D right before the output and without a newline.

Dagger version

dagger v0.10.0 (registry.dagger.io/engine) windows/amd64

Steps to reproduce

Run dagger -m github.com/shykes/daggerverse/hello@v0.1.2 call hello

Running with t...

vivid lintelBOT
#

Fixes regression from #6601, see discord discussion.

Essentially, it became possible to construct an input which would apply the secret accessor translation twice. If one of the frontend inputs was constructed from dagger, it could already have an accessor secret ID as part of it's build graph (if WithExec was used alongside a secret).

However, this input could appear inside the frontend request - which would resu...

vivid lintelBOT
#

Follow-up on comments from https://github.com/dagger/dagger/pull/6352#discussion_r1439349557.

Getting kinda annoyed with all the dependabot spam :cry:

  • By moving from once-a-month to once-a-week, we stay more on top of changes, which means there should be fewer to address all at once. Additionally, I've set the time to trigger on Monday morning - that way, we can hopefully review and merge before the next release.
  • I've also used groups to try and ensure that each set of updates is...
vivid lintelBOT
#

This PR does three things, mostly to reduce overhead of creating several distinct PRs and move this forward quickly:

  • Bumps the Docusaurus version
  • Adds Typescript support. This makes it easier to work with swizzled/custom components and creating custom plugins.
  • Allows multiple versions to be consumed by the guides plugin, by passing the versions through the plugins field of the docusaurus.config.ts file.

Feel free to comment if you think this should be separated into multiple PRs!

vivid lintelBOT
#

Problem

When installing a specific dependency into a downstream Go module, the downstream Go module starts to fail with codegen-related errors.

  • The dependency is valid: calling it directly from the CLI works
  • The error is Go-specific: when installing the same dependency on a Python downstream module, there is no error
  • The error seems related to the module's name and contents. Specifically the module name is docker and it contains a top-level function CLI (in Go). It seems ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Following of #6685 to update the test publish job.

It's weird but some test are not run on push and so we didn't caught this erorr.
https://github.com/dagger/dagger/blob/1759f47a7c6bc8cc13380e193f6f7a1248ca6e0d/.github/workflows/publish.yml#L93

Normally this fixes works and fixes:

Btw, do we actually need these tests? Since we are using Dagger modules now, we don't have use that provisioning feature anymore.

vivid lintelBOT
vivid lintelBOT
#

Think this is a regression in v0.10.1 cc @TomChv

See https://github.com/dagger/dagger/pull/6805/files#r1513137070

goroutine 457496 [running]:
runtime/debug.Stack()
	/usr/local/go/src/runtime/debug/stack.go:24 +0x5e
github.com/dagger/dagger/dagql.(*Server).resolvePath.func1()
	/app/dagql/server.go:642 +0x74
panic({0x1bd65a0?, 0x3139130?})
	/usr/local/go/src/runtime/panic.go:914 +0x21f
github.com/dagger/dagger/core/schema.(*containerSchema).terminal(0x1d3a040?, {0x2299038, 0x...
vivid lintelBOT
vivid lintelBOT
#

This PR is a follow up to #6522 with new features:

  • Add bump command to replace mage's
  • Bump node default version to 18
  • Improve documentation
  • Disable outdated provisioning test

โš ๏ธ I'm not sure that the test disabling is accurate because @jedevc told me we would still support connect function without module.
Let me know if I should revert that part, I only did it so now all functions in the modules work and there's only publish to support in order to completely be comp...

vivid lintelBOT
#

Improve the TypeScript module internal to be easier to maintain and more clear.
This refactor aims to abstract the scan logic using classes to hide the complexity and expose a simpler interface to interact with. By doing so, we no longer need standalone functions to do the introspection, the class is responsible for his own introspection.

After completing the refactor, most of the scan old code with be replaced by the new logic.

This refactor also aims to simplify some logic with the T...

vivid lintelBOT
#

What is the issue?

When a function has an optional argument with a list of lists, the function is callable from a programmatic way but from the cli an error is thrown.

Link to discord [discussion](#daggernauts message)

Dagger version

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

Steps to reproduce

You need to have in your module a function with an optional list of lists like that:

type MyMo...
vivid lintelBOT
vivid lintelBOT
#

This is another spin-off of https://github.com/dagger/dagger/issues/6747 (sibling to https://github.com/dagger/dagger/pull/6806) with the goal of enabling us to efficiently "walk" IDs in order to find all instances of a given type embedded in their DAG.

This is accomplished by updating the dagql ID format to store a map of digest->fields for ID with that digest, with any other references to IDs being via that digest (whereas previously we recursively repeated every ID every time it occ...

vivid lintelBOT
#

...not just the last one. Not quite sure why I missed this before, but this occurs in some test cases (that are really annoying to add test cases for some reason).

This fixes up the logic from #6809 - see the discord conversation in #1212602528890363955 message.

Not 100% sure why the previous fix wasn't right, but this definitely works, and I don't really have the time to dive into exactly what I'm misunderstanding.

vivid lintelBOT
#

What is the issue?

We have been getting reports of no space left on device errors with Dagger v0.10.x running on GitHub Actions runners. This issue is mean to centralise private discussions and make it transparent to anyone that is affected by this.

If you are affected by this issue, please leave a comment with as much details that you are able to share publicly. We are especially interested in:

  1. When did you first notice this issue?
  2. Which version of Dagger are you using?
    ...
vivid lintelBOT
ornate vigilBOT
vivid lintelBOT
#

What are you trying to do?

The current behavior is to load the hosts .docker/config into the dagger session so that existing registry authentications can be used. While this is generally a convenience, there are cases where this is not desirable and there should be an option to opt out of this behavior

Why is this important to you?

No response

How are you currently working around this?

No response

#

This PR introduces a fully-operational ci/ directory, replacing the old non-functional one.

This new CI allows for all of the following:

  • Running our tests
  • Utilities like linting, code-gen, bumping
  • Building the engine/cli/sdks

[!WARNING]

This isn't fully ready yet, but opening a work-in-progress PR to make it easier to track.

A few things I've realized while doing this that I think are technically out-of-scope for this particular piece of work, but we should make ...

vivid lintelBOT
vivid lintelBOT
#

Reported here: https://github.com/dagger/dagger/pull/6829#discussion_r1513464630

Based on my testing, the following did not work:

dagger call foo --token env:TOKEN
echo $TOKEN > token.txt
dagger call foo --token file:./token.txt

Breaking out the file parsing code, the token.txt would be parsed with a newline character at the end.

This adds TrimSpace() to file and cmd secret inputs. TrimSpace() trims leading and trailing unicode whitespace characters. I can't thin...

vivid lintelBOT
vivid lintelBOT
#

What happened? What did you expect to happen?

Previously I had a working Build function with old dagger v0.9 way to build from Dockerfile and push to private registry:

// build image and push to registry
func Build() {
	ctx := context.Background()
	// initialize Dagger client
	client, err := dagger.Connect(ctx, dagger.WithLogOutput(os.Stdout))
	if err != nil {
		panic(err)
	}
	defer client.Close()
	godotenv.Load()
	// read secret from host variable
	tag := os.Getenv(...
vivid lintelBOT
#

Follow-up to https://github.com/dagger/dagger/pull/6716 - people were using Query as a method name, see [discord](#daggernauts message).

This could cause name clashes and was annoying. Thankfully, there's only one legitimate need for this field to be public - interfaces.

We can provide a workaround for this with the new WithGraphQLQuery method on generated types, which resets the underlying type, and sets the query.
...

vivid lintelBOT
#

Should fix https://github.com/dagger/dagger/issues/6850 (cc @morlay)

This regressed in https://github.com/dagger/dagger/pull/6716, and meant that child clients were invalid, and couldn't be called with Do(), as well as causing GraphQLClient() to return an invalid nil value.

This only previously worked because the GraphQL client and the dagger client shared the same name client. When this property was removed, the propagation stopped working. Now, we make this special case explicit...

vivid lintelBOT
#

What is the issue?

I'm following the steps described in the docs for chaining a terminall command to a container output and the following error appears.

> dagger call -m github.com/shykes/daggerverse/wolfi@v0.1.2 container --packages=cowsay terminal
โœ” Wolfi.container(packages: ["cowsay"]): Container! 1.5s
  โœ” exec /runtime 1.5s
  โœ” Apko.wolfi(packages: ["cowsay"...
vivid lintelBOT
vivid lintelBOT
#

There is an extra space in the CLI snippet that causes the command to fail with the following error:

levlaz@Levs-MacBook-Pro ts % dagger call build --source=https://github.com/golang/example/#master:hello --os=linux --architecture =amd64 terminal
zsh: amd64 not found

Removing this space fixes it.

#

What is the issue?

Some users have reported some issues while getting started with dagger about dagger develop not apparently working as expected. In most of those cases we found out that they didn't run dagger init before calling dagger develop which yielded to some unexpected results.

@shykes suggested (#1215438073694003300 message) making dagger develop to fail if no dagger.json is found which seems reasonable
...

vivid lintelBOT
#

Fixes https://github.com/dagger/dagger/issues/6155 and https://github.com/dagger/dagger/issues/6606

Adds support for views as described in the linked issue to support filtering individual directory args. This also required adding a way of configuring this from the CLI, which entailed all the work of fleshing out dagger config, so that's done now too.

Examples:

# create a new view named cool-view
dagger config views set --name cool-view '**/*.go' '!bin/'

# use the view
...
vivid lintelBOT
#

What is the issue?

When attempting to execute a function that includes an argument named json, I encounter an error, despite anticipating it would function correctly.

This issue arises in the context of developing a Dagger function for cloc. Given that the command-line interface offers options such as --json and --yaml, I aimed to directly correlate these with a boolean parameter in the Dagger function.

Dagger version

dagger v0.10.1 (reg...

vivid lintelBOT
#

Trying out the python dev guide and think there is a self missing here.

Output without self:

 dagger call hello-world       
โœ” daggerPotato: DaggerPotato! 0.5s
  โœ” exec /runtime 0.5s
โœ˜ DaggerPotato.helloWorld: String! 0.6s
  โœ˜ exec /runtime 0.6s
  โ”ƒ โ•ญโ”€ Error โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ•ฎ                                         ...
vivid lintelBOT
vivid lintelBOT
#

What happened? What did you expect to happen?

Recently, I was trying to automate Docker builds and was experimenting with different Dagger features.
Trying to assign the whole built image to a variable led to an unexpected error. For example:

image = await client.container().build(
    context=workspace, dockerfile=dockerfile_basename
)
value = await image.as_tarball()
printable = await value.contents()
print(printable)

results in such error:

ERROR:root:Unexpecte...
vivid lintelBOT
vivid lintelBOT
#

When using multiple files, the src/main.py file should be turned into a package (i.e., src/main/__init__.py). This is explained in https://docs.dagger.io/developer-guide/python/820256/module-structure#multiple-files.

However, it's an easy oversight for users that adds confusion, so dagger init should create a proper package instead of the single main.py module.

ruff even complains with the [implicit-namespace-package (INP001) ](https://docs.astral.sh/ruff/rules/implicit-namesp...

vivid lintelBOT
#

Summary

Return only error and no value if return type for a function is Void.

Motivation

It makes no sense for the client to capture a Void value as it's specifically meant for side-effects only. It has no meaning as a value. If you have the following function:

func (m* MyModule) Deploy() error {
    // do something that may return an error
}

This should produce the following schema:

type MyModule {
    deploy: Void
}

But codegen f...

vivid lintelBOT
#

This commit

  • renames the top-level "user guide" and "developer guide" categories to "user manual" and "developer manual"
    • updates the URLs, filesystem paths and links to reflect the new naming scheme
    • adds redirections for the previous URLs
  • renames the second-level developer "guides" category to a new top-level category named "tutorials"
    • updates the URLs, filesystem paths and links to reflect the new naming scheme
    • adds redirections for the previous URLs
    • in futur...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

This commit adds a new top-level category for the "administrator manual". This is a parallel category to the "user manual" and "developer manual" added in #6869

This commit:

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

(We have internal issues for this but making a public facing one since it comes up fairly often)

To improve cold start (i.e. empty cache) latency when using modules, we are planning on adding support to cloud cache for a global/read-only tier that comes pre-loaded with base SDK builds and some number of base module builds. Details on which modules specifically is TBD

vivid lintelBOT
#

It would be great if dagger install always worked, no matter the current working directory:

If... Then... Status
Workdir is inside a dagger module Install into the current module Implemented โœ…
Workdir is NOT inside a dagger module Install into the home directory as if it were a module Not yet implemented โŒ

I propose implementing the second row: when calling dagger install outside a module, use the home directory as a pseudo-module instead....

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

Load docker compose files (just like how dagger can use Dockerfile) and automatically generate map of containers accordingly with docker compose service name as key. Any unsupported setting from docker compose file can be ignored.

Why is this important to you?

I've been using dagger for a while and it's great for running ci/cd pipeline across machines. But i still feel that it hards to replace the simplicity of docker compose when used to run dependencies...

vivid lintelBOT
#

What are you trying to do?

The dagger docs for gitlab / github / etc have each job installing curl followed by installing the dagger CLI to use for a given CI run. It would be much nicer DX, and probably faster to just have an official docker image that can be used that has the CLI already installed?

Why is this important to you?

No response

How are you currently working around this?

No response

#

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

This makes whether a .gitignore is created a configurable setting in dagger.json, with the default being true.

For now, this will require hand-editing dagger.json if the setting should be changed to false, but CLI support will come along with the follow ups to https://github.com/dagger/dagger/pull/6857 as a dagger config subcommand.

To prevent the .gitignore from being created, you need to do:

  • dagger init with no `--sd...
vivid lintelBOT
#

What are you trying to do?

I want to be able to publish a Dagger module to an SCM other than GitHub, especially as I work with organisations that use GitLab and self-hosted instances. I like the look of Dagger and can see its benefits. Running CI locally is a game changer, but GitHub isn't always an option.

Why is this important to you?

It provides more freedom regarding where you publish your Dagger modules, greatly increasing Dagger's usability. It also enables other platforms li...

vivid lintelBOT
#

What is the issue?

When inexperienced helm chart and k8s users try to add pod affinity or tolerations to values.yml, whey will simply remove the comments and when they do, the properties are under image instead of engine, where they should be. This will cause the changes to not take effect and they might get stuck asking about it, causing unnecessary work.

To remedy this, the comments just need to be moved over two spaces.

PR coming!

Scott

Dagger version

dagger v0...

vivid lintelBOT
#

What is the issue?

I'm migrating my CI from GH actions to CircleCI in order to use ARM executors. Following is the pipeline for both GH Actions and CircleCI. I'm using the Dagger Python SDK. GH Actions pipeline runs fine, but CircleCI instantly panics when the dagger run command is executed.

Funnily enough, when SSHing into the CircleCI instance and running the same command there, the engine Dagger pipeline works just fine. I could not for the life of me find a related issue, and the ...

vivid lintelBOT
#

What is the issue?

Setting --oci-max-parallelism 2 on the Engine causes deadlocks, both with & without modules.

This is what that looks like from the CLI / user perspective:

https://github.com/dagger/dagger/assets/3342/826ddb73-c36e-469e-9560-f21b3fd13388

Attaching Dagger Engine v0.10.2 logs + SIGQUIT. Thank you @vito for https://vito.github.io/swirly/ and the tips!

vivid lintelBOT
#

What is the issue?

If you have a function that accepts *Secret parameters, when you run --help it will print the parameter and an empty default value even when you do not specify that the parameter has a default.

I first noticed this in my Mastodon module which looks like this.

func (m *Mastodon) Toot(
	ctx context.Context,
	// url of mastodon instance
	server string,
	// mastodon application client id
	clientId string,
	// mastodon application client secret
	cli...
vivid lintelBOT
#

Today, we can merge directories using Directory.WithDirectory - however, there's no corresponding WithoutDirectory method, like we have on Container.

This is slightly frustrating - imagine the following use case (cc @slumbering):

func (m *MyModule) DoThing(src *Directory) {
	// I want to filter src down, and remove a directory:
	src = dag.Directory().WithDirectory("/", src, DirectoryWithDirectoryOpts{
		Exclude: []string{"node_modules"},
	})

	// But, ideally I'd just...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

It doesn't look like we can specify a version to download in dagger using the instructions here: https://docs.dagger.io/quickstart/729237/cli:

$script = Invoke-WebRequest -UseBasicParsing -Uri https://dl.dagger.io/dagger/install.ps1
$params = "-DaggerVersion 0.9.7"
"$script $params" | Invoke-Expression

If I look at the contents at that script:

> curl https://dl.dagger.io/dagger/install.ps1
# param (
#     [Parameter(Mandatory)] $PersonalToken
# )
Clear-Host
@"
...
vivid lintelBOT
#

Noticed this while working on https://github.com/dagger/dagger/pull/6857

Right now if you have two modules in a local repo checkout and there is a dependency between them, if

  • Module A does an include of *.foo
  • Module B does an exclude of *.foo

Then the exclude of Module B will override the include from Module A. The direction of the dependency between A and B doesn't matter, the end effect will be the same.

The problem is that module loading currently combines all the includ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Related discord thread: #1220078037542895617 message

By default, exporting a directory resulted in its contents being merged into the target directory on the host, with any files that existed on the host but not in the source dir being untouched during the export.

More often than not, this is the behavior you want, but there are use cases where you'd instead like to replace the contents of the host directory entirely such that i...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Related discord thread: #1220153273370280048 message

Some git url formats inline credentials to the URL, in which case dagger ends up printing those creds. If we instead added an arg of type Secret and then internally did the formatting for the user, we could avoid this.

I'm guessing it's possible to do this, it just requires that the user can leave out the creds from the URL in a reasonable way that doesn't result in some amb...

vivid lintelBOT
#

Previously it was possible to start a dependent service in one module API call, and then use it again in a later call, only to have it fail because it cannot resolve the service address, even though it's still running. This happened because each invocation has its own client ID, and client IDs were used to build service addresses.

This change brings service addresses into alignment with the recent change to uniq them by service ID instead of client ID. The overall effect is that services a...

vivid lintelBOT
#

Consider the following Dockerfile:

FROM bash

ARG FOO="vs\n"

RUN cat <> /script
# Cats ($FOO)
# Dogs
echo OK!
EOF

RUN cat -n /script && bash /script

And the following function:

package main

type Dockerfile struct{}

func (m *Dockerfile) Build() *Container {
	return dag.Directory().
	        WithFile("Dockerfile", dag.CurrentModule().Source().File("Dockerfile")).
        	DockerBuild(DirectoryDockerBuildOpts{
			BuildArgs: []BuildArg{
				Bui...
vivid lintelBOT
#

This is the last part of the saga around https://github.com/dagger/dagger/issues/6747 that fully isolates sessions to each client and thus enables support for passing host unix sockets to modules, plugging some existing holes in our secret isolation, etc.

This PR doesn't have all that yet, been in the process of rebuilding it cleanly after an initial messy prototype. Sending it out anyways because what I have here seems to fix the problem in https://github.com/dagger/dagger/pull/6914, so m...

vivid lintelBOT
#

wip, need unit tests, just don't want to lose track of this rabbit hole

To no one's surprise, the tricky reflect handling around input objects isn't working properly, resulting in this ID for up --ports 9090:8080:

Service.up(ports: [{frontend: null, backend: 8080, protocol: TCP}])

instead of this:

Service.up(ports: [{frontend: 9090, backend: 8080, protocol: TCP}]):

The actual behavior is correct - the resolver gets 9090, not null - but the serializatio...

vivid lintelBOT
#

What is the issue?

I am trying to write a dagger module that builds a Dockerfile and then returns an intermediate type, which allows the caller to execute subsequent functions like publish or export. However, when I try to implement these functions, I get inconsistent behaviour compared to returning a Dagger built-in type like File and then exporting.

Dagger version

dagger v0.10.2 (registry.dagger.io/engine) darwin/amd64

Steps to reproduce

Here is an example module:

...

vivid lintelBOT
#

What happened? What did you expect to happen?

I really like the look of Dagger and I am about to take the plunge and migrate my existing GitLab workflows. But I admit, I am a little stumped as to what approach I should take. The documentation focuses heavily on Dagger Modules, so I imagine that is the preferred path.

I am in the process of breaking down my existing GitLab pipeline into composable Dagger modules. And this is where the confusion sets in.

Should I:

  1. Keep the same...
vivid lintelBOT
#

What is the issue?

Hello,
when I initialise a new dagger module and select the go sdk with dagger init --name test --sdk=go --source ., a .gitattributes file is generated but a .gitignore file to exclude the generated code is missing. This seems like unintended behaviour since for e.g. the python sdk, a matching .gitignore file is produced.

Dagger version

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

Steps to reproduce

  1. Run `dagger init --name ko --sdk=g...
vivid lintelBOT
#

What is the issue?

Cannot run dagger init on windows

seems it has problem with filepath.IsAbs for windows

Dagger version

dagger v0.10.2 windows/amd64

Steps to reproduce

  1. install dagger CLI for windows
  2. run command dagger init

Log output

Error: failed to get configured module: failed to get local root path: input: moduleSource.resolveContextPathFromCaller resolve: failed to find up root: path is not absolute: C:\projeccts\test

vivid lintelBOT
#

cc @levlaz

If a secret gets passed into a function input, it's useful to be able to determine the original name of the secret.

This is especially significant for the following API:

type Directory {
  ...

  dockerBuild(
    ...

    """
    Secrets to pass to the build.
    
    They will be mounted at /run/secrets/[secret-name].
    """
    secrets: [SecretID!] = []

    ...
  ): Container!

If we don't know the secret-name, there's no way to get a...

vivid lintelBOT
#

The issue (found at kubecon :tada:):

$ pwd
/tmp/work/fooรฉ/test
$ dagger init --sdk=go --source=.
โœ˜ ModuleSource.resolveContextPathFromCaller: String! 0.0s

Error: failed to get configured module: failed to get local root path: input: moduleSource.resolveContextPathFromCaller resolve: failed to find up root: failed to lstat .git: failed to create diff copy client: rpc error: code = Internal desc = rpc error: code = Internal desc = header key "dir-name" contains value with non-prin...
vivid lintelBOT
#

Introduced in https://github.com/dagger/dagger/pull/6860, causing some additional test flake.

This manifested as additional flakiness in the test, causing out to be written to in a racey way:

WARNING: DATA RACE
Write at 0x00c00189a6c0 by goroutine 20341:
  github.com/dagger/dagger/core/integration.TestModuleDaggerDevelop.func1.1()
      /app/core/integration/module_config_test.go:542 +0x9bd
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:1595 +0x261
  testi...
vivid lintelBOT
#

Imagine the below:

	ctr := dag.Container().From("alpine")
	ctr.
		WithMountedFile("/ctr.tar", ctr.AsTarball()).
		WithExec([]string{"ls", "-lh", "/"}).
		Sync(ctx)

On the first run, this works as expected:

  1. ctr is built
  2. AsTarball triggers an OCI export
  3. WithExec is run on the result

However, on subsequent runs, this doesn't cache as expected - AsTarball is always executed, which results in ls always being run. I don't observe this change if I com...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Repro: https://github.com/yann-soubeyrand/daggerverse/blob/0bfceb15f2597da89cb08bd6c8ba5c73baea6df7/test/main.go

The problem is that the autogenerated method for the interface impl tries to call WithGraphQLQuery but that doesn't exist on the type: https://github.com/yann-soubeyrand/daggerverse/blob/0bfceb15f2597da89cb08bd6c8ba5c73baea6df7/test/dagger.gen.go#L598

Due to the current rule that types defined in a module are serialized with their JSON representation rather than their ID, t...

vivid lintelBOT
vivid lintelBOT
#

For example:

https://github.com/dagger/dagger/blob/3bc4bd1263570d67ced697d0b453c5d418ceb4ce/sdk/rust/crates/dagger-sdk/src/gen.rs#L5156

This type is wrong - it should instead be:

-     pub fn load_container_from_id(&self, id: Container) -> Container {
+     pub fn load_container_from_id(&self, id: ContainerID) -> Container {

The top-level Query.Container has [been deprecated for some time](https://github.com/dagger/dagger/blob/3bc4bd1263570d67ced697d0b453c5d418ceb...

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

Pipeline fails with the above error.

Trace:

goroutine 1 [running]:
github.com/vito/progrock/console.(*textMux).print(0xc000115e60, 0xc0000ba000)
	/go/pkg/mod/github.com/vito/progrock@v0.10.2-0.20240221152222-63c8df30db8d/console/printer.go:229 +0x185
github.com/vito/progrock/console.(*Writer).Close(0x410565?)
	/go/pkg/mod/github.com/vito/progrock@v0.10.2-0.20240221152222-63c8df30db8d/console/writer.go:87 +0x25
github.com/dagger/dagger/telemetry.LegacyID...
vivid lintelBOT
vivid lintelBOT
#

Problem

dagger call [ARGS] --help plays a crucial role, and must be kept as lean as possible. At the moment there is clutter that could be removed.

Solution

De-clutter the output of dagger call [ARGS] --help.

  • Don't show global flags every time
  • Don't show call flags when a function is selected
  • Talk about "functions" and "arguments", rather than "function commands" and "flags"
  • Other?
#

Problem

When passing an argument of type Directory, the CLI accepts a git remote url (eg. https://github.com/dagger/dagger) which is awesome; but it does not support passing a sub-directory of that git repo (eg. https://github.com/dagger/dagger/docs) which is not awesome.

Solution

Support passing a sub-directory of a git remote as CLI argument to Dagger CLI.

#

Problem

Modules are often grouped together in "catalogs" via the Daggerverse Repo pattern. There is no easy way to take advantage of this in the CLI.

For example, this doesn't work:

# Install a daggerverse repo
dagger install github.com/shykes/daggerverse --as=shykes
# Call one sub-module
dagger call -m shykes/supergit --help
# Call another sub-module
dagger call -m shykes/docker --help

The above โ˜๏ธ will fail because shykes/supergit and shykes/docker are...

#

Problem

When loading a module from the CLI without specifying a version (for example dagger call -m github.com/shykes/daggerverse/hello, or dagger install github.com/shykes/daggerverse/hello), the default behavior is to load from the last development branch (usually main). Even if there are tagged releases, these will be ignored.

This is incorrect behavior, and will cause unhappy surprises. When there are versioned releases, users expect to use the latest release by default.

...

#

Problem

When dagger call ends on an object (as opposed to a scalar value), it returns an error with a message saying "please query a field of this object".

This is a problem because:

  1. At a glance, it gives the impression that the user did something wrong, when in fact they did not. So an error is sending the wrong message.
  2. It makes a valid task (produce an object and look at it) harder than it should be. Just show me the object!

Solution

  1. Never show an error whe...
#

Problem

GraphQL supports querying multiple fields from the same object, which is very useful especially for data querying. But the CLI doesn't support this. This drastically limits use cases for dagger call. Basically it makes it impossible to use a Dagger Module as a practical data interface, usable from the CLI.

For an example, see https://daggerverse.dev/mod/github.com/dagger/dagger/linters/markdown

Querying multiple fields can also be applied for easy parallelism: advanced c...

vivid lintelBOT
#

Problem

The user experience for authenticating Dagger CLI to Dagger Cloud, is sub-par. There is a dagger login command, but it doesn't actually do anything.

Solution

Actually implement dagger login, to authenticate the Dagger CLI against Dagger Cloud.

  • For an initial implementation, storing credentials in a file in the user's home directory is fine
  • As a follow-up improvement, integrate with native OS credentials manager, for example Keychain in Mac OS, etc.
vivid lintelBOT
#

This appears to be a regression introduced in 0.10.2, things work as expected in 0.10.1

From @nipuna-perera on Discord:

Basically run (container A + service).

file = get file from (container A + service)

Try to run (container B + file) fails with:

host alias: lookup t6sjv1ru3serq on 10.87.0.1:53: no such host
  โ”ƒ lookup t6sjv1ru3serq.c1mh4mk35essm.dagger.local on 10.87.0.1:53: no such host
vivid lintelBOT
#

Problem

In some situations, a module may define a type which has a perfectly valid name, but still encounters a naming conflict. The conflict may be with a type defined by a dependency, or with a core type.

The conflict occurs when concat(, ) is equal to either concat(, ), or ``.

For example:

  • If a module Git defines a type Repository, it will conflict with the core type GitRepository
  • If a module Docker defines a type ComposeProject, it will conflict with a de...
vivid lintelBOT
#

What is the issue?

The command to init module not working when we are behind coorporate proxy.

dagger develop --sdk=go

It try to access direcly on internet instead to use coorporate proxy (env http_proxy / https_proxy / no_proxy). It seems it ignore standard environment variable to drive proxy ...

Dagger version

dagger 0.10.2

Steps to reproduce

Set proxy with on local computer with:

  • HTTP_PROXY
  • HTTPS_PROXY
  • NO_PROXY

Set the $HOME//.docker/con...

vivid lintelBOT
vivid lintelBOT
#

What happened? What did you expect to happen?

How can I get access to the host from a dagger function?

I miss the Host() , Is there any way to to this?

package main

import (
	"context"
)

type MyModule struct{}

func (m *MyModule) Test(

	ctx context.Context,

) string {

       // Host() does not exists
	myDir := dag.Host().Directory("/tmp/my-directory")

	content, err := myDir.File("my-file").Contents(ctx)

        if err != nil {
		panic(err)
	}
...
vivid lintelBOT
#

What happened? What did you expect to happen?

facing issue when build docker image

my code is like
`// A generated module for TestDagger functions
//
// This module has been generated via dagger init and serves as a reference to
// basic module structure as you get started with Dagger.
//
// Two functions have been pre-created. You can modify, delete, or add to them,
// as needed. They demonstrate usage of arguments and return types using simple
// echo and grep commands. Th...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What is the issue?

In the Python SDK, the signatures of Directory.with_new_file and Container.with_new_file are inconsistent. For Directory, contents is a required positional argument, while for Container, contents is a keyword-only argument. This inconsistency is confusing and often requires referencing the API documentation to determine the correct usage. I vote for setting up a PR, if you could give me a hint on the preferred behaviour.

Dagger version

dagger v0.10.2 ...

vivid lintelBOT
vivid lintelBOT
#

Problem

When initializing an SDK with dagger develop or dagger init --sdk, source files are generated in a subdirectory called ./dagger by default. It seems that most users are either confused by that default, or actively dislike it. I personally always use --source .. I would prefer for . to be the default, and I think most users will agree.

Solution

Change the default for dagger develop --source and dagger init --source to . instead of ./dagger.

Contex...

vivid lintelBOT
#

What is the issue?

I have two modules, ModuleA written in Python using string fields with default values. I depend on this module in my second module written in Golang. It seems that the generated code in dagger.gen.go does not respect the default values of the fields, and requires to set values for these fields again.

Dagger version

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

Steps to reproduce

I've setup https://github.com/skycaptain/dagger-issue-6964 to illu...

#

What is the issue?

I am running a service dagger call ... up. The service, which is a Java app, continuously outputs to stdout. However, from the Dagger TUI, I only see a continuous tail of the log. I have no way to get to the part of the log that has "scrolled off" the screen.

This also affects the output of any "ENTRYPOINT" script. I have a substantial script that outputs a lot to stdout but I can't get to that log when I run the service or after I terminate it.

Dagger versio...

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

Bumps smallrye-graphql.version from 2.7.0 to 2.8.1.
Updates io.smallrye:smallrye-graphql-client-api from 2.7.0 to 2.8.1

Updates io.smallrye:smallrye-graphql-client-implementation-vertx from 2.7.0 to 2.8.1

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You...

#

Bumps com.spotify.fmt:fmt-maven-plugin from 2.22.1 to 2.23.

Release notes
Sourced from com.spotify.fmt:fmt-maven-plugin's releases.

2.23
What's Changed

Update foss-root to 17 by @โ€‹caesar-ralf in spotify/fmt-maven-plugin#187
Bump google format & other dependencies by @โ€‹caesar-ralf in spotify/fmt-maven-plugin#188

Full Changelog: https://github.com/spotify/fmt-maven-plugin/compare/2.22.1...2.23

Commits

a89d6df [maven-release-plugin] prep...

#

Bumps github.com/Khan/genqlient from 0.6.0 to 0.7.0.

Release notes
Sourced from github.com/Khan/genqlient's releases.

v0.7.0
In addition to several new features and bugfixes, along with this release comes reorganized documentation for genqlient. Note that genqlient now requires Go 1.20 or higher, and is tested through Go 1.22.
What's Changed

Add "generic" option to the "optional" configuration for handling nullable types by @โ€‹DylanRJ...

#

Bumps golang.org/x/sys from 0.17.0 to 0.18.0.

Commits

360f961 unix: add API for fsconfig system call
7ff74af unix: drop go version tags for unsupported versions
6b4eab5 unix: suppress ENOMEM errors from sysctl's implementing Uname(uname *Utsname)...
2f2cc5d unix: update IFLA and NETKIT constants with Linux kernel 6.7
See full diff in compare view

[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?depend...

#

Bumps github.com/opencontainers/runtime-spec from 1.1.0 to 1.2.0.

Release notes
Sourced from github.com/opencontainers/runtime-spec's releases.

v1.2.0
Votes: #1242
Additions

config: add idmap and ridmap mount options (#1222)
config.md: allow empty mappings for [r]idmap (#1224)
features-linux: Expose idmap information (#1219)
mount: Allow relative mount destinations on Linux (#1225)
features: add potentiallyUnsafeConfigAnnotations (#1205)
co...

#

Bumps github.com/go-git/go-git/v5 from 5.11.0 to 5.12.0.

Release notes
Sourced from github.com/go-git/go-git/v5's releases.

v5.12.0
What's Changed

git: Worktree.AddWithOptions: add skipStatus option when providing a specific path by @โ€‹moranCohen26 in go-git/go-git#994
git: Signer: fix usage of crypto.Signer interface by @โ€‹wlynch in go-git/go-git#1029
git: Remote, fetch, adds the prune option. by @โ€‹juliens in go-git/go-git#366
git: Add crypto.Signer optio...

#

Bumps github.com/moby/buildkit from 0.13.0-beta3 to 0.13.0.

Release notes
Sourced from github.com/moby/buildkit's releases.

v0.13.0
buildkit 0.13.0
Welcome to the 0.13.0 release of buildkit!
Please try out the release binaries and report any issues at
https://github.com/moby/buildkit/issues.
Contributors

Tรตnis Tiigi
CrazyMax
Justin Chadwell
Sebastiaan van Stijn
Akihiro Suda
Jonathan A. Sternberg
Kohei Tokunaga
David Karlsson
Leandro Santiago
Gabriel Adri...

#

Bumps golang.org/x/tools from 0.17.0 to 0.19.0.

Commits

7656c4c go.mod: update golang.org/x dependencies
5bf7d00 cmd/callgraph: add 'posn' template helper
283fce2 x/tools: drop go1.18 support
7f348c7 internal/versions: updates the meaning of FileVersions.
38b0e9b x/tools: add explicit Unalias operations
a6c03c8 x/tools: update telemetry import (new Start API)
1f7dbdf gopls/internal/cache: add debug assertions for bug report
4d4e802 gopls/doc: address addit...

#

Bumps typescript from 5.3.3 to 5.4.3.

Release notes
Sourced from typescript's releases.

TypeScript 5.4.3
For release notes, check out the release announcement.
For the complete list of fixed issues, check out the

fixed issues query for Typescript 5.4.0 (Beta).
fixed issues query for Typescript 5.4.1 (RC).
fixed issues query for Typescript 5.4.2 (Stable).
fixed issues query for Typescript 5.4.3 (Stable).

Downloads are available on:

NuGet package
...

#

Bumps node-color-log from 11.0.0 to 12.0.0.

Commits

64a00be 12.0.0
7ced8b1 use stderr for default logger output
e7be68b fix test
93badd2 setup tests for different platforms
ef8703f update CI
6642c2a 11.0.2
d01d106 Compatibility to cf workers
213b7d4 bump vesrsion
9bc2e04 Add import statement for Stream in index.d.ts
b442a1b update files
Additional commits viewable in compare view

[![Dependabot compatibility score](https://dependabot-badg...

#
#

Bumps github.com/moby/buildkit from 0.13.0-beta3 to 0.13.0.

Release notes
Sourced from github.com/moby/buildkit's releases.

v0.13.0
buildkit 0.13.0
Welcome to the 0.13.0 release of buildkit!
Please try out the release binaries and report any issues at
https://github.com/moby/buildkit/issues.
Contributors

Tรตnis Tiigi
CrazyMax
Justin Chadwell
Sebastiaan van Stijn
Akihiro Suda
Jonathan A. Sternberg
Kohei Tokunaga
David Karlsson
Leandro Santiago
Gabriel Adri...

vivid lintelBOT
#

Bumps packaging from 23.2 to 24.0.

Release notes
Sourced from packaging's releases.

24.0
What's Changed

Fix specifier matching when the specifier is long and has an epoch by @โ€‹SpecLad in pypa/packaging#712
Clarify version split/join usage by @โ€‹uranusjr in pypa/packaging#725
Default optional metadata values to None by @โ€‹dstufft in pypa/packaging#734
Stop using deprecated/removed keys by @โ€‹dstufft in pypa/packaging#739
Correctly use the ExceptionGroup shi...

#

Bumps pytest-mock from 3.12.0 to 3.14.0.

Release notes
Sourced from pytest-mock's releases.

v3.14.0

#415: MockType and AsyncMockType can be imported from pytest_mock for type annotation purposes.
#420: Fixed a regression which would cause mocker.patch.object to not being properly cleared between tests.

v3.13.0

#417: spy now has spy_return_list, which is a list containing all the values returned by the spied function.
pytest-mock now requires p...

#

Bumps mypy from 1.8.0 to 1.9.0.

Changelog
Sourced from mypy's changelog.

Mypy Release Notes
Mypy 1.9
Weโ€™ve just uploaded mypy 1.9 to the Python Package Index (PyPI). Mypy is a static type checker for Python. This release includes new features, performance improvements and bug fixes. You can install it as follows:
python3 -m pip install -U mypy

You can read the full documentation for this release on Read the Docs.
Breaking Changes
Because the version of typ...

vivid lintelBOT
#

What is the issue?

I am running docker on a remote VM and connecting to it using the DOCKER_HOST env var. I can run docker commands without any issues on the remote host and when I try to call a dagger function I see the dagger engine image getting pulled on the remote host. However, when I try to execute a dagger function, I get an error telling me that the docker daemon is not running.

If I unset DAGGER_CLOUD_TOKEN then everything works as expected and the dagger function is ex...

#

What are you trying to do?

I want to be able to make changes to code locally and see them reflected in my running Dagger services similar to how docker-compose and docker run --v works.

Discussion about this can be found here: #1224583500569514024 message

Why is this important to you?

The introduction of *Service has made it really easy to get a one liner dev environment up and running on my local laptop using the d...

vivid lintelBOT
#

Some big dependency updates for go.mod - we should aim to merge this after v0.11, to allow some time to soak in main.

Some significant updates:

This PR replaces:

vivid lintelBOT
#

Fixes:

This PR adds withAuthToken and withAuthHeader methods to GitRepository so that we can use credentials to clone git repos. Most of the code for doing this is pretty simple :smile: The tests were a bit of a pain (since apparently, as it turns out, we weren't able to clone using dumb http).

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

I am trying to start Dagger Engine on RHEL but it fails to start due to a CNI setup error.

Dagger version

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

Steps to reproduce

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum install docker-ce
sudo systemctl start docker
sudo usermod -aG docker $USER
curl -L https://dl.dagger.io/dagger/install.sh | BIN_DIR=$HOME/....
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

I wan't to make the exported tar for ctr i import, but now I could't added any custom annotation into index.json,
which is important for https://github.com/containerd/containerd/blob/main/core/images/annotations.go#L22`

Why is this important to you?

exported ocr tar can ctr i import directly without manual tag

How are you currently working around this?

No response

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

Problem

When dagger call returns an error, the contents of the error is printed twice to the screen:

  • A first time within the call trace
  • A second time at the end of the output

When the call trace is large, or the error message is long, or both, this makes the output very hard to read. The user will often get lost trying to isolate a useful snippet of text to read.

Solution

Only print the error message once, outside the call trace.

| | Before | After |
| Show err...

vivid lintelBOT
#

What is the issue?

If a version is provided to the install script containing a v prefix, it will fail:

โฏ curl -L https://dl.dagger.io/dagger/install.sh | DAGGER_VERSION=v0.10.3 sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  8674  100  8674    0     0   116k      0 --:--:-- --:--:-- --:--:--  128k
sh debug downloading files into /var/folders/sb/61521rmd5nb...
vivid lintelBOT
#

This fixes the currently failing typescript tests on main: https://github.com/dagger/dagger/actions/runs/8549788696/job/23425690833

This was the intention - but with the node/bun split, we were running all the tests for node, and only one of the tests for bun:

 $ yarn run test:node && yarn run test:bun -g 'Automatic Provisioned CLI Binary'

The other tests aren't designed to run in this environment, so should be skipped.

vivid lintelBOT
#

This allows old clients like dagger v0.10.3 to still connect to and use dagger engine v0.11.0. While this isn't a strict requirement, it's nice to not break this if we don't have to, and based on a couple tests, it seems like this was the only blocker for that.

The other option for this was to introduce an explicit failure for when clients mismatch, but... this is potentially a bit more destructive, this change is pretty minimal.

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What is the issue?

With the latest version, the generated .gitignore file is missing an entry for /internal/telemetry (unless itโ€™s intended?). Is https://github.com/dagger/dagger/blob/fa782c5f25e178e20d58cb7e9610f89bcd38e8ba/core/schema/sdk.go#L331 the right place to fix this?

Dagger version

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

Steps to reproduce

Execute dagger develop in a Go module and see that Git has new untracked files.

Log output

No response

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Related discord thread: https://discord.com/channels/707636530424053791/1225451746868985967

It's unknown if ZFS is actually a culprit somehow, but this hasn't been repro'd on other Debian versions with other filesystems yet, so it stands out as an outlier right now.

Error:

dagger init --sdk=python test2
โœ˜ ModuleSource.asModule: Module! 0.9s
! failed to create module: select: failed to update codegen and runtime: failed to generate code: failed to call sdk module codegen: select:...
ornate vigilBOT
vivid lintelBOT
#

Bumps golang.org/x/tools from 0.19.0 to 0.20.0.

Commits

11c692e gopls/internal/test/marker/testdata: skip hover size tests on 32-bit arm
fc660e5 go.mod: update golang.org/x dependencies
6590f47 internal/gcimporter: renable tests of issue50259.go
f1d5252 gopls/internal/golang: Hover: show wasted % of struct space
951bb40 gopls/internal/test/integration/misc: fix flaky test
c9b0c65 gopls/internal/analysis/fillreturns: skip test if gotypesalias=1
c623a28 gopl...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Before this, there was no way to get the version of an engine - this is really useful if the engine is running remotely, and you want to make a query for it to get it programatically (it's always been possible by analyzing logs, etc).

One of my main use cases is for working out what version of dagger the playground is using: https://play.dagger.cloud/playground - there's actually no way to do that right now (this PR would let you).

What feels frustrating is that `checkVersionCompatibi...

#

What is the issue?

If you type any dagger command in a git worktree, you'll get the following Warning message:
WRN failed to get repo HEAD err="reference not found"

The error could potentially come from here:
https://github.com/dagger/dagger/blob/95b4ce550a2dcd1fa73f8b55199c7e9ed0ef1fc3/telemetry/labels.go#L109-L113

Dagger version

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

Steps to reproduce

1 - Clone a repository with the flag --bare:
`git clone --bare...

#

See the rationale in https://github.com/dagger/dagger/pull/7013, https://github.com/dagger/dagger/pull/7001#discussion_r1549487821. TL;DR, during the release of v0.11.0, we broke compatibility with older clients, but didn't really have the tooling to make sure that this errored cleanly out.

This PR ensures that this doesn't happen again - both the client and the server are able to specify a minimum version, defined in engine/version.go. If a client/server doesn't satisfy these constrai...

vivid lintelBOT
#

Take the following go module:

package main

import (
	"context"
	"strings"
)

type Playground struct{}

func (m *Playground) Foo(ctx context.Context, progress string) (string, error) {
	return strings.ToUpper(progress), nil
}

On call:

$ dagger-dev call foo --progress=plain
Connected to engine ff7f91f8a66b (version 4b825dc642cb6eb9a060e54bf8d69288fbee4904)
โœ” connect 0.2s
โœ˜ initialize 3.5s
! flag already exists: progress
  โœ” ModuleSource.resolveFromCall...
vivid lintelBOT
#

Python Modules now (since v0.11.0) create a requirements.lock file by default, but does this only on dagger init (or develop if thereโ€™s no pyproject.toml), so itโ€™s up to the user to update manually from then on:

uv compile --generate-hashes -o requirements.lock sdk/pyproject pyproject

This can create a catch 22 situation where the SDKโ€™s dependencies have changed, you need to codegen to get th...

vivid lintelBOT
#

Itโ€™s surprising that you can create a module, make some functions, run them, remove main.go and itโ€™ll still run, just with the default ones from the template.

Instead of stopping dagger call from doing codegen automatically, I think it would be more reasonable to just not use the template unless youโ€™re using --sdk for a new module. So if you remove main.go or some other file, it errors rather than re-creating on an ephemeral container, which is more surprising.

The client will s...

vivid lintelBOT
#

What is the issue?

Fail to set InstallPath on Windows with PowerShell v7.4.1

Dagger version

dagger v0.11.0

Steps to reproduce

$script = Invoke-WebRequest -UseBasicParsing -Uri https://dl.dagger.io/dagger/install.ps1
$params = "-InstallPath A:\dagger"
"$script $params" | Invoke-Expression

Log output

-InstallPath:
Line |
  78 |   -InstallPath A:\dagger
     |   ~~~~~~~~~~~~
     | The term '-InstallPath' is not recognized as a name of a cmdlet, functi...
vivid lintelBOT
#

This PR adds a new serializer for graphql input. The previous serializer (serde_json) was just a regular json parser, however, as graphql input functions aren't strictly json (missing quotes on keyes, and enums) it turned out to not be a great fit, and couldn't implement a lot of the functionality we wanted.

As such this pr introduces a purpose built serializer which can handle this.

This should also fix: #5928

#

What is the issue?

When an error occurs. I.e. a .sync().await? fails we get a bloated error response back from the dagger engine, which contains details the client shouldn't need to see.

Such as

[78.0s] error[E0635]: unknown feature `stdsimd`

62: [78.0s]   --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/ahash-0.7.7/src/lib.rs:33:42

62: [78.0s]    |

62: [78.0s] 33 | #![cfg_attr(feature = "stdsimd", feature(stdsimd))]

62: [78.0s]    |           ...
vivid lintelBOT
vivid lintelBOT
ornate vigilBOT
#

We're currently considering using Dagger for production. As our main language is Python, we want to write our Dagger modules in Python. At the moment, we're using the default Python SDK that Dagger provides. This SDK fetches python:3.11-slim from Docker Hub.

However, we've recently encountered the "Too Many Requests" limit on Docker Hub while trying to scale for production. We usually bypass this issue by proxying external images through our Artifactory server. The problem is, the image ...

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

Installed dagger using "brew install dagger" on macos M1 arm64 chip.

From this: https://daggerverse.dev/mod/github.com/kpenfound/dagger-modules/golang@57352e06a1cfbcb5307c009d37c0201b2719b935

It says "dagger install github.com/kpenfound/dagger-modules/golang@57352e06a1cfbcb5307c009d37c0201b2719b935". Then I get:
Error: failed to get configured module: no dagger.json found in directory . or any parents up to git root

Dagger version

dagger v0.11.0 (regist...

ornate vigilBOT
vivid lintelBOT
#

What is the issue?

The startup time for Dagger Functions takes a long time, even on subsequent runs. It seems to be the step where the function is prepared, compiled, dependencies fetched. Watching the logs, once the function code is reached, it goes very quickly

Dagger version

0.11.0

Steps to reproduce

cd tmp 
โžœ  tmp git:(main) โœ—  
dagger init --sdk=go repro-go
12:01:19 WRN no LICENSE file found; generating one for you, feel free to change or remove license=Apache-2....
vivid lintelBOT
#

What happened? What did you expect to happen?

I initialized my dagger module with dagger init --name=simple-frontend --sdk=go. Now i modified the available Functions and removed the default generated ones. Now the dagger.gen.go contains errors, because of referencing the default functions initially generated with dagger init (ContainerEchoand GrepDir). What is the intended usage of the dagger.gen.go file. I didn't found a documented way to regenerate the file?

vivid lintelBOT
ornate vigilBOT
vivid lintelBOT
#

To reproduce on main:

$ dagger call --source=. sdk go generate entries
sdk
(hangs here, even though the task is complete)

Dumping trace logs on the engine:

time="2024-04-08T11:58:34Z" level=trace msg="server removed" client_call_digest= client_hostname=daggerdoer client_id=jui8v1z5en9a42r1l9sncx1zp server_id=cl0so4twc5tpx6ggse1v4rpxa
time="2024-04-08T11:58:34Z" level=debug msg="session call done" client_call_digest= client_hostname=daggerdoer client_id=jui8v1z5en9...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Follow-up to #6843.

Fixes:

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

When I start a dagger call with the --debug flag, it would be helpful to not automatically clean up the terminal but rather leave the full logs visible.

Why is this important to you?

Even with --debug enabled I did not find a simple way to observe a dagger call invocation in the terminal with greater detail.

How are you currently working around this?

Trying to spot lines before they are deleted or clicking through all command invocations in the da...

vivid lintelBOT
#

What is the issue?

While developing locally, I often use --progress=plain for long-running tasks. This allows me to better understand what's happening and to detect early warnings. With prior releases, this worked well, as the logs were streamed to my console and I could follow along with the build. However, it appears that there's a regression with v0.11.0. Now, when I run any dagger --progress=plain call ... command, I only see Connected to engine 14def8fb732a (version v0.11.0) for an ...

ornate vigilBOT
#

I was using GO SDK, connected to Dagger engine. In one session, firstly run a shell command in container A, and then run a shell command in container B.
The pull images operations were cached for small images like alpine, busybox etc.., but not cached for some big images. Anything I can do the cache image pull operations, since it's time consumed.

Here's my environment
SDK: Dagger GO SDK
OS: mac OS
Docker: Docker Desktop 4.20.0 (Engine 24.0.2)

vivid lintelBOT
#

What are you trying to do?

Need to know engine version that a module was built with so can know if a module is compatible with my engine version.

Want to filter for modules by engine version.

Why is this important to you?

Modules created with an engine version different from the one I'm running might not behave properly.

How are you currently working around this?

You can look at the dagger.json in a module's git repo.

vivid lintelBOT
vivid lintelBOT
#

Follow up to:

  • #6884

To simplify not needing to install the SDK's dependencies for codegen, the Python codegen script has been moved into an independent package with a minimal dependency.

Added a codegen introspect subcommand avoid the need for the Python codegen to have HTTP capabilities in order to introspect from the API directly.

This helped simplifiy the runtime module. Now, if a module has a requirements.lock file, it'll be re-compiled automatically (without upgrading pac...

vivid lintelBOT
#

Right now you can only set the module's name at dagger init either with --name or by default the name of the containing directory will be used.

I found this odd and expected to be able to do this:

dagger init
dagger develop --sdk=go --name=foobar --source=.

Side note: since dagger init assumes . I'd want dagger develop to assume source=. also.
https://github.com/dagger/dagger/issues/6963

Instead, I got this error with the above:

dogfish โžค dagger init...
vivid lintelBOT
#

Still some cleanup left, but good enough for feedback. TODOs:

  • [ ] finish description
  • [ ] dedupe some of the distro ca installation code
  • [ ] make ca installation/uninstallation non-fatal and cleaned up in case of failure partial way through
  • [ ] make final call on whether to only selectively enable or just apply to all containers when custom CAs are installed in the engine (at /usr/local/share/ca-certificates)

This adds support for automatic installation of custom CA cer...

vivid lintelBOT
#

This data allows the UI to track where lazy operations came from so we can tie them back to the call site that installed them (i.e. withExec). This visualization angle is super useful when you're trying to gauge the "cost" of

Something like this (note the "shadow bars" - UI subject to change):

image

NOTE: As a prerequisite, I moved the ftp_proxy hackery back to Container.WithExec instead ...

vivid lintelBOT
vivid lintelBOT
#

Came across this while working on continued modularization - ideally, we want to end up in a place where all of our CI is just a dagger call away! Then we can use https://github.com/dagger/dagger-for-github, and dogfood that more.

This step is more fiddly to modularize (which we want to do so it would show up in dagger cloud) - I think it can be done, but I think we might also just be able to remove it. It was added quite a while ago in https://github.com/dagger/dagger/pull/3785, to he...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What is the issue?

Bash completion is failing since version v0.11.0 with the following error: Completion ended with directive ShellCompDirectiveNofileComp
More details in this discord thread https://discordapp.com/channels/707636530424053791/1227602359547592745

Dagger version

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

Steps to reproduce

Install version v0.11.0
try to complete in a bash shell a dagger command.

Log output

No response

vivid lintelBOT
#

What is the issue?

Hey there,

After upgrading to v0.11, I noticed that when using --progress plain, the stderr is outputted only at the end of the run. Why is this important? When running in CI, there will be no feedback given to the user (unless the go code explicitly writes to stdout/err) until the end of the run. This may take minutes.

Expected: the dagger/container/services stderr is streamed as it generated like in <= 0.10

Actual Behaviour: the dagger/container/services ...

#

What is the issue?

With dagger v0.11.0, when running dagger develop and the module is in a folder called .dagger the package main/internal/telemetry is not added to the dagger.gen.go fille. The imports are as follows.

import (
	"context"
	"encoding/json"
	"fmt"
	"log/slog"
	"os"

	"main/internal/dagger"

	"go.opentelemetry.io/otel"
	"go.opentelemetry.io/otel/attribute"
	"go.opentelemetry.io/otel/sdk/resource"
	semconv "go.opentelemetry.io/otel/semconv/v1.4.0"
...
vivid lintelBOT
#

In https://github.com/dagger/dagger/pull/6835, we finally removed _EXPERIMENTAL_DAGGER_CLOUD_TOKEN, and replaced it with DAGGER_CLOUD_TOKEN.

However, we were exploiting an undocumented use of this - we could use DAGGER_CLOUD_TOKEN to enable cloud cache + telemetry, while we could use _EXPERIMENTAL_DAGGER_CLOUD_TOKEN to just enable telemetry for security reasons. We want all PRs to use telemetry (so we can get traces), but we don't want all PRs to use caching - since that could intr...

vivid lintelBOT
#

The previous image was just a manifest explicitly only for amd64:

$ docker buildx imagetools inspect node:21.3-alpine@sha256:cacb4e3a208aa34e0f821b56256e446ad984960d4f9aca66c7026e16b87db89f
Name:      docker.io/library/node:21.3-alpine@sha256:cacb4e3a208aa34e0f821b56256e446ad984960d4f9aca66c7026e16b87db89f
MediaType: application/vnd.docker.distribution.manifest.v2+json
Digest:    sha256:cacb4e3a208aa34e0f821b56256e446ad984960d4f9aca66c7026e16b87db89f

$ docker buildx imagetools i...
vivid lintelBOT
#
  • Bun cache volume should include the version number
  • tsx installation should be part of the base image (so cannot be cache invalidated)
    • @TomChv I think there's some more low-hanging fruit here - the pipeline here doesn't seem to cache in the expected way, we should ensure that wherever possible we can install the dependencies with as few cachebusters around as possible
vivid lintelBOT
vivid lintelBOT
#

What is the issue?

As a follow-up of this discord thread: https://discord.com/channels/707636530424053791/1227300888050139146 and this previous issue: https://github.com/dagger/dagger/issues/6462, seems like dagger call is randomly uploading the context in consecutive calls.

We confirmed this happens in all v0.10.{2,3} and v0.11.0 versions.

Dagger version

v0.11.0

Steps to reproduce

As described in: #1227300888050139146 message...

vivid lintelBOT
#

At the moment our CI costs have gotten quite high. As a way of optimizing (although we are unsure of how much this will help us) we want to reduce the amount of parallel jobs running. The current setup is allowing all jobs of all commits in a PR to complete, even when new commits have been pushed. While this can certainly be useful, it is way too costly. Each time we run jobs for a pull request in our legacy CI we are requesting approximately 64 cores and 384 Gi of memory. This is definitely ...

vivid lintelBOT
#

What is the issue?

Running dagger develop --sdk=go fails if under a go.mod with go 1.22 (but works with go 1.22.1)

#1227832788825407488 message

Dagger version

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

Steps to reproduce

$ mkdir temp
$ cd temp
$ cat > go.mod << EOF
module example.com/temp

go 1.22
EOF
$ dagger init
$ dagger develop --sdk=go

Log output

โœ˜ ModuleSource.as...

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

As of v0.11.0, running dagger version returns a warning when used in a git worktree. I do all my development in git worktrees and this is annoying. This did not happen before:

BEFORE:

โฏ dagger version
dagger v0.10.3 (registry.dagger.io/engine) darwin/amd64

AFTER:

โฏ dagger version
dagger v0.11.0 (registry.dagger.io/engine) darwin/amd64
20:23:06 WRN failed to get repo HEAD err="refe...
ornate vigilBOT
vivid lintelBOT
#

What happened? What did you expect to happen?

๐Ÿ‘‹ Have been playing with dagger by building my own module for running Terraform and other scripts. Am running into a weird issue where previous deploy / destroy runs have been cached to the point where Dagger just shows the previous successful run rather than deploying infrastructure again even though it no longer exists. In essence making multiple runs quite tricky. While searching for a solution I found this in the archive as a workaround t...

vivid lintelBOT
#

What is the issue?

When you use a function name that contains a protocol name like TCP, UDP, IP, HTTP, HTTPS, many users would assume they should use PascalCase for their public function names, for example, TcpTest or HttpsTest, but when those function names are run through codegen in the Go SDK at least, certain substrings containing protocol names are upcased. So the functions above become TCPTest and HTTPSTest.

On the other hand, a function name like FooTest results in `F...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

This issue aims to regroup all my tests and dig into the SDK performances improvement.

Init

  • Env: compiled a binary from main: (bdce95d0abfa9014a35f5e3962a64afce03d5fca)
  • Use dagger cli v0.11.0
  • Use latest dagger cloud
time dagger init --name=perf --sdk=typescript                                              
Initialized module perf in .
dagger init --name=perf --sdk=typescript  0.98s user 0.73s system 11% cpu 14.829 total
โžœ  perfs git:(main) โœ— time dagger function...
vivid lintelBOT
#

Fixes #7045 (nightmare issue yay)

Essentially, with the new TUI, we were failing to set the TUI to raw mode. The reason for this was that we were passing a non-input buffer to containerd/console (through os.Stdin). Unlike on *nix, on windows, the raw mode we were trying to set is not interchangeable between stdin/stdout.

Something is insanely weird about what bubbletea is doing here - it's making loads of funky assumptions about how terminals can be constructed, and honestly I'm not...

vivid lintelBOT
#

Following https://github.com/dagger/dagger/issues/7093, I found that most of the time is spent downloading dependencies, it seems I can drastically reduce the download time using yarn and the --production flag to only install production dependencies.

This is a first step toward improving TS performances, we might switch to pnpm later, this require some tests though because I'm hitting an issue (see https://github.com/dagger/dagger/issues/7093#issuecomment-2057038646)

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Elixir publish --hex-apikey had a typo:

$ dagger call --source=. sdk elixir publish --help
Publish the Elixir SDK

Usage:
  dagger call sdk elixir publish [flags]

Flags:
      --dry-run
      --hex-apikey Secret
      --tag string

Global Flags:
  -d, --debug             show debug logs and full verbosity
      --json              Present result as JSON
  -m, --mod string        Path to dagger.json config file for the module or a directory containing that file....
vivid lintelBOT
vivid lintelBOT
#

What is the issue?

Coming from here: https://discord.com/channels/707636530424053791/1229798907362414673

Looks like our helm chart doesn't really work with the latest version of Dagger and it's pinned to a v0.9.x engine. We should try to keep it updated every time we release a new version.

cc @gerhard @matipan

Dagger version

dagger v0.11.1

Steps to reproduce

Follow the guide here: https://docs.dagger.io/integrations/104820/kubernetes

Try updating the engine image f...

vivid lintelBOT
#

Right now if something goes wrong internal to the shim before all the OpenTelemetry plumbing can be wired up, you just get an exit status 125 with no other output. (The shim currently has to manually send the command's stdout/stderr to OpenTelemetry logging, so there are extra moving parts.)

I added a "break glass to debug telemetry" bit that prints Buildkit logs to stderr, but didn't make it configurable, figuring it would only be useful to me while I bootstrap the OpenTelemetry stack.
...

vivid lintelBOT
#

Fixes #6943 (partially for now, but foundation)

Details of current draft implementation

@helderco we had a sync, but I might have forgotten some parts ahah. Feel free to tell if I'm completely off on some interpretation / implementation:

  • [x] Add line break between error and usage
    This has been intentionally added in cmd/dagger/functions.go

  • [x] Style headings inย BOLD UPPERCASEย to help break sections visually
    A new helper function has been added and the corresponding t...

vivid lintelBOT
vivid lintelBOT
#

This patch updates all the go base images to versions that have go 1.22.

Note! We can't update the version used to build runc, due to an upstream incompatability - however, because the build is separate, we can keep building it using an older version of go.

Also note, we can't yet bump to actually use 1.22 in our code by updating the go.mod. This is because the ci package must continue using 1.21 until the next release (insert elaborate codegen reasons here) - and then the ci pack...

vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

When running integration tests, we have noticed that even when a run is fully cached, the service will still be started and instantly shut down without the said integration tests running since the integration container and the services it is bound to are already cached.

ctr (cached) --> service a (cached)
ctr (cached) --> service b (cached)

I am aware this is a known behaviour, but is there a reason why the service containers are started anywa...

vivid lintelBOT
#

What is the issue?

building a Dockerfile with dagger doesn't show any of the outputs the Dockerfile currently performs. This used to be the case before v0.11.x so it's very likely a regression on the new telemetry solution.

Dagger version

v0.11.1

Steps to reproduce

FROM alpine

RUN find /
func (m *Test) Build(ctx context.Context, df *File) (*Container, error) {
	return dag.Directory().WithFile("Dockerfile", df).
		DockerBuild().Sync(ctx)
}
...
vivid lintelBOT
#

What is the issue?

When running dagger init in an emply directory, it will fail with an error message if the directory does not have a .git directory.

There is another issue that is related but not the same, I'll file another issue for that one and link it back.

I traced it back in the dagger codebase to the buildit module's filesync.go. Based on something I ran into years ago, my suspicion is that the CreateFile needs either a UNC path or double slashes on Windows. I wasn't ab...

#

What is the issue?

This is a semi followup to #7114 with what looks like a different cause. If one follows the steps in that issue, you'll eventually end up with a git repo that has a dagger.json in it. Running 'dagger init' there will throw a duplicate module error.

Dagger version

dagger v0.11.1 (registry.dagger.io/engine) windows/amd64

Steps to reproduce

mkdir dagger-test
cd .\dagger-test\
dagger init
git init
dagger init
New-Item -Type File -Path dagger.json
dag...
ornate vigilBOT
#

Running a simple script with 0.11.1 results in lots of error messages like this:

Transient error StatusCode.UNAVAILABLE encountered while exporting traces to localhost:4317, retrying in 1s.
Transient error StatusCode.UNAVAILABLE encountered while exporting traces to localhost:4317, retrying in 2s.
Transient error StatusCode.UNAVAILABLE encountered while exporting traces to localhost:4317, retrying in 4s.
Transient ...
vivid lintelBOT
vivid lintelBOT
#

Fixes #6923 #7114 (second time's the charm hopefully).

Right. Descriptions are split up into commits to make it a bit easier to understand, but TL;DR, there were two main issues:

  • Paths weren't being correctly decoded after being encoded on the wire - I should have caught this and didn't (my bad). The correct way to do this is to handle the encoding/decoding as close as possible in the code to sending/receiving, then it doesn't sneak everywhere through the code.
  • Windows has differen...
vivid lintelBOT
vivid lintelBOT
ornate vigilBOT
ornate vigilBOT
vivid lintelBOT
#

dagger query is not the main entrypoint of the dagger CLI anymore. Even though the special template made some sense, it is a code duplication to maintain. With the following changes (titles in bold, etc ...) and the remaining presence of the example on the command's help, it does make sense to remove it and keep a single source of truth

New output

./dagger query --help
Send API queries to a dagger engine.

When no document file is provided, reads query from standard in...
vivid lintelBOT
vivid lintelBOT
#

Part of the de-clutter CLI implementation: https://github.com/dagger/dagger/issues/6943#issuecomment-2021310987.

When querying dagger call --help and dagger functions --help without being in a module or for an inexistant function, an error is being raised. This commit adds a newline between the two, as it was hard to distinct between them

Example:

./dagger -m . functions toto --help
โœ” initialize 41.2s

Error: no function 'toto' in object type 'Dagger'
#

Problem

When calling Directory.export() or File.export() from the CLI, the output is confusing: it just prints true without context or explanation.

Example:

$ dagger call \
 -m github.com/shykes/core@770692357aeac6bf898f28177614763ae5cc620c \
 directory \
 export
true

Solution

Change the CLI output to something less confusing. I propose no output, which is the expected convention for a command that completes successfully.

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

One of the action items discussed in https://github.com/dagger/dagger/pull/7107#issuecomment-2061525961

Reposition flags below commands to find them more easily on big dagger call outputs.

New output

 ./dagger -m github.com/levlaz/daggerverse/mariadb@v0.2.1 call base --help
Return MariaDB Container

USAGE
  dagger call base [flags]
  dagger call base [flags] [command]

FUNCTION COMMANDS
  as-service                    Turn the container into a Service.
  as-ta...
vivid lintelBOT
#

There should be no actual behavior changes here, this just brings in the changes that were merged to fsutil master that we were previously pulling from my fork (for the windows fixes).

Specifically, see these 3 PRs:

ornate vigilBOT
ornate vigilBOT
#

The script I am running is in the gist that I linked to in the original question.

If I run that script with 0.10.3, then I get a bunch of console output, along these lines:

โ ™ Downloading dagger CLI1: connect
โ ‹ Creating new Engine session1: starting engine 
โ ‡ Creating new Engine session1: starting engine [1.40s]
1: starting engine [0.06s]
1: starting session 
โ ‹ Creating new Engine session1: [2.28s] OK!
1: starting session [0.10s]
1: connect DONE

5: resolve image config for...
#

Quick tip: you don't need to pass the client around instance anymore, see the Global Client.

I don't know if this is a feature of 0.11.1, or something to do with the logging...

It's from dagger 0.11, not Python specifically. You should see some progress while it's happening and in the end it goes away to leave only the script's own output.

If you run the script through dagger run you have more control. You can...

#

Quick tip: you don't need to pass the client around instance anymore, see the Global Client.

:smiley:

You should see some progress while it's happening and in the end it goes away to leave only the script's own output.

Yea, I saw literally that one line flash up and no other lines!

Ok, if I run it via dagger run in the way you say (didn't know I could do that!) then I do get more output.

vivid lintelBOT
#

What are you trying to do?

Dagger 0.11 made changes to the console output which I believe to be a large downgrade.

What I used to do:

I would run my pipeline without the dagger binary, simply running python main.py. This would print the output from the container as well as my program output (i.e., calls to logger.info()) to the console in real time. Once the process was complete, all the container logs + my own would still be clearly visible for reference.

I found this a...

vivid lintelBOT
#

:tada: This fixes DaggerRun, so hopefully we can have our CI go green again! (cc @matipan @gerhard who helped investigate)

This was "introduced" in #7069, when we changed our plain progress to include colors - in conjunction with the new TUI output, this means that we don't have a plain "Container.From", instead, we have magical control codes strewn throughout it. The trick to fix this, is to just set NO_COLOR, and the test passes again!

However! There's another issue here - this test...

vivid lintelBOT
#

More context in:

It affects Python users not using modules in v0.11.1 (dagger run python script.py or python script.py). In the meantime, been suggesting that they turn telemetry off:

import logging
import opentelemetry

# TODO: Remove when **not** in v0.11.1
logging.getLogger("opentelemetry").propa...
vivid lintelBOT
vivid lintelBOT
#

When nested execs (i.e. execs that can call back to the dagger API) were originally added, they weren't safe since they gave full blown access to the original caller's FS, but that's no longer the case. We can instead make this behavior the default for convenience and instead have a flag for opting out.

There's one last pre-req first, which is handled as part of https://github.com/dagger/dagger/pull/6916. That PR results in nested execs connecting back to the same server (among many other ...

vivid lintelBOT
#

One of the action items discussed in https://github.com/dagger/dagger/pull/7107#issuecomment-2061525961.

Unifies the DX around usage across all commands. The convention follows the standards (gh / git CLIs) as well as the defaults from cobra.

The grammar is as follow:

  • []: optional
  • <>: user input, to differenciate with static args
  • ...: one or more

Another point: [flags] shall always be positioned after the subcommand

This PR applies the grammar everywhere for consistency. ...

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

Investigation after a report by @sagikazarmark in:

It appears that dagger init --sdk go overwrites an existing go.mod when run in a context directory with a go package. The context directory is usually the directory that has .git, but if no parent directory has one, it defaults to the directory where dagger.json is.

Also tested on v0.10.3 and got the same result.

Dagger versi...

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

Using functions that can error in Container.With is a bad idea. So, what we can do is to put the actual computation into an error group (which has the convenient little side-effect that they all get computed in parallel, hopefully improving build times).

This lets us remove the panic, which was crashing the binary. Because of (I think) telemetry draining, this meant that the client job hung forever on this kind of failure.

cc @helderco I know we discussed previously :tada:

vivid lintelBOT
#

The default is 360 minutes (6 hours) - at this point, something has definitely gone wrong for us, so we should explicitly fail.

Also, for jobs that are known to be short, we can cap at 10 minutes: specifically SDK linting + testing jobs.

This would have prevented long run-away jobs like we discovered with the failed typescript linting intersecting with a crash (causing a client hang):

ornate vigilBOT
#

I may be missing something simple, but I'm currently struggling with Directory.glob returning an empty list instead of the files. Consider this example where I want to match all the files in the deploy/sdk directory. Note the different tmp-* directories:

mydir = (
    dag.directory()
    .with_new_file("build/tmp-build-a/deploy/sdk/test.txt", "FOO")
    .with_new_file("build/tmp-build-a/deploy/sdk/test.manifest", "BAR")
    .with_new_file("build/tmp-build-b/deploy/ipk/...
vivid lintelBOT
vivid lintelBOT
#

DEV-3403

This is the "proper" implementation of #6739. This allows us to preserve the original scalar name.

Implemented functionality:

  • [x] TypeDefs have an AsScalar field, so that they can be connected to their original value.
    • For example, this allows the CLI to know that a flag is a dagger.Platform flag. Eventually, this could allow us to have a special value, like "current" as a shorthand to represent the client platform.
  • ...
vivid lintelBOT
#

What are you trying to do?

Expose the GraphQL client directory from the dag variable

See https://discord.com/channels/707636530424053791/1230428619755753553

Why is this important to you?

Allow greater flexibility and special use case like calling other module

How are you currently working around this?

Current workaround from [this discord message](#1230428619755753553 message)

connect(
  async (client:...
vivid lintelBOT
#

What is the issue?

I ran my CI script dagger run npx tsx ci.mts and it made my block cursor disappear.

Dagger version

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

Steps to reproduce

dagger run npx tsx ci.mts with some Docker stuff that fails.

Log output

โœ˜ Container.stderr: String! 47.2s
! failed to compute cache key: write /var/lib/dagger/runc-overlayfs/snapshots/snapshots/36/fs/usr/lib/aarch64-linux-gnu/libx265.so

        date: [ 'Mon, 22 Ap...
vivid lintelBOT
#

What is the issue?

The dagger publish command does not work as expected when you are working with git tags and puts the daggerverse into a strange state.

Here is what I expect.

Running dagger publish or dagger publish $TAG inside of a dagger module should publish the latest tag into the daggerverse.

Here is what happens.

  1. If I run dagger publish it will publish the most recent commit and even find the correct git tag that shows up in the daggerverse UI. But tryi...
vivid lintelBOT
vivid lintelBOT
#

What happened? What did you expect to happen?

Dear Dagger Development Team.

Thank you for this amazing toolkit, this project in actuality creates new dimension into CI/CD and software development. I really like all the concepts and different language SDKs.

So my question is, I was trying to integrate dagger into our current system as a controller for our testing pipeline, where we need to evaluate interactions between dozens of services. First I wanted to do this kind of testin...

vivid lintelBOT
#

What happened? What did you expect to happen?

I'd like to pass a container from one module to another. I'm currently doing something like this:

TTL_SH_CONTAINER=$(dagger -m github.com/Dudesons/daggerverse/infrabox call terragrunt container \
...
publish --address ttl.sh/terragrunt-$RANDOM)

dagger -m github.com/Dudesons/daggerverse call terragrunt \          
with-container --ctr $TTL_SH_CONTAINER \
...

This definitely works at the moment, but I wish I could keep it loc...

vivid lintelBOT
ornate vigilBOT
#

:wave: seems like a bug in the glob pattern matching function. According to this: https://github.com/moby/patternmatcher/blob/main/patternmatcher_test.go#L140 that pattern should work. I even cloned that repository and added the following test case:

	tests := []matchesTestCase{
		{"build/tmp-*/deploy/sdk*", "build/tmp-build-a/deploy/sdk/test.manifest", true},

and this passed.

It's very likely an issue coming from https://github.com/marcosnils/dagger/blob/9baaa467f14b...

vivid lintelBOT
#

Discussed in https://github.com/dagger/dagger/discussions/7156

Originally posted by skycaptain April 22, 2024
I may be missing something simple, but I'm currently struggling with Directory.glob returning an empty list instead of the files. Consider this example where I want to match all the files in the deploy/sdk directory. Note the different tmp-* directories:

mydir = (
    dag.directory()
    .with_new_file("build/tmp-build-a/deploy/sdk/test.txt", "FOO...
vivid lintelBOT
#

One of the action items discussed in https://github.com/dagger/dagger/pull/7107#issuecomment-2061525961. It is the first one discussed from the
Branched from https://github.com/dagger/dagger/pull/7143, needs to be merged prior this one.

  1. Rename all the flag mentions to "options", as proposed by Helder in https://github.com/dagger/dagger/pull/7107#issuecomment-2061525961
  2. Remove the automatic [flags] append on all commands: https://github.com/dagger/dagger/pull/7107#discussion_r15690...
vivid lintelBOT
#

Problem

Dagger has no direct equivalent to this simple Dockerfile line: ENV PATH=foo:${PATH}.

Solution

Add an optional argument Container.withEnvVariable to allow interpolating the current container's env variables into string arguments. And possibly, add it to other Container functions as well.

The default for this new argument should be true, I think. In other words, interpolation should happen by default.

Then this would work out of the box:

func ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

Partially inspired by https://github.com/moby/buildkit/pull/4828 upstream.

Unused parameters can sometimes indicate weird issues, at the very least that are a bit of a code smell (additionally, gopls in vscode loves to flag these, which is the main reason I wanted to clear them up lol).

Thankfully, none of these are significant, there are no hiding bugs, it's just a little bit of a tidy up.

unparam definitely seems to be optimized for less "noise", and doesn't pick up on every un...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

  • Expose functions as json in dagger functions.
[
  {
    "Name": "containerEcho",
    "Description": "example usage: \"dagger call container-echo --string-arg yo stdout\"",
    "ReturnType": {
      "Kind": "OBJECT_KIND",
      "Optional": false,
      "AsObject": {
        "Name": "Container",
        "Functions": null,
        "Fields": null,
        "Constructor": null,
        "SourceModuleName": ""
      },
      "AsInterface...
#

What is the issue?

Today we have a note box in the docs that says

https://docs.dagger.io/manuals/developer/go/264203/functions/

NOTE
The context and error return are optional in the module's function signature; remove them if you don't need them.

but not all developers will know when they need them or not.

In fact we have a Hello function that uses context, but doesn't need it, which is confusing.

We should expand to say something like

NOTE
The cont...
vivid lintelBOT
#

What is the issue?

I have a module, where using credentials is optional, e.g.

import dagger
from dagger import function, object_type

@object_type
class Test:
    username: str | None = None
    token: dagger.Secret | None = None

    name: str | None = None

    @function
    def call(self) -> str:
        return f"Hello, {self.name}!"

When I call this module like this, I get a valid response:

$ MY_TOKEN="very_secret_variable" dagger call -m tes...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

What is the issue?

We're using service containers as a form of basic local up for our developers. This means that we've got a basic set of features available during either development or a local go test ./... that can use these databases.

client.
Container().
From("rabbitmq").
WithExposedPorts(...)
AsService().
Start(ctx)

What we've experienced is that these tests run fine once, but on the second run they cannot form a connection with the service containers. We...

vivid lintelBOT
#

Alternative solution to #7183

Discussed in https://github.com/dagger/dagger/issues/6943#issuecomment-2067514623.

Example

dagger -m github.com/levlaz/daggerverse/mariadb@v0.2.1 functions base --help

Before

Error: no function '--help' in object type 'Container'

After

List available functions in a module.

This is similar to `dagger call --help`, but only focused on showing the
available functions.

USAGE
  dagger functions [flags] ...
vivid lintelBOT
#

What is the issue?

On errors the dagger-rust sdk doesn't understand how to parse the errors from the graphql endpoint

Dagger version

dagger v0.10.2

Steps to reproduce

Simply get a rust dagger program to crash

Log output

Error: failed to query dagger engine: http error: Failed to parse response: Error("invalid type: sequence, expected a string", line: 1, column: 211). The response body is: {"errors":[{"message":"resolve: container: withFile: withExec: withEntrypoint...
vivid lintelBOT
#

What is the issue?

We've hit this error a few times in https://github.com/dagger/dagger/actions/runs/8821414426/job/24217223788?pr=7082, part of:

2024-04-24T18:36:16.3979153Z 117: DONE 1325 tests, 3 skipped, 2 failures in 605.184s
2024-04-24T18:36:16.3979462Z 
2024-04-24T18:36:16.3979728Z panic: runtime error: invalid memory address or nil pointer dereference
2024-04-24T18:36:16.3980302Z [signal SIGSEGV: segmentation viola...
vivid lintelBOT
#

Fixes #7145 - essentially, we need to a more careful merge of go.mod and go.sum when adding dependencies, instead of replacing them.

Essentially, when doing a dagger init --sdk=go in an existing go repo, we were following a code path that meant we weren't using the builtin go.mod/go.sums at all, and were instead relying on go mod tidy to do something reasonable (which is also slower!).

Additionally, when using dagger develop, we never preserved go.sum, always completel...

vivid lintelBOT
vivid lintelBOT
#

Is this an intermediary step that we can take towards migrating to new CI runners? Related to:

If the Engine & CLI workflows passes, I would be tempted to merge this before the other PR. The focus is to migrate off the legacy CI as soon as possible.

Trade-offs:

  • If we keep the current DAGGER_CLOUD_TOKEN, we will not be able to use the Cloud Cache in PRs coming from forks
  • If we add the DAGGER_CLOUD_TOKEN secret, this will not be avai...
vivid lintelBOT
#

Problem

There are two types of Dagger modules: those that are standalone software projects, and those that exist in the context of a software project. Let's call those standalone modules and contextual modules, respectively.

Dagger is designed to support both, which is good, but causes friction for users in some areas.

  • Contextual modules almost always need access to their context directory. Today this requires an explicit argument, which is verbose.
  • Contextual modules oft...
vivid lintelBOT
vivid lintelBOT
#

What are you trying to do?

First class or at least decent support for pushing to Git repositories.

Why is this important to you?

Dagger already has first-class support for pulling from Git repositories (even if private repo support isn't trivial).

It's often important to push changes back to a repository. A couple use cases in mind:

  • Regenerate SDKs from API descriptors upon change
  • Update GitOps manifests when a new version is out

Unfortunately, feeding credentials int...

vivid lintelBOT
vivid lintelBOT
#

Previously, we would mark a parameter as optional in two cases:

  • With a // +optional pragma comment,
  • Any pointer to a primitive (string, integer, boolean)

This second one is a leftover from when optionals in the Go SDK was purely indicated using pointer-iness. When working on this before, I think I must have missed this one, or I would have tried to remove it then :D

vivid lintelBOT
#

In this PR try to modernize DotNet SDK by do the following:

  • Upgrade .net from 7 to 8.
  • Setup .editorconfig to make dotnet format works.
  • Rework on query builder by introduce QueryBuilder class and port the logic from Go to it. Mostly feature is covered I guess.
  • Restructure folder from DaggerSDK to Dagger.SDK.
  • Temporary move DaggerSDKCodegen out of the solution. We will tackle next after this PR. :)
vivid lintelBOT
#

What is the issue?

Some Mac users have been having issues lately as they have either rosetta or the DEFAULT_PLATFORM variable set to something other than arm64 when using Dagger with Docker Desktop installed. ref: https://discord.com/channels/707636530424053791/1232715125480493127

We should add a note in our docs that in case of issues running our hello example in Mac + Docker Desktop, to double check this. It's also important to clarify that if they effectively ran into this is...

vivid lintelBOT
#

Repro test:

func TestLogDrop(t *testing.T) {
	t.Parallel()

	var logs safeBuffer
	c, ctx := connect(t, dagger.WithLogOutput(&logs))

	_, err := c.Container().
		From(alpineImage).
		WithEnvVariable("BUST", identity.NewID()).
		WithExec([]string{"sh", "-c", `i=0; while [ $i -lt 2000 ]; do echo ` + strings.Repeat("$i", 100) + `; i=$((i + 1)); done`}).
		Sync(ctx)
	require.NoError(t, err)
	require.NoError(t, c.Close())

	scanner := bufio.NewScanner(&logs)
	var i int
	expe...
vivid lintelBOT
#

Problem

Cache volumes exist in the engine's global namespace: if modules A and B each create a cache volume with id foo, they will share read and write access to the same volume, as long as they are run on the same engine. This allows one module to corrupt the data of another module, either accidentally or maliciously.

Solution

Namespace the name of cache volumes, so that each module can only read and write to its own cache volumes.

vivid lintelBOT
vivid lintelBOT
#

This is a combo of:

Basically, I finally got back to #6916 and found the bare minimum changes needed to get #6914 working fully, which is the first commit here. But then I also realized that I actually needed #6914 in order for services to work and existing tests to pass; basically, the changes ended up being codependent and I had to...

vivid lintelBOT
vivid lintelBOT
#

This feels insane, I'm not quite sure what is going on here. There appear to be 2 separate vulnerability advisories, one in runc and one in cri-o (which doesn't seem to be available yet).

However, this issue definitely doesn't affect us - we don't use cri-o anywhere in our stack, we're not spawning pods in the dagger engine, etc.

There's also not a version of runc we can feasibly upgrade to - 1.2.0-rc1 (as suggested in https://github.com/advisories/GHSA-c5pj-mqfh-rvc3), is a minor relea...

vivid lintelBOT
#

Problem

In many cases it's not clear for module consumers how to use them once they find them in the Daggerverse. Even though https://daggerverse.dev has detailed docs about the module functions, their arguments and return types, sometimes modules are designed to be consumed in a particular way which is currently hard to express given the current module documentation features.

For example, looking at this module: https://daggerverse.dev/mod/github.com/jcsirot/daggerverse/java@c591e9...

#

Problem

Dagger modules and Daggerverse do not work with other SCM than GitHub.

For the past few months, several discussions have occurred around the best way to solve it. This is now a top-priority on the backlog. Your opinion is extremely valuable to assess what behavior you would expect as a user, taking into account the pros and cons of each alternative, especially scope and DX wise.

Context

The current way of calling a [module ref](https://github....

vivid lintelBOT
vivid lintelBOT
#

What is the issue?

While working on #7202 I noticed that mounting an SSH key as a secret in a container always leads to Load key "/ssh-key": error in libcrypto errors.

Dagger version

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

Steps to reproduce

The code reproducing the issue can be found in my daggerverse:

git clone https://github.com/sagikazarmark/daggerverse.git
cd daggerverse
git checkout ssh-key-repro
cd ssh-key-repro
chmod 600 id_ed25519
...
vivid lintelBOT
#

Specifically! This doesn't spin up a docker container with a dev version of dagger, it spins up a dagger service with a dev version of dagger - dagger in dagger!

This simplifies deployment to the new CI runners.


At some point, it would be nice to have the ./hack/dev script use this as well - however, I'm not 100% sure how this would work with other core devs' workflows. Personally, I periodically run ./hack/dev to build and restart the docker engine, and use ./hack/with-dev...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#

This removes the ftp_proxy hack we've had for a while for passing uncached metadata to containers (previously a lot, but recently trimmed down to just ServerID).

Instead, we take advantage of the new custom executor added recently and use that to set the _DAGGER_SERVER_ID env var in containers. The plumbing passes the ServerID via job values, which get read by the solver's ResolveOp callback and used to tell the Executor for ExecOps which ServerID to set in the container.

There's quite ...

vivid lintelBOT
vivid lintelBOT
#

Problem

In monorepos, it's common for each sub-project of the repo to have its own submodule. But there is no easy way for the root module to "pass through" the functions of its submodules to the user. For example:

  • submodules frontend and backend are installed in the root module
  • dagger call frontend build won't work: instead dagger call -m frontend build is required.
  • dagger functions shows no functions

Solution

Allow specifying a dependency as exported. Th...

vivid lintelBOT
vivid lintelBOT
#

This is a very bad default to recommend - essentially this "de-secrets" a value, and this could then be leaked accidentally:

  • Potentially into OTEL spans
  • Potentially into cache keys
  • Potentially into engine logs

We should recommend using WithSecretVariable instead, which is much better - then rely on the shell to do the interpolation, which avoids all of these problems. The secret scrubber will then guarantee that we don't secrets leaked into logs.