#github-feed

1 messages ยท Page 10 of 1

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7236 chore(deps): bump @opentelemetry/sdk-metrics from 1.23.0 to 1.24.0 in /sdk/typescript

Bumps @opentelemetry/sdk-metrics from 1.23.0 to 1.24.0.

Release notes
Sourced from @โ€‹opentelemetry/sdk-metrics's releases.

v1.24.0
1.24.0
:rocket: (Enhancement)

feat(sdk-trace-base): log resource attributes in ConsoleSpanExporter #4605 @โ€‹pichlermarc
feat(propagator-aws-xray): moved AWS Xray propagator from contrib 4603 @โ€‹martinkuba
feat(resources): new experimental detector ServiceInstanceIdDetectorSync that sets the value for service.i...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7237 chore(deps): bump tar from 6.2.1 to 7.0.1 in /sdk/typescript

Bumps tar from 6.2.1 to 7.0.1.

Changelog
Sourced from tar's changelog.

Changelog
7.0

Rewrite in TypeScript, provide ESM and CommonJS hybrid
interface
Add tree-shake friendly exports, like import('tar/create')
and import('tar/read-entry') to get individual functions or
classes.
Add chmod option that defaults to false, and deprecate
noChmod. That is, reverse the default option regarding
explicitly setting file system modes to match tar entry
settings.
Ad...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7238 chore(deps): bump @opentelemetry/semantic-conventions from 1.23.0 to 1.24.0 in /sdk/typescript

Bumps @opentelemetry/semantic-conventions from 1.23.0 to 1.24.0.

Release notes
Sourced from @โ€‹opentelemetry/semantic-conventions's releases.

v1.24.0
1.24.0
:rocket: (Enhancement)

feat(sdk-trace-base): log resource attributes in ConsoleSpanExporter #4605 @โ€‹pichlermarc
feat(propagator-aws-xray): moved AWS Xray propagator from contrib 4603 @โ€‹martinkuba
feat(resources): new experimental detector ServiceInstanceIdDetectorSync that sets the v...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7240 chore(deps): bump sphinx from 7.2.6 to 7.3.7 in /sdk/python

Bumps sphinx from 7.2.6 to 7.3.7.

Release notes
Sourced from sphinx's releases.

Sphinx 7.3.7
Changelog: https://www.sphinx-doc.org/en/master/changes.html
Sphinx 7.3.6
Changelog: https://www.sphinx-doc.org/en/master/changes.html
Sphinx 7.3.5
Changelog: https://www.sphinx-doc.org/en/master/changes.html
Sphinx 7.3.4
Changelog: https://www.sphinx-doc.org/en/master/changes.html
Sphinx 7.3.3
Changelog: https://www.sphinx-doc.org/en/master/changes.html
Sphin...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7241 chore(deps): bump grpcio from 1.62.1 to 1.63.0 in /sdk/python

Bumps grpcio from 1.62.1 to 1.63.0.

Release notes
Sourced from grpcio's releases.

Release v1.63.0
This is release 1.63.0 (giggle) of gRPC Core.
For gRPC documentation, see grpc.io. For previous releases, see Releases.
This release contains refinements, improvements, and bug fixes, with highlights listed below.
Core

[Deps] Backport: Protobuf upgrade to v26.1. (#36353)
[OTel C++] Add experimental optional locality label available to client per-attempt metrics....

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7242 chore(deps): bump pluggy from 1.4.0 to 1.5.0 in /sdk/python

Bumps pluggy from 1.4.0 to 1.5.0.

Changelog
Sourced from pluggy's changelog.

pluggy 1.5.0 (2024-04-19)
Features

#178 <https://github.com/pytest-dev/pluggy/issues/178&gt;_: Add support for deprecating specific hook parameters, or more generally, for issuing a warning whenever a hook implementation requests certain parameters.
See :ref:warn_on_impl for details.

Bug Fixes

[#481](https://github.co...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7243 chore(deps): bump mypy from 1.9.0 to 1.10.0 in /sdk/python

Bumps mypy from 1.9.0 to 1.10.0.

Changelog
Sourced from mypy's changelog.

Mypy Release Notes
Next release
Mypy 1.10
Weโ€™ve just uploaded mypy 1.10 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.
Support TypeIs (PEP 742)
My...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7244 chore(deps): bump go.opentelemetry.io/otel/trace from 1.24.0 to 1.26.0 in /sdk/go

Bumps go.opentelemetry.io/otel/trace from 1.24.0 to 1.26.0.

Changelog
Sourced from go.opentelemetry.io/otel/trace's changelog.

[1.26.0/0.48.0/0.2.0-alpha] 2024-04-24
Added

Add Recorder in go.opentelemetry.io/otel/log/logtest to facilitate testing the log bridge implementations. (#5134)
Add span flags to OTLP spans and links exported by go.opentelemetry.io/otel/exporters/otlp/otlptrace. (#5194)
Make the initial alpha release of go.opente...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7246 chore(deps): bump go.opentelemetry.io/otel/sdk from 1.24.0 to 1.26.0 in /sdk/go

Bumps go.opentelemetry.io/otel/sdk from 1.24.0 to 1.26.0.

Changelog
Sourced from go.opentelemetry.io/otel/sdk's changelog.

[1.26.0/0.48.0/0.2.0-alpha] 2024-04-24
Added

Add Recorder in go.opentelemetry.io/otel/log/logtest to facilitate testing the log bridge implementations. (#5134)
Add span flags to OTLP spans and links exported by go.opentelemetry.io/otel/exporters/otlp/otlptrace. (#5194)
Make the initial alpha release of go.openteleme...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7247 chore(deps): bump google.golang.org/grpc from 1.62.1 to 1.63.2 in /sdk/go

Bumps google.golang.org/grpc from 1.62.1 to 1.63.2.

Release notes
Sourced from google.golang.org/grpc's releases.

Release 1.63.2
Bugs

Fix the user agent string

Release 1.63.1
Bugs

grpc: fixed subchannel log messages to properly reference the parent channel (#7101)

Special thanks: @โ€‹daniel-weisse

API Changes

grpc: remove Deprecated tag from Dial and DialContext; these will be deprecated in v1.64 instead (#7103)

Release 1.63.0
Behavior Changes

grpc...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7248 chore(deps): bump go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc from 1.24.0 to 1.26.0 in /sdk/go

Bumps go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc from 1.24.0 to 1.26.0.

Changelog
Sourced from go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc's changelog.

[1.26.0/0.48.0/0.2.0-alpha] 2024-04-24
Added

Add Recorder in go.opentelemetry.io/otel/log/logtest to facilitate testing the log bridge implementations. (#5134)
Add span flags to OTLP spans and links exported by go.opentelemetry.io/otel/exporters/o...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7249 chore(deps): bump smallrye-graphql.version from 2.7.0 to 2.8.3 in /sdk/java

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

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

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

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7250 chore(deps): bump google.golang.org/grpc from 1.62.1 to 1.63.2

Bumps google.golang.org/grpc from 1.62.1 to 1.63.2.

Release notes
Sourced from google.golang.org/grpc's releases.

Release 1.63.2
Bugs

Fix the user agent string

Release 1.63.1
Bugs

grpc: fixed subchannel log messages to properly reference the parent channel (#7101)

Special thanks: @โ€‹daniel-weisse

API Changes

grpc: remove Deprecated tag from Dial and DialContext; these will be deprecated in v1.64 instead (#7103)

Release 1.63.0
Behavior Changes

grpc...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7251 chore(deps): bump github.com/charmbracelet/lipgloss from 0.9.1 to 0.10.0

Bumps github.com/charmbracelet/lipgloss from 0.9.1 to 0.10.0.

Release notes
Sourced from github.com/charmbracelet/lipgloss's releases.

v0.10.0
String Transforms ๐Ÿ’„
Lip Gloss v0.10.0 features a brand new Transform function for Styles to alter strings at render time. As well as some bug fixes, like ANSI-aware table cell truncation. ๐Ÿงน
Simply define a Transform function as func (string) string and apply it to any style:
// Example:
s := NewStyle().Tra...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7252 chore(deps): bump github.com/containerd/containerd from 1.7.15-0.20240329193453-0dcf21c1528a to 1.7.15

Bumps github.com/containerd/containerd from 1.7.15-0.20240329193453-0dcf21c1528a to 1.7.15.

Release notes
Sourced from github.com/containerd/containerd's releases.

containerd 1.7.15
Welcome to the v1.7.15 release of containerd!
The fifteenth patch release for containerd 1.7 contains various fixes; one for a
regression introduced in v1.7.14 in the way process exits were handled.
Highlights

Adds mediatype to OCI index record on export (#9990)

Runt...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7253 chore(deps): bump github.com/docker/cli from 26.0.0-rc1+incompatible to 26.1.1+incompatible

Bumps github.com/docker/cli from 26.0.0-rc1+incompatible to 26.1.1+incompatible.

Commits

4cf5afa Merge pull request #5047 from vvoland/v26.1-5038
6c2b06d Merge pull request #5045 from vvoland/vendor-docker-26.1.1-dev
1c6a8ec cli-plugins: PluginRunCommand: use cmd.Environ instead of os.Environ
6d1c387 vendor: github.com/docker/docker ac2de55998d4 (v26.1.1)
1e6db5d Merge pull request #5044 from vvoland/wait-cancel-noerror
840016e waitExitOrRemoved: Handle cont...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7254 chore(deps): bump go.opentelemetry.io/otel/exporters/otlp/otlptrace from 1.24.0 to 1.26.0

Bumps go.opentelemetry.io/otel/exporters/otlp/otlptrace from 1.24.0 to 1.26.0.

Changelog
Sourced from go.opentelemetry.io/otel/exporters/otlp/otlptrace's changelog.

[1.26.0/0.48.0/0.2.0-alpha] 2024-04-24
Added

Add Recorder in go.opentelemetry.io/otel/log/logtest to facilitate testing the log bridge implementations. (#5134)
Add span flags to OTLP spans and links exported by go.opentelemetry.io/otel/exporters/otlp/otlptrace. (#5194)
Make ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7255 engine: support for system proxy settings

Adds support for standard proxy settings (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, ALL_PROXY, FTP_PROXY) being passed transparently to containers from the system.

The support itself is very easy via the new custom executor setup.

Integ tests are much more complicated, though kind of fun. I have integ tests working for HTTP_PROXY and HTTPS_PROXY, using a squid proxy service and nested engine with a binding to it, but they are a bit of a mess right now.

Draft pending:

  • [ ] ...
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7257 chore: update go deps

Important updates:

This PR replaces:

vivid lintelBOT
#
kjuulh
[dagger/dagger] Issue opened: #7258 ๐Ÿž dagger v0.11.2 possible memory leak

What is the issue?

We've seen that since bumping to 0.11 + some of our containers are facing out of memory issues. Currently our dagger engines sit at around 7GB of memory, when before 0.11 they were at 2GB. It continues to climp until kubernetes choses to preempty the pods.

We initially saw it because quite a few barebones debian:12.5-slim execs with apt-get update + apt-get install -y ca-certificates gave a 137 exit code.

Which from what I could gather is when buildkit sends a ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
helderco
[dagger/dagger] Pull request opened: #7270 chore: silence output from uv compile

Silenced output when creating/updating the requirements.lock file. Since we create lots of modules in our test suite this adds a lot to logs because of all the hashes.

Example (before, โ‰ˆ 450 lines):

exec uv pip compile --generate-hashes -o requirements.lock sdk/pyproject.toml pyproject.toml
1	Resolved 34 packages in 931ms
2	# This file was autogenerated by uv via the following command:
3	#    uv pip compile --generate-hashes -o requirements.lock sdk/pyproject.toml pyproject.toml...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7272 feat: improve plain progress

Fixes #7137.

With the changes as part of #6835 (in v0.11.0), all old TUIs were removed, including the old --progress=plain output. With #7069 (in v0.11.1), a limited version of the plain TUI was restored. However, as noted in https://github.com/dagger/dagger/issues/7137#issuecomment-2090450408 and https://github.com/dagger/dagger/pull/7223#issuecomment-2090499541, this new plain progress has issues - it only reports spans that have logs, and loses a lot of additional information.

This...

vivid lintelBOT
#
sagikazarmark
[dagger/dagger] Issue opened: #7273 Cannot write (or read?) from temp mounts

What is the issue?

After writing to a temp mount in a container, the mounted directory shows up as empty, but there is no error indicating that the command writing to the mount fails.

When opening up a terminal in the same container, it works.

Dagger version

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

Steps to reproduce

	return dag.Container().From("alpine").
		WithUser("root").
		WithMountedTemp("/root/foo").
		WithExec([]string{"sh", "-c", "echo baz...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sagikazarmark
[dagger/dagger] Issue opened: #7276 Customize CLI command names

What are you trying to do?

Allow customizing how function names are translated into commands.

For example:

// +command=e2e
func (m *Ci) E2e() {
    // ...
}

Why is this important to you?

Function names are often translated to weird commands. For example E2e becomes e-2-e.

How are you currently working around this?

I call my end-to-end test function Etoe. ๐Ÿ™ˆ

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
SKalt
[dagger/dagger] Issue opened: #7278 ๐Ÿž Module names with single-dotted characters cause "main object not found"

What is the issue?

I have a go module with a weird name with single dotted characters in it (e.g. "m.a.s.h"). I was running through the setup script when I encountered a weird error, "unable to find main object". I determined this error only occurs when there are single-dotted characters in the name field of dagger.json. I suspect the culprit is a mismatch between the arguments informing the [generated go struct name](https://github.com/dagger/dagger/blob/1bc2cffabc80e614afea9dc0155a0...

vivid lintelBOT
#
iximiuz
[dagger/dagger] Issue opened: #7280 ๐Ÿž bash completion setup instructions are broken when XDG_DATA_HOME is not set

What is the issue?

Here is an excerpt from the install.sh run on my server(s):

dagger has built-in shell completion. This is how you can install it for:

  BASH:

    1. Ensure that you install bash-completion using your package manager.

    2. Add dagger completion to your personal bash completions dir

      mkdir -p /bash-completion/completions
      dagger completion bash > /bash-completion/completions/dagger

Notice how `mkdir -p /bash-completion/completio...

vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7281 core: clarify withMountedTemp docs that they are ephemeral

Just a doc string update, but something odd is happening when I run ./hack/make sdk:elixir:generate locally:

โœ˜ DaggerElixirSdk.generate: Directory! 11.8s
! call function "Generate": process "/runtime" did not complete successfully: exit code: 2
โ”ƒ marshal: json: error calling MarshalJSON for type *dagger.Directory: input: container.from.withWorkdir.withDirectory.withExec.withExec.withExec.withServiceBinding.withEnvVariable.withMountedFile.withEnvVariable.withExec.withMountedSecret.wi...
vivid lintelBOT
#
giuliohome
[dagger/dagger] Issue opened: #7282 ๐Ÿž On Windows 11 - Cannot start an interactive terminal

What is the issue?

The command

 dagger -m github.com/shykes/daggerverse/wolfi@v0.1.2 call container --packages=python3 terminal

fails with Error: sending initial size: get terminal size: The handle is invalid.

Dagger version

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

Steps to reproduce

I have create an azure windows 11 vm with docker desktop installed.
I follow the install docs, I install powershell 7.4.2 and I execute

Invoke-WebRequest...
vivid lintelBOT
vivid lintelBOT
#
harleylang
[dagger/dagger] Issue opened: #7284 ๐Ÿž TypeScript SDK v0.11.2 throws `TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts"`

What is the issue?

Since v0.11.2 was shipped I have found that TypeScript Dagger Modules and Functions will fail to run, with the following error thrown in the logs: TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts"

The best hypothesis I could drum up is that this error was introduced after this PR merged in on Friday:

https://github.com/dagger/dagger/commit/56a039a3ee96b4ab826b711d3e5843da8aadd8cb#diff-a8b5f7f08501c3951b9991d2450b8b0a68ac764af369185bbf7044d96...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
helderco
[dagger/dagger] Pull request opened: #7286 cli: use "functions" and "arguments" instead of "commands" and "options" in `dagger call`

Follow up to:

Part of:

What changed?

  • Removed COMMANDS from the list of subcommands heading, in favor of just FUNCTIONS.
  • Added [arguments] and `` to the usage line when appropriate.
  • Flags created for function arguments are split into its own ARGUMENTS section. So constructor arguments will now appear separately from callโ€™s own flags.

Before

After

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7295 chore: use temporary buildkit fork with bug fixes pending upstream merge

We really want these bug fixes for the next release but they are still in PR upstream, so we made a fork of buildkit in the dagger org and I cherry-picked those fixes.

  • This fork is only intended to be used on temporary bases for situations like this where we want bug fixes but upstream hasn't updated yet. Not intended to be used for any long term divergence.

The upstream PRs with cherry-picked commits are:

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7302 ci: lint runtime modules

In addition to making sure that all the module runtimes are being properly linted, this also ensures that the go.mods are kept up to date!

This is important, so that we don't see these go.mods not reflecting the state of reality (see the report in https://github.com/dagger/dagger/issues/7284, which mis-identifies the source of the issue - the dependency in question was always being installed, but the go.mod wasn't accurately reflecting that).

vivid lintelBOT
#
gerhard
[dagger/dagger] Issue opened: #7303 ๐Ÿž `NotAwaitedRequestError`: Encountered an error while requesting data via graphql through a synchronous call. Make sure the function called is awa...

What is the issue?

Hit this in sdk:typescript:test https://github.com/dagger/dagger/actions/runs/8986965799/job/24684341907?pr=7296#step:5:6492

Also:

cc @TomChv

Dagger version

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

Steps to reproduce

Not sure how to reproduce, but I've seen our CI hit it a few times. Will comment when we hit it again.

Log output

[NotAwaitedRequestError.txt](https://github.com/dagger/dagger/files/15237078/NotAwaitedRequestE...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7309 chore: update dep on buildkit

The fix for leaking goroutines was fixed, so rebased our temp fork on upstream with that.

Also, it was noticed that the fix for edge merging actually does need the more complicated solution that includes adding jobs to all ancestor states; there was a panic when the solver walked provenance without that.

So this also now points to the (still pending upstream) commit with that fix.

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7314 ๐Ÿž Dagger Fails due to `ci/internal/telemetry` error

What is the issue?

Users are reporting intermittent errors where dagger starts to fail with this error:

cannot use proxySpan{โ€ฆ} (value of type proxySpan)

Dagger version

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

Steps to reproduce

No response

Log output

โœ˜ initialize 2.4s
! input: module.withSource.initialize resolve: failed to initialize module: failed to call module "ci" to get functions: call constructor: process "go build -o /runtime ." did...
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7315 WIP refactor of server/sessions/buildkit-interfaces

Another part of the effort to support https://github.com/dagger/dagger/pull/6916 while also doing general cruft cleanup and setup for various upcoming efforts.

Deeply WIP still, but main goal is to fix the current knots tied between BuildkitController, DaggerServer, BuildkitClient, Query, dagql.Server, ClientCall-related stuff, etc. in order to make the whole system more comprehensible and make it easy to manage/isolate state (both now and going forward).

There's quite a bit...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Issue opened: #7320 CLI cannot call function accepting a list of scalars in v0.11.3

Found in https://github.com/dagger/dagger/actions/runs/9003172745/job/24733214096?pr=7319.

Attempting to call a function like:

// Verify that the engine builds without actually publishing anything
func (e *Engine) TestPublish(
	ctx context.Context,

	// +optional
	platform []Platform,
) error {

Causes a panic:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xf6108d]

gor...
#
vito
[dagger/dagger] Pull request opened: #7321 track stable function call hash + more attrs
  • moved telemetry/graphql.go to core/telemetry.go so it can integrate with Query to get necessary module metadata
  • dagger.io/dag.digest.stable is a Call's 'stable digest'. This digest can be used to compare performance of the same Call across different inputs over time. This calculation involves simply recursing through a call and removing any embedded Calls passed as arguments.
  • dagger.io/dag.caller.type indicates whether the span comes from a direct user call, a call from a mo...
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7322 fix: ensure cli handles scalar lists correctly

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

Also added tests for this. cc @TomChv the typescript tests I added seem to fail, with:

$ dagger --progress=plain call --source=. test custom --race=true --pkg=./core/integration --run=TestModuleScalarType/typescript
...
    module_test.go:2989: 
        	Error Trace:	/app/core/integration/module_test.go:2989
        	Error:      	Received unexpected error:
        	            	input: container.from.withMountedFile.withWorkdi...
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7323 chore: update alpine base to 3.19

Yay - somehow, https://github.com/dagger/dagger/pull/7111 wasn't entirely right - the git version in alpine 3.18 is too old, and git fetch --porcelain isn't supported. However, in alpine 3.19, the version is new enough, and this new flag works.

See https://github.com/dagger/dagger/actions/runs/9003172745/job/24733214096?pr=7319#step:4:71.

14:06:47 WRN failed to fetch branch err="error fetching branch from origin: exit status 129\nerror: unknown option `porcelain'\nusage: git fetch ...
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7324 Add Documentation for dagger.json

What is the issue?

As far as I can tell we don't have any documentation describing the contents of dagger.json.

We should have a section in the docs that talks about the file, what it contains by default, and what additional parameters are available.

The biggest point of friction for newcomers is there is a way to exclude files and dirs via dagger.json that is undocumented. So for projects with large directories (that are not required for the actual build) it can cause significan...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7328 core: make Directory.diff logic less fragile

The TS SDK was very subtly broken when used from a git ref due to the fact that the Directory.diff logic was way too fragile (has existed since the beginning of time). This fixes that logic and updates the TS SDK to be slightly simpler now that it doesn't need to try to avoid that fragility.

Individual commits have more detailed messages.

We also need to add integ tests that use SDKs other than go sourced from git refs. Starting the effort now, will send out a separate PR if t...

vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7329 tests: add coverage for non-go SDKs used from git

While in theory SDKs should be agnostic of whether module source is
coming from git, local dirs, etc. a very subtle issue arose recently
that broke TS modules only when sourced from Git (related to
Directory.diff path handling).

That would have been caught by coverage of those SDKs used from git,
so adding tests here. Verified that tests pass with ./hack/dev but the
TS one fails if run direct against v0.11.3, so it's working as intended.

Related: https://github.com/dagger/...

vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7332 docs: make go snippet compilable

This was causing errors on main and in PRs: https://github.com/dagger/dagger/actions/runs/9008181567/job/24749649865?pr=7330#step:5:502

Couldn't have caught it because the docs PRs (correctly) don't trigger engine tests, but I think the way the engine tests run result in an error if there's a compilation problem on any Go packages in the whole repo, which includes the docs since we have all those go examples.

  • There's definitely some room for improvement here, but want to fix this to unb...
vivid lintelBOT
#
sagikazarmark
[dagger/dagger] Issue opened: #7334 ๐Ÿž Setting the same secret in parallel causes Dagger to hang

What is the issue?

Failed to connect; retrying... make request: Post "http://dagger/query": rpc error: code = Unknown desc = failed to verify client: client ID "***" registered with different secret token

https://github.com/sagikazarmark/daggerverse/pull/96/commits/1090eee44f94be6aa09e20d28301af0e8d582261

Dagger version

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

Steps to reproduce

No response

Log output

No response

vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7335 engine: make client IDs fully random again

A few releases ago, client IDs were changed to be digests of the dagql.CurrentID in order to remove the number fields in our ftp_proxy hack and to consolidate client ID w/ module caller digest.

This is not entirely working as expected though (detailed below). Fortunately the new custom worker gives us a non-hacky path to set whatever IDs we want in containers without worrying about cache busting or the various problems caused by the ftp_proxy hack, which has been gone entirely as of last r...

vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7336 core: don't bust cache with random OTEL values in function calls

When OTEL support was added, module functions were updated to set env vars with the OTEL traceparent values. These values appear to be random every time a function is invoked, even if coming from the same caller and making the call with the same inputs, etc.

That resulted in them busting the Buildkit cache every time.

Fortunately, most of the time the dagql cache within the context of a session prevented this from being noticeable, but in the case where dagql IDs were impure (which prev...

vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7337 fix: refactor `GITHUB_REF` handling to use temp ref

Fixes the issue described in #7323 (that wasn't the right fix though, since this occurs on a client - so we don't control the git version).

The --porcelain flag is very nice, but unfortunately, it's not present on older git versions. Since the client git version isn't controlled or managed by us, we should try and play nice with it, and not use any
features that are too new.

In this new approach, we create a new "refs/dagger/..." ref, and then update that (to avoid making changes to ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
gerhard
[dagger/dagger] Issue opened: #7339 ๐Ÿž path: ETOOBIG File name length exceeds the maximum supported 255 characters

What is the issue?

While reviewing:

I've hit the following issue:

  โœ˜ Directory.withNewFile(contents: "some-content", path: ETOOBIG:sha256:b28cf6ece37f09c81b0f005953eeee586b4d2a60af4317de1cd461dc6ae74f80): Directory! 0.0s
  ! File name length exceeds the maximum supported 255 characters

I am able to hit this consistently on NixOS 24.05 with Docker 24.05 cc @vito @matipan @sipsma ? This now explains the behaviour...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sagikazarmark
[dagger/dagger] Issue opened: #7343 โœจ Dependency updates

What are you trying to do?

Automate/make dependency updates easier.

Dependency update strategies:

  1. Update one dependency because I need something from a newer version:
dagger install github.com/...
  1. Update all dependencies to latest (due to Dagger engine compatibility or because I just want to update everything to the latest version):

Ideal solution:

dagger install -u

Why is this important to you?

No response

How are you currentl...

vivid lintelBOT
#
sagikazarmark
[dagger/dagger] Issue opened: #7344 โœจ Do not auto-publish all modules to Daggerverse

What are you trying to do?

Do not auto-publish the following modules to Daggerverse:

  • Dev/test modules
  • Untagged modules
  • Project (application) modules
  • Modules intended as a demo/bug reproduction
  • Forks of modules

In my particular case:

vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7347 fix: attach cli args to initialize parent

Discovered during #7272, when trying to make sense of some of the output.

Before, the context was not being propagated, so when loaded, all CLI args would be associated with the root, instead of under the initialize span (where it makes a lot more sense).

Before:

โฏ dagger call -vv --source=. version string
โœ” connect 0.9s
  โœ” starting session 0.2s
  โ”ƒ OK!
โœ” initialize 7.9s
  โœ” ModuleSource.resolveFromCaller: ModuleSource! 0.1s
  โœ” ModuleSource.asModule: Module! 0.1s
   ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
kpenfound
[dagger/dagger] Issue opened: #7353 DAG loses concurrency with module chaining

When chaining module functions from the CLI, it appears that the expected DAG concurrency is lost. Here is an example:

package main

import (
	"context"
	"fmt"
	"math/rand"
)

type MyModule struct{}

type Job struct {
	*Container
	*Directory
	Key string
}

type Jobs struct {
	Jobs []Job
}

func (r *MyModule) JobGroup(
	ctx context.Context,
	// +optional
	sync bool,
) Jobs {
	jobs := Jobs{Jobs: []Job{
		r.echoAndSleep(5),
		r.echoAndSleep(6),
		r.echoAndSl...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7356 core: fix custom CA certs in modules + add integ test coverage

A recent commit that changed client IDs to be random again accidentally made it so that commands run to update CA certificates (when a custom engine has those installed) hit errors about client tokens not matching when the exec being run was nested, which includes module function calls.

This was due to the fact that those commands run in the same container with the same client ID but the secret token was generated by the client each time it ran...

vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7357 โœจ Create Dockerfile from Dagger

What are you trying to do?

Dagger is really good at reading and executing Dockerfiles, but it would be really cool if you could generate a Dockerfile from Dagger as well.

Why is this important to you?

A few users have mentioned that rewriting their Dockerfile in Dagger (which is a good thing) has some downstream consequences. Most critically it breaks existing docker-compose setups.

How are you currently working around this?

No great workaround.

vivid lintelBOT
vivid lintelBOT
#
sagikazarmark
[dagger/dagger] Issue opened: #7358 โœจ Make secret name optional

What are you trying to do?

I have a function that creates a secret: https://daggerverse.dev/mod/github.com/sagikazarmark/daggerverse/registry-config@b45dbd7448bb967aca4a538af9ce7f042abf0316#RegistryConfig.secret

The current secret API takes a name at the moment: dag.SetSecret("name", "value").

I'm not sure, but my guess is that name is supposed to be unique (ie. to make sure there is no interference between calls to the same function).

Why is this important to you?

Right no...

vivid lintelBOT
vivid lintelBOT
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7360 chore(deps): bump the sdk-java group across 1 directory with 8 updates

Bumps the sdk-java group with 8 updates in the /sdk/java directory:

Package From To
io.smallrye:smallrye-graphql-client-api 2.7.0 2.8.3
io.smallrye:smallrye-graphql-client-implementation-vertx 2.7.0 2.8.3
org.apache.commons:commons-lang3 3.13.0 3.14.0
org.apache.commons:commons-compress 1.24.0 1.26.1
org.mockito:mockito-core 5.10.0 5.12.0
[org.codehaus.mojo:exec-mav...
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7361 chore(deps): bump the sdk-typescript group in /sdk/typescript with 2 updates

Bumps the sdk-typescript group in /sdk/typescript with 2 updates: execa and graphql-request.

Updates execa from 8.0.1 to 9.0.2

Release notes
Sourced from execa's releases.

v9.0.2
Types (bug fixes)

Do not require using --lib dom for TypeScript users (#1043, #1044)
Fix type of the reject option (#1046)

https://github.com/sindresorhus/execa/compare/v9.0.1...v9.0.2
v9.0.1
Types (bug fixes)

Fix types ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
stobias123
[dagger/dagger] Issue opened: #7368 โœจ `.AsTarball` Add OCI manifest RepoTags

What are you trying to do?

I want to add tags when running .AsTarball(), perhaps in ContainerAsTarballOpts

Example usage:

client.Container().From("ubuntu:latest").WithExec([]string{"touch", "/test"}).AsTarball(dagger.ContainerAsTarballOpts{Address:"test:foo"}).Export(context.Background(), "test.tar")

Docker equavalent:

โžœ  git:(stobias/ci-improvements) โœ— docker build -t tarball_test .
โžœ  git:(stobias/ci-improvements) โœ— docker tag tarball_test tarball_test:...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7371 feat: mark `[internal]` buildkit prefixes as internal

Follow-up to #6835 (found during hackery on #7272)

We used to use the magic [internal] prefix in buildkit vertex names to mark these as internal to the UI. However, we've since updated our TUI and cloud logic to instead pull this information from an OTEL span attribute (which makes much more sense). However, we didn't have a way of connecting buildkit vertices to this attribute.

This wasn't immediately obvious - because of how [our TUI logic doesn't show spans that last longer than 10...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sagikazarmark
[dagger/dagger] Issue opened: #7374 ๐Ÿž Inconsistent file mounting behavior when name isn't specified

What is the issue?

I'm supposed to be able to do this:

dag.Container().WithFile("", file)

dag.Directory().WithFile("", file)

When no path is specified, the file should be mounted in the current directory with it's current name.

Unfortunately, Dagger behaves differently in different scenarios which makes mounting files like this unreliable.

(The unfortunate consequence is every higher level API that allows mounting a file in a lower level container requires a se...

vivid lintelBOT
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7375 โœจ Dagger CLI should time out more when there is an issue with docker

What are you trying to do?

Right now if there is some issue with docker the dagger CLI will continue to try to connect indefinitely. We had a very patient person who waited 56 minutes before giving up. :)

Ideally we either check to make sure docker is going to work, or time out if we are stuck connecting for more than say 5 minutes.

Why is this important to you?

Especially for people new to Dagger this can be a very bad first impression and a very poor DX.

How are you ...

vivid lintelBOT
vivid lintelBOT
#
jpadams
[dagger/dagger] Issue opened: #7377 โœจ API for export of `Directory` and `File` from `Service` container

What are you trying to do?

Users have asked for the ability to get files out of Service containers so they can capture test reports, or logs, or other generated files. Currently there is no API.

integration test container cannot be a service if we want to extract files like tests reports at the end of a run. If it was possible to extract files from a service that would also work.

Discord references:
#1239817495309713428 message...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7385 Improved connection progress

Continued progress exploration! I just kinda kept pulling on #7375, and kept finding more things to tidy up :tada:

Fixes:

  • #7375

This changes a few things about the initial connection:

  • Changes timeouts, to provide a sane upper limit on the amount of time allowed to provision an engine, e.g. pulling+starting a docker container (10 minutes)
  • Splits up the connect step into separate parts - this allows for improved debugability if this step is hanging - we can see exactly which p...
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7386 fix: hide remotes.docker.resolver spans

Before this, we would display all the containerd/buildkit spans that relate to pulling an image. These are super unhelpful by default, so we want to hide them in the TUI (unless the parent command errors).

We already have this concept today with telemetry.Encapsulate. However, this is set on the parent (in our case, Container.from), which isn't quite what we want. Firstly, this would silence all output from this function (even if later we would want to add some more useful output of ...

vivid lintelBOT
#
gerhard
[dagger/dagger] Issue opened: #7387 ๐Ÿž Dagger CLI v0.11.4 deadlocks when running `dagger call --source=.:default test all`

What is the issue?

This was discovered part of:

Somewhat similar to this issue, but different since host had 16CPUs, parallelism was 16:

The CLI will remain stuck and it will need to be manually killed, as mentioned by @jpadams in a private thread. When a timeout is used - [30m in our case](https://github.com/dagger...

vivid lintelBOT
vivid lintelBOT
#
jpadams
[dagger/dagger] Issue opened: #7388 โœจ API: add `File` or `NewFile` to API to create a new file

What are you trying to do?

Today, there is no way to ask the API for a new file directly. You have to go through Directory.

We got close to seeing this in the past, but it hasn't happened yet.
https://github.com/dagger/dagger/issues/3028
https://github.com/dagger/dagger/issues/3884

Why is this important to you?

Many users have requested this including @sagikazarmark @vito @helderco @jpadams

How are you currently working around this?

myFile := dag.Director...
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7389 docs: Document how functions translate to the client versions in dag and how they differ

@vikram-dagger, I'm also thinking we need to document somewhere (not in this PR, of course) how these functions translate to the client versions in dag, and how they differ. Several Go users have been confused by this, especially when a function returns both an error and an object, because the client version doesn't return an error in this case.

_Originally posted by @helderco in https://github.com/dagger/dagger/issues/7379#issuecomment-2112383112_

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
gerhard
[dagger/dagger] Pull request opened: #7395 Remove oci-max-parallelism entirely

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

This is not an option that we should support. Justin puts it best:

I think with (Dagger) Modules, this effectively means that
`max-parallelism` is pretty much just completely broken - it just fits
very badly with the idea of nested containers.

... but to me this kind of highlights that we need a better way of
constraining resources - max-parallelism is just really not fit for
the shape that pipelines tend ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7397 ๐Ÿž CLI docs does not show bool type

What is the issue?

I have a function with a bool type parameter. When I get --help for this function the docs do not show the type.

I have this parameter defined in go:

	// Optional flag to disable cache
	// +optional
	// +default=false
	enableCache bool,

I expect the output to show this:

ARGUMENTS
      --src Directory              The source directory of your docusaurus site, this can be a local directory or a remote git repo [required]
      --ca...
#
levlaz
[dagger/dagger] Issue opened: #7398 โœจ Don't require any params when asking for help

What are you trying to do?

Right now if I want to call --help on a module or function that has some required parameters I need to add those parameters before getting the help output. This is especially painful when using a constructor.

I expect this to work closer to daggerverse.dev where I can inspect everything a module or function can do without needing to think about the inputs.

Why is this important to you?

I think its a much cleaner DX if we decouple --help from executio...

vivid lintelBOT
#
shykes
[dagger/dagger] Issue opened: #7399 Container.up()

Problem

When I call a function returning a Container, to run that container as a service, I have to run:

dagger call  as-service up

That is 2 extra functions in the chain, which is cumbersome. It's common to write a wrapper function that returns a Service, for the sole purpose of typing:

dagger call  up

But now I have to maintain one more function, with another name. It's also cumbersome and feels unnecessary.

Solution

Implement...

vivid lintelBOT
vivid lintelBOT
#
helderco
[dagger/dagger] Issue opened: #7400 CLI: Donโ€™t show inherited flags in `dagger call <function> --help`

In dagger call --help thereโ€™s three groups of flags:

  • Module constructor arguments
  • call specific flags
  • Global flags

Example:

ARGUMENTS
      --source Directory            [required]
      --host-docker-config Secret
      --version string

OPTIONS
      --json            Present result as JSON
  -m, --mod string      Path to dagger.json config file for the module or a directory containing that file.
                        Either local path (e.g. "/path/to/some/...
vivid lintelBOT
#
Xiot
[dagger/dagger] Issue opened: #7401 โœจ [Typescript] Support string literal types

What are you trying to do?

I'm trying to use a literal type in order to have better typing in my dagger code.

I have a field like this on an object.

@field() type: 'head' | 'merge'

However it looks like the code-gen doesn't seem to support this as when I try to run the dagger module, I get

 Error: query module objects: returned error 400 Bad Request: failed to get schema introspection JSON: introspection query failed: input: __schema.types[75].fields[2].t...
#
Xiot
[dagger/dagger] Issue opened: #7402 โœจ [Typescript] eslint rule to avoid some common gotchas

What are you trying to do?

While trying to get around https://github.com/dagger/dagger/issues/7401, I tried to keep the @field as a string, but then just type a custom property.

@object()
export class MergeRequestReference {
  @field() _iid: string
  @field() _type: string

  constructor(iid: string, type: 'head' | 'merge') {
    this._iid = iid
    this._type = type
  }

  get iid() {
    return this._iid
  }
  get type() {
    return this._type
  }
}...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
wingyplus
[dagger/dagger] Issue opened: #7410 ๐Ÿž Go: `dagger functions` treat constructor arg as a function

What is the issue?

I have a module that has 1 constructor argument and a run function. When I call dagger functions, the command treat constructor arg as a function.

Dagger version

0.11.4

Steps to reproduce

Use the module from https://github.com/wingyplus/daggerverse/tree/main/earthly. Then run dagger functions. You will see both function and constructor arg listed like the screenshot below:

![Screenshot 2024-05-19 171753](https://github.com/dagger/dagger/asset...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
yibble
[dagger/dagger] Pull request opened: #7412 Add Values.engine.labels value to Helm Chart.

This is required in cases where labels are required to provide access, ETC. I.E.:

I need this change because I'd like to execute Terraform code in Dagger Runners under an Azure MSI context using aadPodIdentity in an AKS cluster. To provide the necessary access, the dagger-engine DaemonSet requires an aadpodidentity label for aadPodIdentity to attach an Azure MSI context to it.

vivid lintelBOT
vivid lintelBOT
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7415 chore(deps): bump google.golang.org/grpc from 1.63.2 to 1.64.0 in /sdk/go in the sdk-go group

Bumps the sdk-go group in /sdk/go with 1 update: google.golang.org/grpc.

Updates google.golang.org/grpc from 1.63.2 to 1.64.0

Release notes
Sourced from google.golang.org/grpc's releases.

Release 1.64.0
API Changes

stats: Deprecate InPayload.Data and OutPayload.Data; they were experimental and will be deleted in the next release (#7121)

Behavior Changes

codec: Remove handling of environment variable GRPC_GO_ADVERTISE_COMPRESSORS to suppress setting s...

vivid lintelBOT
vivid lintelBOT
#
gerhard
[dagger/dagger] Pull request opened: #7416 ci: Add extra flags for Engine & CLI tests

--parallel now defaults to the number of CPUs. Before, this was hard-coded to 16 which was set the number of CPUs in the larger GitHub Runners, the ubuntu-22.04-16c-64g-600gb instance size specifically. If this new default value does not work well on the larger CI runners (they have 48CPUs & we run multiple pipelines on them at the same time), we can specify this value explicitly in the workflows.

--timeout defaults to 30m. This was changed not that long ago - the value was set t...

vivid lintelBOT
#
helderco
[dagger/dagger] Pull request opened: #7417 fix(cli): don't validate flags when requesting `--help`

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

The --help flag is now global (interspersed). So the help will no longer be shown next to the command where itโ€™s defined if thereโ€™s more to the right. Itโ€™s position in the chain no longer matters, it will be the same as adding it to the end. This was needed to look ahead and skip some validations while that flag wasnโ€™t parsed yet, and while it was possible to preserve the previous behavior, making it global seems more consistent with CLI...

vivid lintelBOT
#
helderco
[dagger/dagger] Pull request opened: #7418 cli: donโ€™t show functions that canโ€™t be called

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

Most common reason for not being able to call a function is unsupported flags, but if there's unsupported return types as well, they should be added too.

This change excludes functions with any unsupported flag, however, maybe itโ€™s best to do it only for required flags, and keep the function but skip adding the optional arguments that arenโ€™t supported.

vivid lintelBOT
#
grouville
[dagger/dagger] Pull request opened: #7420 core: multi SCM support

First working draft of multi SCM support.

Currently only works on public VCS repo, as well as public vanity URL relying on the go-get vanity URL logic from Go.

TODO

  • [ ] More detailed history of https://github.com/grouville/go-vcs when merging
  • [ ] Improve error messages: on init, install, call, functions -> add ++++ integration tests
  • [ ] Add vanity URL test by changing dagger.io/dagger redirect (side PR)
  • [ ] Add vcsToBuildKitRef logic in core/schema/git` to handle s...
vivid lintelBOT
vivid lintelBOT
#
gerhard
[dagger/dagger] Issue opened: #7423 ๐Ÿž Failed `dagger call` check fails due to missing span & does not get fixed when re-running the job

What is the issue?

This dagger call check failed:

If you look carefully at all the workflows, you will notice that they all succeeded. The last time that this happened, re-triggering the workflow fixed it: https://github.com/dagger/dagger/pull/7407#issuecomment-2119253346

In this case - https://github.com/dagger/dagger/pull/7416 - that didn't work.

https://dagger.cloud/dagger/traces/d2a10b407f509e3a0cb119c9f7d97a7b

Is there a different workaround that we could use for t...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
shykes
[dagger/dagger] Issue opened: #7426 Simplify service API

Problem

The Service API is powerful, but confusing - especially to beginners.

  • Service.start() starts a service, but you're not supposed to use it, except in a niche use case.
  • Service.up() also starts a service, but differently - only to expose ports to the client's network, and should only be called in the CLI. If you call from a Dagger Function, it will expose ports on the function container's network.
  • Service.stop() stops a service, but you're not supposed to use it, ...
vivid lintelBOT
vivid lintelBOT
#
shykes
[dagger/dagger] Issue opened: #7428 Cache function calls by default

Problem

Dagger has great caching, but Dagger Functions don't fully benefit from it, because their runtime containers are not cached.

This has several consequences:

  1. Functions that perform compute-intensive work themselves, via native code, are most affected: they are re-run each time, adding a major performance penalty.
  2. Functions that are not compute-intensive (the majority) are less affected, but still pay a small performance tax at each execution, because of the overhead o...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
esafak
[dagger/dagger] Issue opened: #7430 Indicate that python scripts need not be wholly placed in __init__.py

What is the issue?

dagger's practice of using __init__.py to hold dagger scripts beyond simple imports flies in face of python convention. The documentation and templates should be revised to indicate that dagger does not in fact require or recommend this, and users are free to place their code in another file and import it in __init__.py so long as it is in a package called "main"

[Discord discussion](#python message...

vivid lintelBOT
#
shykes
[dagger/dagger] Issue opened: #7432 Toolchains

This proposal is an alternative to #7199. The problem is the same, but the proposed solution is different.

Problem

There are two types of Dagger modules: those that are standalone software projects, and those that exist in the context of another 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 ac...
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7433 โœจ Consider Pinning Node to LTS release

What are you trying to do?

A user reported that they were surprised to see us using a non-LTS version of Node in our Typescript SDK.

We should consider pinning our TypeScript SDK to the LTS version of node as we approach "dagger 1.0"

Why is this important to you?

Since we expect people to adopt this SDK in their production pipelines, I think we will have a lot less issues long term if we stick to a stable version of node. Node's own documentation recommends using only LTS ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
gerhard
[dagger/dagger] Issue opened: #7441 ๐Ÿž panic: runtime error: slice bounds out of range [:77] with capacity 64

What is the issue?

This is the first time that I'm seeing this in our CI, wanted to flag it up:

dagger call --source=.:default --host-docker-config=file:/home/runner/.docker/config.json engine container export --path=./bin/engine.tar --forced-compression=Gzip
panic: runtime error: slice bounds out of range [:77] with capacity 64

goroutine 1[19](https://github.com/dagger/dagger/actions/runs/9186832417/job/25263267560#step:4:20) [running]:
bytes.(*Buffer).grow(0xc00041b...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
angrybat
[dagger/dagger] Pull request opened: #7445 Fix powershell install script to work when on a different drive

Changed the default install path from $env:HOMEPATH to $env:USERPROFILE as this includes the drive. Currently when calling the install script on the D: drive the transfer from the temp directory to the install path fails. This is not reported as an error and the install script appears to have worked correctly. This is because $env:HOMEPATH does not include the drive in the path. Changing this to $env:USERPROFILE has the same path but the path includes the drive, this fixes the issue.

vivid lintelBOT
#
Xiot
[dagger/dagger] Issue opened: #7446 ๐Ÿž [Typescript] Object prototypes aren't preserved for fields

What is the issue?

Custom values that are stored in a @field do not have their prototype chain preserved.

This leads to unexpected behaviour, especially since objects need to be created as a class with @object in order to be serialized at all.

Dagger version

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

Steps to reproduce

I created a very simple module, that just passes a custom object between two modules.

@object()
class RootModule {
  ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
grouville
[dagger/dagger] Pull request opened: #7451 fix: check error on `normalizeCallerLoadedSource`

normalizeCallerLoadedSource function can segfault if withContextDirectory returns an error, as we do not check for the returned error on the withContextDirectory call.

The following dagql calls can be executed: on the dagger init, for example, the withName gets called on my tests, and trigger the segfault.

It is currently never triggered, as there are two potential edge cases in which we return an error on withContextDirectory:

  1. when the modulesourcekind is not local
  2. ...
vivid lintelBOT
vivid lintelBOT
#
vito
[dagger/dagger] Pull request opened: #7452 OTel cleanups + better draining
  • Adopt upstream logging SDK (still WIP - otelloggrpc is a noop for example)
  • De-duplicate github.com/dagger/dagger/telemetry and sdk/go/telemetry (no longer internal/)
    • dagger.io/dagger/telemetry is now the place where we centralize OTel setup across the Dagger CLI, engine, and SDKs.
  • Fix integration test suite OTel integration - now we'll have one span per connect(t), and one span will show up beneath them
    • [ ] Unfortunately testutil.Query call sites won't. Maybe w...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
MikaelElkiaer
[dagger/dagger] Issue opened: #7455 ๐Ÿž `dagger call --help` lists arguments as functions

What is the issue?

Fields in a module or custom type get listed as functions.
This is true at least for Go, have not tried others.

This is also true when using module constructors.

Dagger version

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

Steps to reproduce

I have a simple example here: https://github.com/MikaelElkiaer/daggerverse/blob/main/testing.go, from which I can run:

dagger --mod github.com/mikaelelkiaer/daggerverse call testing --help

...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7458 fix(go): leave and discard stdout

Instead of just closing it immediately. This could potentially result in the child process crashing with "broken pipe" if it accidentally wrote to this file descriptor.

This is a weird edge case discovered as part of investigating https://github.com/jedevc/dagger/tree/fix-weird-stall/examples/sdk/go/repro. This could have occurred if any primary output was detected during progress rendering: https://github.com/dagger/dagger/blob/24d1dcbc591c3d29c8d9ca12ea7cbd893cf14d55/dagql/idtui/frontend...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
shykes
[dagger/dagger] Issue opened: #7462 Allow defining a default view

We have a concept of directory "views" for filtering the contents of a directory, to avoid uploading its entire contents. A view can passed explicitly to the CLI with PATH[:VIEW]. For example dagger call build --source .:default. But there is no way to configure a view to be used by default.

command view used today view used in proposal
dagger call build --source .:foo foo โœ… foo
dagger call build --source . none โŒ default if it exists,...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
shykes
[dagger/dagger] Issue opened: #7466 One binary

Problem

Today Dagger is split in two components - a CLI and an OCI image - which are built and packaged separately, but should not be.

These components are tightly coupled: they are only usable together; must be upgraded together; the communication protocol between them is private and undocumented; and the functional boundary between them is not settled. The only reason for packaging them separately is that it's easier for us. But the price we (and our users) pay elsewhere may not be...

vivid lintelBOT
vivid lintelBOT
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7468 chore(deps): bump the sdk-java group in /sdk/java with 2 updates

Bumps the sdk-java group in /sdk/java with 2 updates: org.assertj:assertj-core and org.codehaus.mojo:exec-maven-plugin.

Updates org.assertj:assertj-core from 3.25.0 to 3.26.0

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

v.3.26.0
:boom: Breaking Changes
Core

Delegate OptionalDouble value comparison to Double.compare in hasValue assertion #3411

This fixes the comparison of NaN value...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
helderco
[dagger/dagger] Pull request opened: #7478 cli: add feedback on skipped functions

Follow-up to:

Core objects

At minimum this produces a debug level log for core functions, to reduce noise:

User objects

For module functions, itโ€™s raised as a warning to make it more visible to module authors:

dagger functions

In dagger functions, since itโ€™s just listing functions, itโ€™s shown in faded color at the end of the output:

Considerations

When listing functions with dagger call and wit...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7487 fix: create buildkit client before establishing telemetry connection

This ordering issue caused a couple of issues:

  • Error messages indicated telemetry issues, when actually the engine wasn't connected to properly.
  • The retry logic has exponential backoff that isn't capped - whereas newBuildkitClient uses buildkit's Wait which has a more reasonable default of retrying every second until a connection is established (which was our previous behavior before we added this telemetry).

This is a fairly likely cause of the issue that @marcosnils was see...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
marcosnils
[dagger/dagger] Issue opened: #7490 ๐Ÿž Dagger doesn't fail when using `kube-pod` scheme if `kubectl` is not present

What is the issue?

While using the kube-pod scheme in the _EXPERIMENTAL_DAGGER_RUNNER_HOST variable, if kubectl is not present where the dagger CLI is running, the CLI will just keep trying to connect to the engine indefinitely.

ref: https://discord.com/channels/707636530424053791/1245072471481385051

My assumption is that we're not handling this specific error upon connection and we're probably retrying indefinitely as part of the backoff retry connection strategy .

D...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7492 ci: add sdk all group

When we removed mage, we removed the easy helpers that allowed generating/linting/etc on all SDKs. That meant that making API changes became much more fiddly.

This patch restores the "all" group, but this time directly in the dagger module. One day, we might remove this with a script, but we don't have that right now.

vivid lintelBOT
vivid lintelBOT
#
carnage
[dagger/dagger] Pull request opened: #7493 [WIP] Add php runtime

Very minimal attempt at a PHP runtime for module support.

To the best of my knowledge, the go part of this PR is complete & working.

Outstanding is to write the PHP code to

  • Create a module entry point
  • Scan the user module src directory for dagger functions
  • Retrieve the call information from the dagger engine
  • Dispatch the call to the detected function
  • Return the result the the dagger engine
vivid lintelBOT
#
wingyplus
[dagger/dagger] Pull request opened: #7494 chore(sdk/elixir): improve elixir codegen part 2

In this PR, I do:

  • Move code template from EEx to iodata. I tried the EEx way for sometime but it's quite hard to modify the template when the logic get complicated. The iodata is quite a bit easier to read and easier to change the logic.
  • Add more unit tests, I use a library called mneme to do snapshot testing the code instead of adding assertion by hand. The tests aren't cover all the case but the important cases (object renderer) are most cover. We can add it more later.
  • Reduce...
vivid lintelBOT
#
grouville
[dagger/dagger] Pull request opened: #7496 chore: import `go-vcs` library with clean history

Context

First PR of a serie, splitting the implementation of https://github.com/dagger/dagger/pull/7420, in a cleaner way.

This one imports the codebase from https://github.com/grouville/go-vcs directly into our codebase for ease/maintainability purposes.

First commit

The first commit is Google's https://pkg.go.dev/golang.org/x/tools/go/vcs#RepoRootForImportPath filtered-history squashed into one, with all the context:

This commit adds a forked / improved version o...
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7497 ci: build dumb-init for target platform and add verification

dumb-init was accidentally always being built for the host platform, which meant if it was built on an x86 host the published arm64 image would incorrectly be x86.

This fixes that and also adds general purpose verification of all the binaries we build checking that they are of the expected target platform, to reduce the chances of this happening again.

Tested the verification logic by locally going back to building the dumb-init binary for the host platform and getting an error w...

#
marcomuser
[dagger/dagger] Issue opened: #7499 โœจ [TypeScript SDK] Consider using ECMAScript Decorators

What are you trying to do?

Currently, the TypeScript SDK uses experimental decorators that are considered deprecated. TypeScript has provided support for standard ECMAScript decorators since version 5.0. I would suggest considering the use of standard decorators over the now deprecated experimental decorator implementation which will never be usable from JavaScript and might even get removed from TypeScrip...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
marcosnils
[dagger/dagger] Issue opened: #7503 ๐Ÿž git operations don't work if they need to use an http proxy

What is the issue?

If the git operations in the engine require the HTTP_PROXY to be set, they'll not work given that the proxy values are not passed to the underlying git commands executed.

ref: #1244581784080093225 message

cc @sipsma

Dagger version

v0.11.5

Steps to reproduce

Try to perform a dagger call or dagger install of a module that requires a proxy server to be set in order to reach the ta...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
pjmagee
[dagger/dagger] Issue opened: #7505 ๐Ÿž Windows dagger CLI: no such file or directory when passing host *dagger.File

What is the issue?

I've been trying to follow the documentation on passing a file via the CLI.
It appears that the file is uploaded, but somehow there is an issue with the file being detected.

Using windows and following the default tutorial for host file access, it does not work on Windows

The weird part with -d is that this file seems to be "uploaded to the engine" fine..

    โœ” upload . from PATRICK-PC (client id: jhyf9iajxjh4gcitjjjlelp1i) (include: C:\Projects\example\...
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7506 cli: convert Windows paths to / slash format

Before this, file+dir arg values to dagger call on a Windows client were not converted from \ format to / format, which resulted in calls like filepath.Split in the Linux engine container to not work as expected.

Now the CLI calls filepath.ToSlash before sending paths, which helps handle the paths better in the engine container; specifically enough to avoid at least one bug that resulted in the engine trying to find a path at e.g. /C:\Foo\Bar.

To be clear, this is probably n...

vivid lintelBOT
vivid lintelBOT
#
y12studio
[dagger/dagger] Issue opened: #7508 Port not ready error when using --ports=8080:80 with dagger call build

What is the issue?

Issue:

When running dagger call build --source=. as-service up --ports=8080:80, I encounter a "port not ready" error. The error message indicates that the connection to 8080 is refused.

Steps to reproduce:

  • Run dagger call build --source=. as-service up --ports=8080:80
  • Observe the "port not ready" error
  $ dagger call   build --source=.   as-service   up --ports=8080:80
11:19:49 WRN canceling... (press again to exit immediately)

โ— Se...
vivid lintelBOT
#
michaeljohnalbers
[dagger/dagger] Issue opened: #7509 ๐Ÿž unhandled errors in a TaskGroup

What is the issue?

When using the Python SDK, many errors during development of functions are surfaced as

โ•ญโ”€ Error โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ•ฎ
โ”‚ Failed to unstructure result: unknown error (unhandled errors in a TaskGroup โ”‚
โ”‚ (1 sub-exception)) @ main.Common.build                                       โ”‚
โ•ฐโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ•ฏ

Turning on debugging doesn't provide anything m...

vivid lintelBOT
vivid lintelBOT
#
skycaptain
[dagger/dagger] Issue opened: #7510 ๐Ÿž New `--plain=progress` implementation swallows prints and logs from modules

What is the issue?

The new --plain=progress implementation shiped with v0.11.5 seems to swallow print statements and logs from modules among a lot of helpful debugging information (i.e. the command called).

Dagger version

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

Steps to reproduce

Take the following example:

import logging

from dagger import function, object_type
from dagger.log import configure_logging

configure_logging(logging.DEBUG)
l...
vivid lintelBOT
#
grouville
[dagger/dagger] Pull request opened: #7511 feat(core): allow other CIs than GitHub

Branched from https://github.com/dagger/dagger/pull/7496

This PR allows the use of other CIs than GitHub as a ref:

  • dagger functions
  • dagger install

In order to do it without changing the current logic, we do 2 things:

  • Extend parseRefString to actually try to isolate the root of the remote
  • Stat / fallback as a local source if not found

At the same time, we introduce a function to split the root and the subdir.
All this logic relies on Google's repoRootForImportPath func...

#
levlaz
[dagger/dagger] Issue opened: #7512 ๐Ÿž Dagger does not seem to work with Istio

What is the issue?

I'm adding this issue for tracking purposes.

We ran into networking issues where Dagger Engine deployed with Istio as a sidecar that runs dagger containers caused networking issues where the pods were not able to reach go package registry or npm. Removing istio from the equation resolved the issue.

Dagger version

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

Steps to reproduce

No response

Log output

No response

vivid lintelBOT
#
skycaptain
[dagger/dagger] Issue opened: #7513 ๐Ÿž Python SDK creates invalid syntax

What is the issue?

Take following example

SDK_ENTRYPOINT = f"""#!/bin/sh
# Source the environment setup file
. "$(find /sdk -type f -name 'environment-setup-*')"

# Execute CMD
exec "$@"
"""


@object_type
class SdkBuilder:
    sdk_entrypoint: str = SDK_ENTRYPOINT
    ...

Using this module as a dependency generates the following invalid Python code in sdk/src/dagger/client/gen.py:

...
def sdk_builder(self, sdk_entrypoint: str = "#!/bin/s...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jpadams
[dagger/dagger] Issue opened: #7515 โœจ Templates for Daggerizing a project from `dagger init`

What are you trying to do?

From @kpenfound :

What I propose is to have a built in scaffolder/template system to give you a starting module based on a specific template instead of the default grep-dir and container-echo sample. This would be similar to what you can do with rails, react, or other frameworks with scaffolders. Here's create-react-app for example https://create-react-app.dev/docs/getting-started/#selecting-a-template

This might look something like `dagger init ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
TomChv
[dagger/dagger] Pull request opened: #7518 fix(ts-sdk) rollback to npm to ignore packageManager field

#7096 introduced a regression by using yarn install --production. If the field packagaManager is set, it might lead to failure because yarn post v1.22.11 doesn't support the --production flag anymore, it has been removed in favor of yarn workspaces focus --production.

However, depending on the yarn major version (v2, v3, v4), the options are different but also the results and the way they handle subdependencies.

It seems npm is the only package manager that actually force inst...

vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7519 engine: fix engine panic during dagger call ... terminal with nesting

TODO:

  • [ ] Actually fix, just reproing in integ test so far and sending out so I don't forget about this
    • Problem is the engine hits a nil panic due to dagql.CurrentID() being nil during Query.RegisterClient, which is due to the fact that the terminal is being connected to direct over a websocket at that point, not via a gql query
    • This will also be fixed by https://github.com/dagger/dagger/pull/7315, so if that's merged first then I'll just throw this test in there so we have...
vivid lintelBOT
vivid lintelBOT
#
morlay
[dagger/dagger] Issue opened: #7520 ๐Ÿž [v0.11.5] `/usr/local/bin/dumb-init` is not aarch64 format in ghcr.io/dagger/engine:v0.11.5 for linux/arm64

What is the issue?

wrong format of /usr/local/bin/dumb-init
which will break in pure aarch64 host

Dagger version

v0.11.5

Steps to reproduce

docker run ghcr.io/dagger/engine:v0.11.5 in aarch64 host

$ docker cp dagger-engine-f3da0aa799eb2fd3:/usr/local/bin/dumb-init .tmp/dumb-init
$ file ./.tmp/dumb-init
./.tmp/dumb-init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

we could see the dumb-init is x86-64 format

other ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
yann-soubeyrand
[dagger/dagger] Issue opened: #7524 ๐Ÿž Idempotency issue with `dagger develop`

What is the issue?

When executing dagger develop several times in a row, the content of the dagger.gen.go file varies each time (blocks of code are reordered).

Dagger version

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

Steps to reproduce

git clone https://github.com/camptocamp/daggerverse.git
cd daggerverse/redhat
dagger develop
mv dagger.gen.go{,.bak}
dagger develop
diff -u --color dagger.gen.go{.bak,}

Log output

Possible output:

---...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7526 chore(deps): bump protobufjs from 7.2.4 to 7.3.0 in /examples/sdk/nodejs/pulumi/infra/ecs

Bumps protobufjs from 7.2.4 to 7.3.0.

Release notes
Sourced from protobufjs's releases.

protobufjs: v7.3.0
7.3.0 (2024-05-10)
Features

add handling for extension range options (#1990) (2d58011)

protobufjs: v7.2.6
7.2.6 (2024-01-16)
Bug Fixes

report missing import properly in loadSync (#1960) (af3ff83)

protobufjs: v7.2.5
7.2.5 (2023-08-21)
Bug Fixes

crash in comment parsing (#1890) (eaf9f0a)
deprecation warning for new Buffer (#1905) (e93286e...

vivid lintelBOT
#
shykes
[dagger/dagger] Issue opened: #7527 Don't reuse parent go.mod by default

Problem

When initializing a new dagger module with the Go SDK, by default no go.mod is created if a parent go.mod already exists. This is not the correct default behavior. It causes confusion, and in some cases can even break development altogether.

As a rule of thumb: by default, my dagger module should be an island. It should work the same regardless of what else is going on in the same repo. If I want my module's behavior to depend on another part of the repo, *that should be ex...

vivid lintelBOT
#
shykes
[dagger/dagger] Issue opened: #7528 Go SDK: support embedding structs

It would be cool if the Go SDK supported embedded another type. For example:

type *SuperDirectory {
  *dagger.Directory
}

// Extend the core directory type with an extra function
func (dir *SuperDirectory) Hello() string {
 return "world"
}

Since SuperDirectory embeds dagger.Directory, it inherits all the methods of the embedded type. But this embedding does not carry into the corresponding Dagger module. So, even though I can call SuperDirectory.Entries() ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jpadams
[dagger/dagger] Issue opened: #7531 ๐Ÿž Warning (`WRN`) from `dagger` cli when in an empty `git` repo without a `HEAD` commit

What is the issue?

Running an dagger cli command like version, help, or init will produce a warning line like

20:43:08 WRN failed to get repo HEAD err="reference not found"

Dagger version

dagger v0.11.6

Steps to reproduce

test-git-issue โžค ls -a
.  ..
test-git-issue โžค dagger version
dagger v0.11.6 (registry.dagger.io/engine) darwin/arm64
test-git-issue โžค git init -q
test-git-issue โžค dagger version                                                git...
vivid lintelBOT
vivid lintelBOT
#
vito
[dagger/dagger] Pull request opened: #7532 add `testctx` for instrumenting integration tests with OTel

based on #7452 - sorry for the large diff, wanted a PR up so I can see how it goes in CI

Adds testsctx, a little *testing.T compatible testing library that adds ctx propagation and middleware. Ideally we'd extract it for general use once it's fully baked so Go folks can use it and get pretty OTel integration in Cloud.

Adds the following testctx middleware to our integration test suite:

  • t.Parallel everywhere. Non-parallel tests have been adapted to work in parallel. (I t...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7536 docs: Improve more complex Dockerfile Example

Since we're building the flask-app example, we could call the container image that we're publishing flask-app too vs hello-dagger.

The image we build also doesn't really work to the intended purpose when run alone, which could reduce confidence:

docker run -it --rm ttl.sh/hello-dagger@sha256:bb01842ae62045a24fed30437cdb63901581ce83e82043e02131864b76d54716
 * Serving Flask app 'app.py'
 * Debug mode: off
WARNING: This is a development server. Do not use it in a ...
vivid lintelBOT
vivid lintelBOT
#
jpadams
[dagger/dagger] Issue opened: #7537 โœจ It should be really easy to get the most popular IDEs/editors set up for Dagger SDKs

What are you trying to do?

I want a very easy way to get my IDE/editor set up to do hinting/Intellisense/suggestion for any of the SDKs so I can use the Dagger API most effectively without having to look at a reference doc or try to remember the API and struggle.

Why is this important to you?

While learning Dagger or even as an advanced user, having suggestions or corrections from a language server/IDE is huge so I have a good experience coding in Dagger without making mistakes.

#...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7539 โœจ improve error in python when dependency is missing

What are you trying to do?

Right now if you don't have a dependency installed or specified in pyproject.toml you get an error that looks like this:

Error: input: module.withSource.initialize resolve: failed to initialize module: failed to call module "nostalgia" to get functions: call constructor: process "/runtime" did not complete successfully: exit code: 1

Stderr:
โ•ญโ”€ Error โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ•ฎ
โ”‚ The "main" module could n...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7541 ๐Ÿž daggerverse: weird formatting for python docstring in daggerverse

What is the issue?

Given this python docstring:

"""Apache Avro Tools

This module provides a set of functions to work with Apache Avro Tools.

Shorthand avro tools functions provided by this module are:

- idl2schemata: a helper function to Convert an Avro IDL file to Avro schema files in the provided directory
- idl: a helper function to Convert an Avro IDL file to an Avro schema file

For more advanced usage, you can use the avro-tools function to get a container with...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
pjmagee
[dagger/dagger] Issue opened: #7547 ๐Ÿž Windows user home directory support with ~

What is the issue?

Dagger does not seem to recognise the ~ on Windows and assumes the current working directory in combination with the ~ rather than being the current users home directory.

Dagger version

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

Steps to reproduce

I tried various approaches of the following

dagger -m github.com/pjmagee/dagger-heroes-decode@6c672139c5a5d5138ae608cd33af707c45a833c9 call decode --file "~\simple.StormReplay" stdout

...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
colin-rogers-dbt
[dagger/dagger] Issue opened: #7548 ๐Ÿž <title>

What is the issue?

We're experiencing transient issues pulling the dagger container:

1: connect ERROR: new client: failed to run container: Unable to find image 'registry.dagger.io/engine:v0.8.8' locally
docker: Error response from daemon: Get "https://registry.dagger.io/v2/engine/manifests/sha256:779fedd2902d251166eefe4fd1f00f71ab74e157b1e736fce4c6615b0fb1b321": net/http: TLS handshake timeout.
See 'docker run --help'.
: exit status 125
Error: new client: failed to run contain...
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7549 core: reduce module ID size by not including full schemas

Before this, we were passing full introspection schema JSONs as strings as args to non-Go SDKs, which resulted in them being included in the full IDs for non-Go modules.

Those strings got huge and could appear multiple times in a single ID, which inflated their size, and also ended up in progress output (I think the source of ETOOBIG?) + telemetry.

This has been a known issue for a while but not harmful enough to be prioritized for a fix. However, my [other PR](https://github.com/dagg...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
TomChv
[dagger/dagger] Pull request opened: #7551 fix(ts-sdk): fix subpath issue on codegen

@marcosnils raised an issue happening when loading a module as
a subpath of a root directory.

This leaded to an error happening during the diff

failed to diff generated code: select:
cannot diff with different relative paths

This PR fixes that issue by not creating a directory
as generated result code but instead reusing the
codegen dir.

Example now

{
  git(url:"github.com/marcosnils/daggerverse") {
    branch(name:"main") {
     tree { 
      ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7556 โœจ Add support for updating dagger modules via the CLI

What are you trying to do?

Right now upgrading modules to newer version is painful, especially because even if you put in the human readable tag version, when you run dagger develop it will be automatically converted to the git commit version instead.

We should allow people to specify tag versions in dagger.json and not have them rewritten to git commits, but we should also consider adding a mechanism similar to go get -u to check for newer versions and be able to apply those aut...

vivid lintelBOT
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7558 ๐Ÿž unable to export files with Windows CLI

What is the issue?

The dagger CLI crashes when trying to export a file in Windows. It looks like exporting a file attempts to do a chown and the CLI complains that this is not supported by Windows.

Dagger version

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

Steps to reproduce

Here is a simple function that reproduces the error on Windows, the error should happen with any function that tries to return a file.

    @function 
    def get_file(self) -> da...
#
levlaz
[dagger/dagger] Issue opened: #7559 ๐Ÿž error output in Windows is difficult to read

What is the issue?

The output in the terminal on Windows is very difficult to read because it seems that is is not able to handle the ANSI escape sequences properly. This behavior is the same on powershell and the command prompt.

See this issue for a concrete example but there are many different types of output that cause this.

Dagger version

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

Steps to reproduce

_No re...

vivid lintelBOT
vivid lintelBOT
#
marcosnils
[dagger/dagger] Issue opened: #7561 ๐Ÿž dagger init go SDK takes an excessive amount of time in codegen for large Go repositoryies

What is the issue?

coming from: https://discord.com/channels/707636530424053791/1248011149971292331

summary is that if you do a dagger init --sdk go in a large go codebase, the first cold codegen will take an excessive amount of time.

dagger could trace: https://dagger.cloud/marcos-test/traces/a996535073617e245051590c94cbb6e8

image

Dagger version

v0.11.6

Steps to reproduce...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
pjmagee
[dagger/dagger] Pull request opened: #7569 .\install.ps1 changes

#7560

  • Use [switch] for 'toggle' behaviour (.\install -Interactive)
  • Added interactive install (validates paths + some inputs)
  • Ensures semver provided is valid + not higher than latest version of dagger
  • Ensures the amd64/arm64/armv7 versions are installed by checking the arch of the system
  • Optionally adds dagger.exe to the PATH (off by default)
  • Correctly tells the user where it's installed with a friendly full path i.e C:\users\patrick\dagger
  • Uses github redirect of '/...
vivid lintelBOT
#
d3rp3tt3
[dagger/dagger] Issue opened: #7570 Update Dagger Cloud docs for `dagger login`

What is the issue?

Overview

It appears the updated functionality for dagger login was released, but the Dagger Cloud docs weren't updated. The new feature makes it A LOT easier to use Dagger Cloud from your dev machine.

What changed

Before: You added your Dagger Cloud token as an environment variable to send telemetry to Dagger Cloud from your dev machine.

Now: You can use the dagger login command to connect your dev machine to Dagger Cloud. You can use `dagg...

vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7571 Various TS + general test fixes + improvements

While debugging something nodejs-related in https://github.com/dagger/dagger/pull/7315 I noticed a bunch of problems with the TS tests and some related areas:

  1. Fix missing awaits in TS tests that caused accidental parallelism + tidy up env restoration: https://github.com/dagger/dagger/commit/15c43aef428a74dbe9c18d3c08ae2feba1e4a2d6 https://github.com/dagger/dagger/commit/32638a4809cfca968ebacddfb4e2428d9d769fed
  2. Fix bun image to be multiplatform and upgrade bun version to avoid SIGSEGV/...
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7573 ts: pin tsx version installed for modules

tsx pushed a release an hour ago that caused all Typescript modules to break out of band with errors like:

Transforming JavaScript decorators to the configured target environment
("node21.3.0") is not supported yet

It broke out-of-band because our install of tsx was not pinned to any version. I pinned it now to the previous patch release and things work again.

Hopefully there's some better way of pinning this version since it's currently just a direct npm install call and ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
shykes
[dagger/dagger] Issue opened: #7582 Can't return an interface

The interface documentation shows how to define an interface and use it in arguments. But it doesn't show how to use the interface in the return value. I tried, but it doesn't seem to be possible.

It would be very useful to make this possible.

Example:

type Check interface {
 Pass() bool
 Details() string
}

type MyCheck struct {}

func (c *MyCheck) Pass() bool {
  return true
}

func (c *MyCheck) Details(...
vivid lintelBOT
#
sipsma
[dagger/dagger] Issue opened: #7583 All Typescript modules fail to run due to `Transforming JavaScript decorators`

(related PR https://github.com/dagger/dagger/pull/7573, creating an issue for tracking+visibility)

Currently, all typescript modules will fail to run due to a breaking change pushed to tsx (issue), which the typescript SDK did not pin the version of in all previous engine releases.

  • If your engine has a local cache of previous typescript SDK calls, it may work for a while until that local cache gets pruned

The error message looks li...

vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Issue opened: #7585 Make all SDKs usable from git refs

Background: the root cause of https://github.com/dagger/dagger/issues/7583 was lack of pinning deps in the typescript sdk (one of the unpinned ones updated out of band and broke every ts module in all previous engine releases) but it was made much more painful by the fact that we needed to do an engine release in order to fix it rather than just patching the TS SDK.

If we could instead allow users to easily import all of the builtin SDKs as git refs if they want, that would improve this si...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sagikazarmark
[dagger/dagger] Issue opened: #7593 ๐Ÿž Builds timeout on GitHub Actions

What is the issue?

I've seen an increase in builds timing out on GitHub Actions recently (~since the beginning of May).

Here is an example: https://github.com/openmeterio/openmeter/actions/runs/9443871398/job/26008370834?pr=984

I don't have a strong lead, but it seems to me that runs generally hang at service executions.

Dagger version

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

Steps to reproduce

No response

Log output

No response

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
gerhard
[dagger/dagger] Pull request opened: #7596 helm: Allow disabling --oci-max-parallelism num-cpu

While we are keeping this default so that we don't break existing users, setting this value is something that we want to move away from.

The problem is that this setting limits how many operations can run in parallel. It is still possible for a single operation to max out all available cores. It is also known for a value of 2 to cause deadlocks, i.e. https://github.com/dagger/dagger/issues/6894

For now, we just allow this to be disabled with either --set engine.args='' or by explici...

vivid lintelBOT
vivid lintelBOT
#
marcosnils
[dagger/dagger] Issue opened: #7599 ๐Ÿž initial `connect` o a newly spawned engine "sometimes" takes a lot of time

What is the issue?

I have observed that sometimes when calling Dagger the first time (engine gets started) the connect step takes an excessive amount of time.

ref: #maintainers message

Dagger version

v0.11.6

Steps to reproduce

It's hard to consistently reproduce since it happens sometimes. What I do to repro is removing the engine container and then trying to run

Log output

130|marcos:tmp/lala (ma...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7603 ci: enable best-effort cache reuse for nested engines

We were previously always putting a random id in the cache volume used for engines created in various CI functions, which meant none of them ever had any local cache. The main reason was that two engines can't use the same local cache at the same time.

We can't lift that limitation, but by using the engine version and private cache mounts we can get best effort re-use of these cache volumes, which is a simple enough performance improvement for some cases that we may as well take it.

vivid lintelBOT
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7604 chore(deps): bump webpack-dev-middleware from 5.3.3 to 5.3.4 in /examples/sdk/nodejs/react-build

Bumps webpack-dev-middleware from 5.3.3 to 5.3.4.

Release notes
Sourced from webpack-dev-middleware's releases.

v5.3.4
5.3.4 (2024-03-20)
Bug Fixes

security: do not allow to read files above (#1779) (189c4ac)

Changelog
Sourced from webpack-dev-middleware's changelog.

5.3.4 (2024-03-20)
Bug Fixes

security: do not allow to read files above (#1779) (189c4ac)

Commits

86071ea chore(release): 5.3.4
189c4ac fix(security): do not allo...

#
vito
[dagger/dagger] Pull request opened: #7605 OTel log draining follow-ups
  • Standardize on slog everywhere that we print output from the engine, instead of "faking" stdout/stderr in places.
    • Goal: SpanLogger no longer leaves ambiguity as to whether caller needs to Close(). It never does.
    • We will no longer drain to ensure we get every last log, but this was never really an issue, doesn't seem worthwhile atm.
  • Rename telemetry.Logs to telemetry.SpanStdio so its intentions are clearer.
    • Goal: again, remove ambiguity as to whether caller need...
vivid lintelBOT
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7607 chore(deps): bump rustls from 0.21.10 to 0.21.12 in /sdk/rust

Bumps rustls from 0.21.10 to 0.21.12.

Commits

3633152 Cargo: v0.21.11 -> v0.21.12
0baaeba proj: MSRV 1.61 -> 1.63
6fd691a tls13: fix clippy::unnecessary_lazy_evaluations finding
6da5337 Test for illegal IP address in server name extension
75f8857 Ignore server_name extension containing IP address
7b8d1db Prepare 0.21.11
ebcb478 complete_io: bail out if progress is impossible
20f35df Regression test for complete_io infinite loop bug
2f2aae1 Don't spe...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7608 engine: fix context error wrapping in executor

When an exec fails due to context canceled, we were dropping the cancelation error and just returning the exec error. I believe this got fat-fingered while updating the code from upstream to use fmt.Errorf instead of github.com/pkg/errors.

It's not clear if this is really meaningful, but noticed it changed while attempting to debug occurances of "exit code 137" in our CI, which plausibly could be related to all of this. It's possible there's calling code that tries to handle cancelation wi...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7610 executor: fix deadlock in service exit from netns workers

There was a race condition where contexts get canceled after a job is sent to the netns worker but before the result got read. This caused runInNetNS to exit (due to canceled context) but the result chan to never be read from. It was crucially an unbuffered chan, which resulted in the worker never being able to exit and the whole container cleanup to block indefinitely.

The fix here is just to make that chan buffered with a size of 1 so that the worker doesn't ever get blocked trying to wr...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
gerhard
[dagger/dagger] Issue opened: #7614 ๐Ÿž TypeScript module runtime: Type Error: Cannot read properties of null (reading 'trim')

What is the issue?

Have hit this when starting with a clean state, no previous Dagger Engine container running. Was reviewing:

This is the exact command that I was running: dagger call image --source=.:app --token=env:GH_TOKEN

image

As this is a transient issue, it might be difficult to reproduce. Creating this issue s...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
pjmagee
[dagger/dagger] Pull request opened: #7620 Adding winget to goreleaser

Attempting to solve #6441

This seems like a more Dagger supported method for installation because:

  • Its supported by existing goreleaser
  • It handles the checksum
  • winget allows the portable zip binary
  • It can also handle adding the install to the users PATH via an alias
  • Supports simple uninstall and upgrades of the Cli

I have used the existing package Id that was already found by someone who published the 0.9.6 to Winget, since that time, I have published 2 versions bu...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7621 chore(deps): bump github.com/Azure/azure-sdk-for-go/sdk/azidentity from 1.1.0 to 1.6.0

Bumps github.com/Azure/azure-sdk-for-go/sdk/azidentity from 1.1.0 to 1.6.0.

Release notes
Sourced from github.com/Azure/azure-sdk-for-go/sdk/azidentity's releases.

sdk/internal/v1.6.0
1.6.0 (2024-04-16)
Features Added

Options types for SetBodilessMatcher and SetDefaultMatcher now embed RecordingOptions
Added a collection of default sanitizers for test recordings

sdk/azidentity/v1.6.0
1.6.0 (2024-06-10)
Features Added

NewOnBehalfOfCredentialWit...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7622 chore(deps): bump @grpc/grpc-js from 1.10.6 to 1.10.9 in /sdk/typescript

Bumps @grpc/grpc-js from 1.10.6 to 1.10.9.

Release notes
Sourced from @โ€‹grpc/grpc-js's releases.

@โ€‹grpc/grpc-js 1.10.9

Avoid buffering significantly more than grpc.max_receive_message_size per received message.

@โ€‹grpc/grpc-js 1.10.8

Fix a bug that caused channels with unix: targets to not reconnect after the channel goes idle (#2750)

@โ€‹grpc/grpc-js 1.10.7

Improve reporting of HTTP error codes (#2723)
Update dependency on @grpc/proto-loader to the la...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7623 chore(deps): bump golang.org/x/net from 0.20.0 to 0.23.0 in /sdk/elixir/runtime

Bumps golang.org/x/net from 0.20.0 to 0.23.0.

Commits

c48da13 http2: fix TestServerContinuationFlood flakes
762b58d http2: fix tipos in comment
ba87210 http2: close connections when receiving too many headers
ebc8168 all: fix some typos
3678185 http2: make TestCanonicalHeaderCacheGrowth faster
448c44f http2: remove clientTester
c7877ac http2: convert the remaining clientTester tests to testClientConn
d8870b0 http2: use synthetic time in TestIdleConnTimeout
d...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7624 chore(deps): bump requests from 2.31.0 to 2.32.2 in /sdk/python

Bumps requests from 2.31.0 to 2.32.2.

Release notes
Sourced from requests's releases.

v2.32.2
2.32.2 (2024-05-21)
Deprecations

To provide a more stable migration for custom HTTPAdapters impacted
by the CVE changes in 2.32.0, we've renamed _get_connection to
a new public API, get_connection_with_tls_context. Existing custom
HTTPAdapters will need to migrate their code to use this new API.
get_connection is considered deprecated in all versions of Requests...

#
dependabot[bot]
[dagger/dagger] Pull request opened: #7625 chore(deps): bump jinja2 from 3.1.3 to 3.1.4 in /sdk/python

Bumps jinja2 from 3.1.3 to 3.1.4.

Release notes
Sourced from jinja2's releases.

3.1.4
This is the Jinja 3.1.4 security release, which fixes security issues and bugs but does not otherwise change behavior and should not result in breaking changes.
PyPI: https://pypi.org/project/Jinja2/3.1.4/
Changes: https://jinja.palletsprojects.com/en/3.1.x/changes/#version-3-1-4

The xmlattr filter does not allow keys with / solidus, > greater-than sign, or = equals ...

vivid lintelBOT
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7627 chore(deps): bump braces from 3.0.2 to 3.0.3 in /sdk/typescript

Bumps braces from 3.0.2 to 3.0.3.

Commits

74b2db2 3.0.3
88f1429 update eslint. lint, fix unit tests.
415d660 Snyk js braces 6838727 (#40)
190510f fix tests, skip 1 test in test/braces.expand
716eb9f readme bump
a5851e5 Merge pull request #37 from coderaiser/fix/vulnerability
2092bd1 feature: braces: add maxSymbols (https://github.com/micromatch/braces/issues/...
9f5b4cf fix: vulnerability (https://security.snyk.io/vuln/SNYK-JS-BRACES-6838727)
98414f9 ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7633 ci: start linting install.sh

Create a new ci/std/shellcheck module using https://github.com/koalaman/shellcheck, and enable checks for our scripts in CI.

This check would have caught https://github.com/dagger/dagger/pull/7617, and would have errored out with:

$ dagger call --source=.:default scripts lint
โœ˜ DaggerScripts.lint: Void 4.1s
! call function "Lint": process "/runtime" did not complete successfully: exit code: 2
โ”ƒ invoke: input: shellcheck.check.assert resolve: call function "Assert": process "/r...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
Xiot
[dagger/dagger] Issue opened: #7637 โœจ Support `--depth` when using `dag.git`

What are you trying to do?

Trying to pull down more history for a ref than just the single commit.

The request is to have a property on the dag.git to specify the depth (number of commits) to checkout

Why is this important to you?

We currently have a couple different jobs within our workflow that rely on checking the differences between the given commit and its parent.

How are you currently working around this?

Right now, we are using dag.git to do the initial checko...

vivid lintelBOT
#
jedevc
[dagger/dagger] Issue opened: #7640 Module versioning compatability

In the upcoming v0.12 release, we plan to make a few backwards incompatible changes to the API. This includes:

  • Changing function signatures
  • Removal of deprecated fields
  • etc.

However, these changes will likely require updates to module code, across the ecosystem. We want to make this transition as easy as possible - when users upgrade their cli/engine versions, they shouldn't need to worry about manually ensuring compatibility with their engines.

There are a couple of approach...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Issue opened: #7645 Tunnel hang w/ nested engines

If you use the v0.11.7 CLI and run e.g. dagger -m . call --source=.:default test custom --timeout=10m --run=TestModuleDaggerUp --pkg=./core/integration --race=true --parallel=8 on main you'll currently get a hang after the tests pass.

  • Note: this won't currently impact any users, it's only an issue on main atm when using v0.11.7 as the CLI

This is due to OTEL draining spans from the CLI's session attachable server (engine logs show waiting on TunnelListener/Listen). The CLI is gettin...

vivid lintelBOT
#
shykes
[dagger/dagger] Issue opened: #7647 Context directory

Problem

Dagger modules are often contextual: they are used in the context of another software projet. Almost always, these modules need to access their context directory - typically the project's source code.

  • Today a module cannot directly access its context directory. Instead it must be passed by the caller as an argument. This is inconvenient.
  • To make things worse, modules cannot filter the contents of the context directory. This is essential to avoid the prohibitive c...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7648 ci: fix git publish tag confusion

Follow up to #7631

This is fairly fiddly to do correctly. Essentially, we need to be able to handle at least these inputs:

  • Branch names, like main
  • Tag names, like v0.11.7
  • Full refs, like refs/pull//merge

We can't simply use git fetch , since that doesn't create a local ref copy. We shouldn't use a refspec that mirrors to a single name, since that strips refs/tag/... which means tags are lost.

The correct way to do this is using a git fetch refspec, to mirror all ...

vivid lintelBOT
#
marcosnils
[dagger/dagger] Issue opened: #7652 ๐Ÿž Python SDK code generation is incorrect for functions with `dagger.Container` type

What is the issue?

While installing this the following module dagger install github.com/vito/daggerverse/testcontainers@a1647750b3ef09b83091b40185f498bb995ed540 in a dagger python project, the generated setup function (https://github.com/vito/daggerverse/blob/a1647750b3ef09b83091b40185f498bb995ed540/testcontainers/main.go#L28) has an incorrect signature.

The generated code is:

    def setup(self, ctr: Self) -> Container:

It should have generated:

 ...
#
jedevc
[dagger/dagger] Pull request opened: #7653 fix: improve plain progress log chunks

There were a couple of weird whitespace handling issues with the plain progress.

  1. If a program produces logs at pace, then ExportLogs will be called on large chunks, and is not guaranteed to end with a newline. In this case, that last line should be marked as pending, and we should hold it until the rest of that line is received (flushing any unfinished lines when the span terminates).
  2. If a program writes "\r" carriage return characters in the middle of a line, we were essentially wr...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Issue opened: #7662 flakey test: `TestPythonProjectLayout` - `The "main" module could not be found`

Saw this fail here: https://github.com/dagger/dagger/actions/runs/9509605842/job/26212800646?pr=7660

Don't have the cloud trace on hand because it got re-run and couldn't find it in the history. But ugly output extracted from GHA logs is:

2024-06-14T02:27:54.5780199Z 122 :     [5m41.8s] |     module_python_test.go:306: 
2024-06-14T02:27:54.5781462Z 122 :     [5m41.8s] |         	Error Trace:	/app/core/integration/module_python_te...
vivid lintelBOT
vivid lintelBOT
#
grouville
[dagger/dagger] Pull request opened: #7663 chore: add integration tests to other VCS

โš ๏ธ This is an ugly implementation atm (lots of copy-paste), but it is a foundation for the question:

  • what testing strategy do we want over the modules integration tests, across VCS ?

In the current state of the PR, It basically covers every test relying on the modules test repo with its public GitLab equivalent

This won't work as is for bitbucket (because of a different valid HTMLURL), and tests will probably need to be extended to not dumbly fail over refs with .git (which wor...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
nipuna-perera
[dagger/dagger] Issue opened: #7668 โœจ Dagger CLI: `dagger develop` with recursive code gen for multi module repositories

What are you trying to do?

Creating a "Daggerverse" that has many modules residing in the same Git repository is a common practice today. However, not everyone will commit the generated code up to the repository as it is not required for general dagger operations.

I need a way to tell dagger to recursively go into each of my modules and generate code with a single command so that I can lint the dagger modules without running into errors based on missing generated code.

Why is th...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
vito
[dagger/dagger] Issue opened: #7672 test flake: TestContainerSystemProxies

https://dagger.cloud/dagger/traces/b8f44fb34378e1f9d5da38345ee13551?span=d826e8f9b0dc1572&logs#d826e8f9b0dc1572:L1385

=== FAIL: core/integration TestContainerSystemProxies/git_uses_proxy/git-proxy-logs (0.00s)

    proxy_test.go:360: 

        	Error Trace:	/app/core/integration/proxy_test.go:360

        	            				/app/core/integration/proxy_test.go:228

        	Error:      	"1718561860.060      0 10.88.0.161 NONE_NONE/000 0 - error:transaction-end-before-headers - HI...
vivid lintelBOT
#
skycaptain
[dagger/dagger] Issue opened: #7673 ๐Ÿž Regression of #7057 with v0.11.7

What is the issue?

It appears issue #7057 has recurred in v0.11.7 (also tested with the latest b213c4f88de0f4bfa164e047276d717024b78cb2). Now, it occurs with all progress modes. As before, the issue arises in CI where only --progress=plain is available. Long-running tasks may be canceled if nothing is printed for a certain period. It would be beneficial to have the ability to read the log while the build is running.

Dagger version

dagger dev-071bba814c2411bb8ab5c016897210711f0f26...

vivid lintelBOT
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7675 chore(deps): bump the sdk-python group in /sdk/python with 2 updates

Bumps the sdk-python group in /sdk/python with 2 updates: docutils and protobuf.

Updates docutils from 0.20.1 to 0.21.2

Updates protobuf from 4.25.3 to 5.27.1

Commits

3d9f7c4 Updating version.json and repo version numbers to: 27.1
368b9b2 Merge pull request #17019 from protocolbuffers/cp-27
2717ae7 Internal change
9a37881 Always report plugin support errors from protoc.
f61d89c Avoid ODR violations from ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
netikras
[dagger/dagger] Issue opened: #7678 ๐Ÿž Dagger CLI does not have a way to pass with-exec arguments containing commas

What is the issue?

discord: #1252253912405381141 message

Hi!

How can I supply a command to a dagger-cli that would accept arguments containing a comma? Is there any syntax to escape commas from parsing?

cmd="trivy fs --dependency-tree --scanners vuln,misconfig,secret --severity,UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL --output trivy-report.out -f table --exit-code 7 ./"

dagger -m github.com/shykes/daggerverse/wolfi call ...
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7679 Fix forced simplification infinite progress loop on high verbosity settings

Reported by @vito in an internal discord: #1250122361131499664 message

huh, running that command with --debug or -vvv seems to cause the CLI to eat up all of my memory, seems like a bug with the call simplification code

last time this came up it was because of a call simplifying to itself or something and ending up in a loop, all the memory usage is from trying to render the indentation

Turns out, the changes to call sim...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
vito
[dagger/dagger] Issue opened: #7681 test flake: TestRemoteCacheRegistrySeparateImportExport - `connection refused` reaching registry

https://dagger.cloud/dagger/traces/321f2e777c47c9ca7651a28633a08420?span=79134fa449a2f409&logs#79134fa449a2f409:L3797`

Error: make request: input: container.from.withExec.stdout resolve: failed to copy: httpReadSeeker: failed open: failed to do request: Get "http://registry:5000/v2/test-cache-a/blobs/sha256:c74b3fa9b6e492458102dbd87edf33967a1863e12ac8a138fbc12c6f87483f18": dial tcp 10.88.0.107:5000: connect: connection refused

Test:       	TestRemoteCacheRegistrySeparateImportExpor...
vivid lintelBOT
vivid lintelBOT
#
jpadams
[dagger/dagger] Issue opened: #7684 ๐Ÿž GitHub and GitLab urls supplied as arguments for Directory assume `main` even if that's not the default branch

What is the issue?

When a user provides a git url, for example as a Directory argument, without any branch, tag, commit sha, etc, then we assume they want #main.
https://github.com/dagger/dagger/blob/main/cmd/dagger/flags.go#L253-L268

But the default_branch might be master (most common alternative) or maybe something else. So we shouldn't assume.

The default_branch can be looked up before pulling, but requires access to the git server over the network. For example:

``...

vivid lintelBOT
vivid lintelBOT
#
vito
[dagger/dagger] Pull request opened: #7686 tui: associate effects to their origin, not their unlazier

based on #7671

The place where something becomes un-lazied is not that useful. Better to show effects at their point of origin instead.

This also effectively works around a Buildkit bug that ends up associating LLB to incorrect spans[^1], which would sometimes put a failed span beneath a succeeding one, making it especially hard to find.

[^1]: possibly from here which the race detector is also unhappy with)

  • [ ...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7696 tests: attempt to deflake proxy tests

I couldn't repro this locally but there were occasional CI flakes in the proxy test that pulls a git repo and verifies the proxy logs show a connection to github.com (needed to verify that git ops correctly use proxy settings).

My best guess is that the squid logs were just not always flushed by the time they were read for the test assertion, so this updates the tests to explicitly start/stop the squid service and do some retries on reading the logs.

Will have to see if this actually fi...

vivid lintelBOT
vivid lintelBOT
#
levlaz
[dagger/dagger] Issue opened: #7698 ๐Ÿž Unable to Publish Module due to dagger version mismatch

What is the issue?

I created a new module using dagger 0.11.7 on my laptop. When I try to publish it on Daggerverse, it complains that the highest supported go from go mod is 1.22.3

I think this is because the daggerverse is still running 0.11.6

I think we should do one or both of these things to address this:

  1. Make sure that daggerverse is always running latest version of Dagger because a lot of current module authors are always running latest.
  2. Handle the case when t...
#
sipsma
[dagger/dagger] Issue opened: #7699 ephemeral `context canceled` errors

This has been reported by users and seen occasionally in CI. Most recent occurrence I saw was here https://github.com/dagger/dagger/actions/runs/9551005799/job/26324343803

That passed on many re-runs and also tried running SDK tests again in commits around it without it happening again.

I've been trying to repro what happens in that elixir SDK check failure locally since yesterday but have not replicated it.

  • To be clear, I don't think this has anything to do with the elixir SDK, the ...
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7700 engine: log buildkit solve error stack traces

Buildkit does all sorts of special context.Cause error handling but still sets all the errors to just be context.Canceled, only difference being wrapping them with hidden stack traces from the github.com/pkg/errors package.

To help debug where context canceled errors are coming from, it's useful to see these stack traces so we can get more than "context canceled". To do this we need to log the errors with the formatting directive %+v.

Related to https://github.com/dagger/dagger/i...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7705 feat: add automatic sdk cli versioning

This is part of a piece of a more general piece of work to improve our own releasing process.

TL;DR: our releasing process (defined in https://github.com/dagger/dagger/blob/main/RELEASING.md) has steadily become more and more complex over time. Now that we're aiming for faster release cadences (at least once every couple of weeks, and often once a week), this process is starting to incur a lot of overhead. (I estimate I probably spend at least half a day per release). We can take some of t...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
shykes
[dagger/dagger] Issue opened: #7707 Unbundle the SDK: client without runtime, or runtime without client

Problem

A Dagger SDK can do 2 things:

  1. Generate client bindings to consume functions and types from other modules
  2. Build a runtime to provide new functions and types

These two features are tightly coupled: an SDK must implement both or it is considered incomplete. A module is expected to use both, or it is probably "doing it wrong".

But there are cases where I don't actually want both:

  • Example 1: I want to run Dagger pipelines from my software, without running my soft...
vivid lintelBOT
#
grouville
[dagger/dagger] Pull request opened: #7708 feat(core): add private git support

WIP implementation of private Git support (works, just not with a generic / nice ref yet)

This is rebased on top of #7663, which adds integration tests and fixes some of the VCS logic.

Core changes

  • Following @sipsma's work to securely isolate sockets per sessions. We can now automatically and securely load the SSH socket when the SSH_AUTH_SOCK env variable is set. This is the auth that will be used to access the private repo.
  • File / Directory passed as CLI args do not rely ...
#
shykes
[dagger/dagger] Issue opened: #7709 Get a file's digest

Problem

The Dagger API doesn't provide an efficient way to compute a file's digest. Which, in turn, makes it impossible to efficiently compare two files, or check if a file has changed for example. There are workarounds, but they either add complexity, hurt performance, or both.

Solution

Add a function to compute a file's digest. Ideally reusing the underlying buildkit digest.

extend type File {
  """
  Return the file's digest.
  The format of the digest is n...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
becojo
[dagger/dagger] Issue opened: #7712 ๐Ÿž using HEAD as ref of a git repository

What is the issue?

When using a git repository URL for a directory argument, Dagger seems to assume that the default branch is named main. This is often not the case.

I also cannot use HEAD as ref. You can see in the error message the commit HEAD is pointing to but Dagger does not handle it.

When Dagger is provided a Git URL without ref, it should mimic a git clone of that URL and not guess the default branch.

Dagger version

dagger v0.11.6 (registry.dagger.io/engine)...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
gerhard
[dagger/dagger] Pull request opened: #7718 Publish Wolfi Engine variants - with & without NVIDIA drivers support

This publishes two new image variants:

  1. *-wolfi
  2. *-wolfi-gpu

We want to take this through the paces - automated & manual tests - and check if it's feasible to consolidate all images into a single one: Wolfi with NVIDIA.

I have also made it clearer in workflow descriptions that this isn't a GPU image variant. While NVIDIA is the dominant GPU vendor today, Intel & AMD are still relevant and in some cases ahead (e.g. Aurora & Frontier supercomputers). A bunch of homelabbers (includin...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
danielwegener
[dagger/dagger] Issue opened: #7721 โœจ Build-Kit Build reproducibility in Dagger

What are you trying to do?

I'd love to have binary reproducible builds (motivation: https://reproducible-builds.org/) in dagger.

Why is this important to you?

Beside its nice security properties, I'd also love the fact, that I could use it for stable image pinning and actual change detection in k8s deployments (as image digests would only change if the underlying application does change).

How are you currently working around this?

Directory.withTimestamp helps, but sometime...

vivid lintelBOT
#
sporto
[dagger/dagger] Issue opened: #7722 Typescript / Node examples are different than the generated code, thus confusing

What is the issue?

When following the getting started with Dagger using the typescript SDK. You get a file which uses a class with decorators.

I was trying to create a db service. Which needs to mount a host directory.

Then looking at https://github.com/dagger/dagger/tree/main/examples/sdk/nodejs, you find these examples using a very different approach i.e. using connect. This is confusing, not very clear how you would translate what you see in those examples to the class approac...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
dependabot[bot]
[dagger/dagger] Pull request opened: #7728 chore(deps): bump github.com/99designs/gqlgen from 0.17.44 to 0.17.49 in /sdk/go in the sdk-go group

Bumps the sdk-go group in /sdk/go with 1 update: github.com/99designs/gqlgen.

Updates github.com/99designs/gqlgen from 0.17.44 to 0.17.49

Release notes
Sourced from github.com/99designs/gqlgen's releases.

v0.17.49
What's Changed

chore(deps): bump golang.org/x/text from 0.15.0 to 0.16.0 in /_examples by @โ€‹dependabot in 99designs/gqlgen#3123
chore(deps-dev): bump vite from 5.2.12 to 5.2.13 in /integration by @โ€‹dependabot in 99designs/gqlgen#3126
chor...

#
sipsma
[dagger/dagger] Issue opened: #7732 bug: service stop gets called multiple times in error cases and results in timeouts

Context: I was working on the final PR for passing sockets as args and had a bug that caused the Tunnel in c2h.go to return an error. That was just a bug in the WIP code, but the failure mode I saw was very weird and repros on main: the session close timed out.

After questioning my fundamental sanity for a while, I finally realized that for some reason the service stop callback got called multiple times in this error case, which is bad because it does a select on an exited channel that...

vivid lintelBOT
vivid lintelBOT
#
jedevc
[dagger/dagger] Issue opened: #7733 Allow easy healthcheck for the dagger engine

Spun out from this discord discussion: #1253636253358755840 message

It's currently quite difficult to write a healthcheck for the dagger engine itself - how do you know if it's running, and ready to accept connections?

Previously, you used to be able to use the buildctl command to connect manually (but that was removed), or even use a dummy dagger query command (but that was also removed).

We should make it easy to run a ...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
vito
[dagger/dagger] Pull request opened: #7735 More OTel fixes, mostly service-related

A few more fixes/simplifications for OTel + draining found in the process of working on #7532. With these changes I'm finally able to reliably run our instrumented integration tests without any spans "left behind" (even services).

โœ” connect 0.2s
โœ” initialize 13.0s
โœ” prepare 0.8s
โœ” ModuleSource.resolveFromCaller: ModuleSource! 0.1s
โœ” ModuleSource.resolveDirectoryFromCaller(path: ".", viewName: "default"): Directory! 0.0s
โœ” dagger(
    source: โœ” ModuleSource.resolveDirectoryFromCa...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7738 engine: prune local cache after sessions disconnect

We used to prune the local cache after sessions ended, but this got dropped during recent refactoring so now the local cache is only being pruned at engine startup.

This re-adds that gc call on session disconnect.

This is obviously in dire need of integration tests, but setting those up is a decent chunk of work so prioritizing the fix first and will follow-up immediately with that test coverage.

For now, I verified the fix manually with a local test that runs an exec that consumes m...

vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
TomChv
[dagger/dagger] Pull request opened: #7740 fix(ts-sdk): correctly resolve non-primitive default value

There was an issue that created an error when a non-primitive default value was set to a function like

@object()
class Default {
  @func()
  a(
    dir: Directory = dag.directory()
      .withNewFile("/foo", "hello world")
    ): Container {
    return dag.container().withMountedDirectory("/dir", dir)
  }
}

This commit fixes the issue to ignore the default value registration if it's not a primitive type and let the TypeScript runtime resolve it during the ex...

#
sipsma
[dagger/dagger] Pull request opened: #7741 Cherry-picks and release notes for v0.11.9

First commit is cherry-pick of https://github.com/dagger/dagger/commit/6708971d052bad4d9ea3c3f19077e7ed81a43939

Second commit is the standard release notes as generated with instructions already in RELEASING.md.

Note that because this is a separate branch directly off v0.11.8, this PR is merging into that branch rather than main.

vivid lintelBOT
#
cbochs
[dagger/dagger] Issue opened: #7743 ๐Ÿž Inconsistent handling of env var inputs when used in dagger functions

What is the issue?

Dagger accepts secret parameters in the form of env:ENV_VAR. However, this is not broadly the case for all parameters. It is unexpected and inconsistent that non-secrets do not respect this form and require you to pass in environment variables as $ENV_VAR instead. For example,

dagger call -m example \
    test \
    --version env:MY_VERSION \ # does NOT work as intended
    --name    $MY_NAME \       # need to use this form instead
    --secret  env:MY_...
vivid lintelBOT
#
TomChv
[dagger/dagger] Pull request opened: #7744 Feat/context directory

API changes

This PR updates the Function and FunctionArg from our engine API to support defaultPathFromContext

# Function

  withArg(
    """
    If the argument is a Directory or File type, default to load path from context directory, relative to root directory.
    """
    defaultPathFromContext: String = ""
# }

# FunctionArg {

  """
  If the argument is a Directory or File type, default to load path from context directory, relative to root directory.
...
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7747 Improve releasing during v0.11.9

Opening this against the release-v0.11.9 branch for now. We will want to "forward-port" it to main also, will handle that along-side forward-porting https://github.com/dagger/dagger/pull/7745

  • tbh I'm not 100% sure how necessary it is to merge this to the release-v0.11.9 branch vs. only doing it to main, but doing it anyways during the first run-through of "publish from non-main branch" out of caution

TODOs (these are only strictly required for the main branch, so may end up just...

vivid lintelBOT
vivid lintelBOT
#
sipsma
[dagger/dagger] Pull request opened: #7748 docs: update RELEASING.md with non-main branch instructions

WIP updates to instructions on differing instructions when releasing from non-main branch.

Not done, sending out early so I can see it as rendered markdown.

It's honestly kind of challenging to figure out the best way to present this. There's a lot of overlap in the instructions, but also a lot of little divergence points. Will do what I can to get the information here while keeping it comprehensible.

vivid lintelBOT
#
jedevc
[dagger/dagger] Pull request opened: #7749 fix: ensure gc policy percentage is correct

When originally updating this in #7563, we only updated the default CLI option - however, this is confusing, and isn't exactly how that works - my suggested refactor wasn't actually correct.

Because we use GlobalIsSet, this default is never actually the one that's used. So, we can refactor this, and set a global const to define the default gc policy ourselves, outside of buildkit.

This also opens us up to modifying the gc policy in more detail in the future.