#github-feed
1 messages ยท Page 9 of 1
We display the error message instead of the whole stack trace so it's easier for the user to catch the error.
Before
(node:30) [DEP0128] DeprecationWarning: Invalid 'main' field in '/src/dagger-docs/error-handling/sdk/package.json' of 'dist/index.js'. Please either fix that or report it to the module author
(Use `node --trace-deprecation ...` to show where the warning was created)
(node:30) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userla...
What are you trying to do?
I'm trying to use dockerBuild() with a Dockerfile containing the statement RUN --mount=type=ssh ... to forward the SSH agent to the build container so I can fetch packages from private repositories.
Why is this important to you?
We can already pass the ssh agent socket when using a container so I thought this feature would be great to close the gap in feature parity when it comes down to build an image with a Dockerfile in dagger.
How are you cur...
Another fix for https://github.com/dagger/dagger/issues/6706 - we're not gonna get any full compete solution that happily manages all the go versions before v0.10, but this at least can warn users when a weird case happens.
We've already got protections for the case of making a new module from scratch (the most common case), but this adds a similar protection for creating using an existing go.mod file.
This is tricky, since the scalar aliases were getting lost in our TypeDef code. We can preserve these, and then provide a custom parser.
With this, we can add validation that the target platform is valid, as well as allow a special current platform, which allows this use case:
package main
import (
"fmt"
)
type Playground struct{}
func (m *Playground) Hello(platform Platform) string {
return fmt.Sprintf("hello i am platform %q", platform)
}
โฏ dagge...
What is the issue?
seeing these panics, running 0.9.11 dagger-engine, 0.9.11 dagger CLI, and 0.9.11 client:
goroutine 760 [running]:
net/http.(*conn).serve.func1()
/usr/local/go/src/net/http/server.go:1868 +0xb0
panic({0xd0af20?, 0x4000092b70?})
/usr/local/go/src/runtime/panic.go:920 +0x26c
github.com/dagger/dagge...
The engine complains if the Host API is used with non-absolute paths. For the CLI's use case, this is not really meaningful since the user is explicitly passing paths anyways so we can safely make the paths absolute on the user's behalf automatically.
Adding to v0.10 since it's an annoying enough papercut and the fix is extremely trivial (vast majority of additions here are test code)
There's linting errors on main right now, just including the generated code for these so we can lint them (also patched one legit linter complaint about extra whitespace in one of the files)
Found myself calling this all over the place; I don't think we really meant to leak this out since it was originally an implementation detail of the DagQL switch. Directory.asModule and ModuleSource.asModule seem like the two main APIs for loading modules so it seems like they should return a fully instantiated one.
Funnily enough this doesn't seem to be a breaking change, since you can call initialize.initialize.initialize just fine. I saw there was a TODO to remove initialize ent...
Right now you can't invoke Functions that accept args of type Socket from the CLI. In theory, this should be as simple as supporting e.g. dagger call fn --sock unix:///var/run/docker/docker.sock or dagger fn --sock tcp://localhost:1234, etc.
However, we need to be very careful when implementing this to not accidentally create a backdoor where any (malicious) module could gain access to any host socket. I think this will require explicit tracking of which modules have access to a give...
Before this, it was technically possible for a module to make a raw graphql query to the Host.unixSocket API and gain access to any unix socket on the main client caller's host (i.e. where the CLI is running). This is due to the fact that the socket attachable currently has to be hardcoded to always refer to the main client caller (which in turn is due to relevant grpc metadata not being forwarded by buildkit yet in those codepaths).
Now we just enforce that this API can only ever be calle...
Summary
While documenting optional and default values in Python functions I came upon some inconsistencies in implementations due to different assumptions. The term โOptionalโ thatโs used in modules is misleading.
Terminology
In Python, an argument that is optional is one with a default value because the true meaning of โoptionalโ is that it can be omitted.
def foo(bar: str = ""): ...
In GraphQL itโs mostly the same, with the exception that a **nullabl...
Addresses Python inconsistency in:
TODO: Working on test cases.
panics can result in some bizarre error reports - for example:
failed to check version compatibility: Post "http://dagger/query": context canceled
panic: get tree hash: Post "http://dagger/query": context canceled
goroutine 51 [running]:
github.com/dagger/dagger/internal/mage/util.CIDevEngineContainer({0x90a140, 0xc0002be000}, 0xc00011a9c0, {0xc0000efb00, 0x1, 0xc00011e1d0?})
/home/jedevc/Documents/Projects/dagger/dagger/internal/mage/util/engine.go:163 +0x5db
github.com/dagg...
There's not a huge reason to include debug=true in tests - these logs add huge amounts of extra logging, that is often not particularly helpful during debugging.
For local development, with ./hack/dev, these were already enabled with the --debug flag - it's just with the engine for tests.
Tiny fix for a broken link in zenith docs.
This issue found during work on wttr module [1] that is a prototype of the Elixir for Dagger Module, the error is silent when send the output from wttr back to the function call. After investigate it, it has 2 issues:
- The
executefunction silent the error. It returns ok tuple with error result, cause a function process incorrectly. - The graphql builder didn't escape
\got graphql server returns 403 parse error to the client.
This patch fix those issues above.
[1] https:...
This PR was auto-generated.
Fixes: https://github.com/dagger/dagger/issues/6719
See individual commit messages for explanations.
Running the full TestModule suite locally now shows RSS maxing out around 1GB (still high-ish but much more reasonable than 6GB). And most importantly, whereas previously the engine's RSS stayed high after the test suite ended (it stuck around 2-3 GB RSS), now the RSS drops down to reasonable 600MB afterwards, with pprof showing reasonable usage mostly from buildkit's in memory cac...
Fixes https://github.com/dagger/dagger/issues/6725
This is a pre-req for a number of issues in the v0.10.x milestone and pretty trivial so just figured I'd get it out of the way now.
What is the issue?
Not sure why this is happening, made my best guess with the title.
When I call my github.com/vito/bass module and pass the repo as an arg, it successfully clones the repo for the module, but the subsequent clone for the arg hangs.
Dagger version
dagger v0.10.0
Steps to reproduce
dagger call -m github.com/vito/bass --src git://github.com/vito/bass unit --packages ./pkg/bass
Don't think the commit matters, but for reference HEAD is curre...
This commit updates the text on the docs index page to match the quickstart index
to avoid unnecessarily long shutdown times when using the remote cache
service, we should only sync the cachemounts that have been seen by the engine
previously. This helps in the specific scenario were pipelines are
cached and cache mount re-uplodas are unnecessary.
Signed-off-by: Marcos Lilljedahl
Thanks @vito for the suggestion: https://github.com/dagger/dagger/pull/6759#discussion_r1504696242
This now adds linting to the engine and the go sdk for go.mod consistency. An error looks something like this:
Error: Generated code mismatch. Please run `go mod tidy`:
--- go.mod
+++ go.mod
@@ -4,12 +4,9 @@
replace dagger.io/dagger => ./sdk/go
-require (
- dagger.io/dagger v0.10.0
-)
+require dagger.io/dagger v0.10.0
require (
- dagger.io/dagger v0.10.0
gith...
Agh, I screwed up.
In fefce56 (#6750), I accidentally committed some local code, which then got missed in review.
As suggested by @helderco in https://github.com/dagger/dagger/pull/6744#pullrequestreview-1902308392.
This brings it inline with how you can currently pass git directories.
Usage:
dagger call thing --file https://github.com/dagger/dagger.git#main:README.md
Or with an implicit branch:
dagger call thing --file https://github.com/dagger/dagger.git#:README.md
See https://github.com/dagger/dagger/actions/runs/8075163921/job/22061629460?pr=6765 (in dagger cloud: https://dagger.cloud/dagger/runs/5a27b0b5-cf3a-4d29-b357-0ca9cfa946ff)
We get this utterly incomprehensible error message:
1179 multi.go:85: [35m59:[0m exec dagger --debug develop [32mDONE[0m
1180 module_test.go:3432:
1181 Error Trace: /app/core/integration/module_test.go:3432
1182 Error:
1183 Test: TestModuleCodegenOnDepChange/...
What is the issue?
The error message output by this should correctly indicate that two sibling modules being referenced must live within the same git context. This will allow end users to much more easily understand why this is failing
Dagger version
dagger v0.10.0 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
โ /tmp rm -rf test
โ /tmp mkdir test
โ /tmp cd test
โ test mkdir mod1
โ test mkdir mod2
โ test cd mod1
โ mod1 dagger ...
Fixes #6743.
We have a message size limit enforced by the gRPC connection - however, we then go to host a HTTP server on that connection, and we weren't performing any restrictions on the size of the Writes.
To resolve this, for any Write that is larger than (an adjusted for headers) size limit, we split it into multiple Write calls which will split it into several BytesMessages by the grpchijack package.
Note: no such transformation is required for Reads, since go permit...
This effectively reverts #5983, since with go.work support we can't have duplicate module names inside a single namespace.
Thankfully though, we can avoid the original issue that this fixed (where go is effectively a reserved module name), by prefixing all module names with dagger/).
This helps for daggerverse-like repo structures, where the top-level go.work would ideally need to contain all the sub-modules.
This commit adds a note to the Dagger Cloud get started.
What are you trying to do?
Provide a way to define possible argument values of functions.
Expose functions as json in dagger functions.
[
{
"Name": "containerEcho",
"Description": "example usage: \"dagger call container-echo --string-arg yo stdout\"",
"ReturnType": {
"Kind": "OBJECT_KIND",
"Optional": false,
"AsObject": {
"Name": "Container",
...
What happened? What did you expect to happen?
Hello everyone,
I'm new to Dagger and I wanted to inquire about the process of launching modules from private repositories, if possible.
For instance, through the CLI (dagger call) or integration into various CI/CD engines.
Here's my scenario:
I have a private GitHub repository that contains Dagger modules, and I'd like to provide third parties with the ability to include them in their GitHub Actions pipeline.
Is this feasible?...
This adds Kapa AI to the Dagger docs, which we're testing to see if it provides a great UX for people to quickly get answers to their Dagger-related questions.
Few releases ago, dagger mod init created a .gitignore file in the module's source directory.
We discussed today with @sipsma and @shykes to possibly add this back. Especially it would clear out questions regarding what files need to be committed with the rest of the code.
Discord ref: #daggernauts message
Previously, we suggested that users mount sensitive directories in "userspace" from their own code: https://docs.dagger.io/guides/457482/create-app-ci-module/#step-6-add-a-function-to-run-the-application-as-a-local-service
But that no longer is viable when just using dagger call.
Off the top of my head thoughts are to either:
- Create a new core type like
SecretDirectoryor some...
What is the issue?
Before Dagger modules we built a pipeline for our micro services in a Go module we named service. Trying to migrate it to modules I can generate the module with dagger init --sdk=go service however when I try to run dagger call container-echo --string-arg='Hello Daggernauts!' stdout I get the following `
โ initialize 0.5s
โ ModuleSource.asModule: Module! 0.1s
โ Module.initialize: Module! 0.2s
โ exec go build -o /runtime . 0.2s
โ # main
...
Bumps golang.org/x/sys from 0.16.0 to 0.17.0.
Commits
914b96c windows: support ill-formed UTF-16 in UTF16PtrToString
511ec84 Revert "windows: support nil done parameter in ReadFile and WriteFile"
628365d windows: support nil done parameter in ReadFile and WriteFile
bef1bd8 unix: move mksyscall regexp to package level variables
5710a32 unix/linux: update Linux kernel to 6.7
b3ce6a3 windows: build env_windows_test.go only go Go 1.21 and above
c3fa2b8...
Bumps github.com/stretchr/testify from 1.8.4 to 1.9.0.
Release notes
Sourced from github.com/stretchr/testify's releases.
v1.9.0
What's Changed
Fix Go modules version by @โSuperQ in stretchr/testify#1394
Document that require is not safe to call in created goroutines by @โprogrammer04 in stretchr/testify#1392
Remove myself from MAINTAINERS.md by @โmvdkleijn in stretchr/testify#1367
Correct spelling/grammar by @โecharrod in stretchr/testify#1389
docs: ...
Bumps golang.org/x/oauth2 from 0.16.0 to 0.17.0.
Commits
ebe81ad go.mod: update golang.org/x dependencies
adffd94 google/internal/externalaccount: update serviceAccountImpersonationRE to supp...
deefa7e google/downscope: add DownscopingConfig.UniverseDomain to support TPC
See full diff in compare view
[
4d78dc5 Add forwarding close methods to several writer implementations (#636)
c1ab4ed Make Log.Fatal() call Close on the writer before os.Exit(1) (#634)
417580d add: ContextLogger Interface LogObjectMarshaler (#623)
602e90a Fixed failing tests (#626)
a9ec232 Add stacktrace to Context (#630)
3e8ae07 Refactor: change Hook(h Hook) to Hook(hooks ...Hook) (#629)
7fa45a...
Bumps golang.org/x/crypto from 0.18.0 to 0.20.0.
Commits
0aab8d0 all: update go.mod x/net dependency
5bead59 ocsp: don't use iota for externally defined constants
1a86580 x/crypto/internal/poly1305: improve sum_ppc64le.s
1c981e6 ssh/test: don't use DSA keys in integrations tests, update test RSA key
62c9f17 x509roots/nss: manually exclude a confusingly constrained root
405cb3b go.mod: update golang.org/x dependencies
913d3ae x509roots/fallback: update bun...
Bumps httpx from 0.26.0 to 0.27.0.
Release notes
Sourced from httpx's releases.
Version 0.27.0
0.27.0 (21st February, 2024)
Deprecated
The app=... shortcut has been deprecated. Use the explicit style of transport=httpx.WSGITransport() or transport=httpx.ASGITransport() instead.
Fixed
Respect the http1 argument while configuring proxy transports. (#3023)
Fix RFC 2069 mode digest authentication. (#3045)
Changelog
Sourced from httpx's changelog.
0.27....
Bumps pytest-httpx from 0.29.0 to 0.30.0.
Release notes
Sourced from pytest-httpx's releases.
0.30.0 (2024-02-21)
Changed
Requires httpx==0.27.*
Fixed
Switch from setup.py to pyproject.toml (many thanks to Felix Scherz).
Changelog
Sourced from pytest-httpx's changelog.
[0.30.0] - 2024-02-21
Changed
Requires httpx==0.27.*
Fixed
Switch from setup.py to pyproject.toml (many thanks to Felix Scherz).
Commits
36c5062 Merge pull request #1...
Bumps certifi from 2023.11.17 to 2024.2.2.
Commits
45eb611 2024.02.02 (#266)
83f4f04 fix leaking certificate issue (#265)
bbf2208 Bump actions/upload-artifact from 4.2.0 to 4.3.0 (#264)
9e837a5 Bump actions/upload-artifact from 4.1.0 to 4.2.0 (#262)
05d071b Bump actions/upload-artifact from 4.0.0 to 4.1.0 (#261)
2a3088a Bump actions/download-artifact from 4.1.0 to 4.1.1 (#260)
d4ca66e Bump actions/upload-artifact from 3.1.3 to 4.0.0 (#258)
5d1566...
Bumps ruff from 0.1.14 to 0.3.0.
Release notes
Sourced from ruff's releases.
v0.3.0
This release introduces the new Ruff formatter 2024.2 style and adds a new lint rule to
detect invalid formatter suppression comments.
Changes
Preview features
[flake8-bandit] Remove suspicious-lxml-import (S410) (#10154)
[pycodestyle] Allow os.environ modifications between imports (E402) (#10066)
[pycodestyle] Don't warn about a single whitespace character before a comm...
Bumps anyio from 4.2.0 to 4.3.0.
Release notes
Sourced from anyio's releases.
4.3.0
Added support for the Python 3.12 walk_up keyword argument in anyio.Path.relative_to() (PR by Colin Taylor)
Fixed passing total_tokens to anyio.CapacityLimiter() as a keyword argument not working on the trio backend (#515)
Fixed Process.aclose() not performing the minimum level of necessary cleanup when cancelled. Previously:
Cancellation of Process.aclose() could...
Bumps golang.org/x/mod from 0.14.0 to 0.15.0.
Commits
fa1ba42 sumdb: replace globsMatchPath with module.MatchPrefixPatterns
See full diff in compare view
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-up...
Bumps github.com/stretchr/testify from 1.8.3 to 1.9.0.
Release notes
Sourced from github.com/stretchr/testify's releases.
v1.9.0
What's Changed
Fix Go modules version by @โSuperQ in stretchr/testify#1394
Document that require is not safe to call in created goroutines by @โprogrammer04 in stretchr/testify#1392
Remove myself from MAINTAINERS.md by @โmvdkleijn in stretchr/testify#1367
Correct spelling/grammar by @โecharrod in stretchr/testify#1389
docs: ...
Bumps org.mockito:mockito-core from 5.10.0 to 5.11.0.
Release notes
Sourced from org.mockito:mockito-core's releases.
v5.11.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.11.0
2024-03-01 - 17 commit(s) by Aouichaoui Youssef, Franz Wong, Pranoti Durugkar, Rรณbert Papp, dependabot[bot]
Fixes #3281 : Add native method to exception message of MissingMethodIโฆ (#3283)
MissingMethodInvocationException is thrown when mocking ...
Bumps org.codehaus.mojo:exec-maven-plugin from 3.1.0 to 3.2.0.
Release notes
Sourced from org.codehaus.mojo:exec-maven-plugin's releases.
3.2.0
๐ New features and improvements
Enable to exec:java runnables and not only mains with loosely coupled injections (#408) @โrmannibucau
Try to get rid of legacy API which can break starting with java 17 (#409) @โrmannibucau
๐ Bug Fixes
Fix #401 - Maven v4 compatibility (#414) @โslawekjaranowski
๐ฆ D...
Bumps de.m3y.maven:inject-maven-plugin from 1.5 to 1.7.
Release notes
Sourced from de.m3y.maven:inject-maven-plugin's releases.
1.7
What's Changed
Require Maven 3.9+ #161
Full Changelog: https://github.com/marcelmay/inject-maven-plugin/compare/inject-maven-plugin-1.6...inject-maven-plugin-1.7
1.6
What's Changed
Fix path issue on Windows by @โHelmutWiedemann in marcelmay/inject-maven-plugin#160
Bump net.bytebuddy:byte-buddy from 1.14.10 ...
Bumps eslint from 8.56.0 to 8.57.0.
Release notes
Sourced from eslint's releases.
v8.57.0
Features
1120b9b feat: Add loadESLint() API method for v8 (#18098) (Nicholas C. Zakas)
dca7d0f feat: Enable eslint.config.mjs and eslint.config.cjs (#18066) (Nitin Kumar)
Bug Fixes
2196d97 fix: handle absolute file paths in FlatRuleTester (#18064) (Nitin Kumar)
69dd1d1 fix: Ensure config keys are printed for config errors (#18067) (Nitin Kumar)
9852a31 fix: deep m...
Add ExperimentalPrivilegedNesting args in DefaultTerminalCmdOpts and TerminalOpts.
Add InsecureRootCapabilities args in DefaultTerminalCmdOpts and TerminalOpts.
I did some test with a local module I made but I struggle figuring out how to test it in our integration's test.
I know we have module_terminal_test.go for terminal tests and container_test.go for inscure and nesting params but I cannot figure out a nice way to combine both because this requires extra installation...
This is a spin-off of work on https://github.com/dagger/dagger/issues/6747, which has proven itself to be a fountain side-quests all over the codebase. Splitting that effort up into separate PRs for everyone's sanity. There will be at least more pre-req PR (for improving dagql ID digest performance to support walking IDs efficiently) before the "final act" of the actual user-facing features.
This change results in each client getting its own buildkit.Client and buildkit Session. As a s...
What is the issue?
The output from when running a dagger functions command on Windows is not correctly formatted. When running with --progress plain, the output is as expected, but when running with --progress tty, it is adding D[85D[85D[85D85D right before the output and without a newline.
Dagger version
dagger v0.10.0 (registry.dagger.io/engine) windows/amd64
Steps to reproduce
Run dagger -m github.com/shykes/daggerverse/hello@v0.1.2 call hello
Running with t...
Fixes regression from #6601, see discord discussion.
Essentially, it became possible to construct an input which would apply the secret accessor translation twice. If one of the frontend inputs was constructed from dagger, it could already have an accessor secret ID as part of it's build graph (if WithExec was used alongside a secret).
However, this input could appear inside the frontend request - which would resu...
Follow-up on comments from https://github.com/dagger/dagger/pull/6352#discussion_r1439349557.
Getting kinda annoyed with all the dependabot spam :cry:
- By moving from once-a-month to once-a-week, we stay more on top of changes, which means there should be fewer to address all at once. Additionally, I've set the time to trigger on Monday morning - that way, we can hopefully review and merge before the next release.
- I've also used
groups to try and ensure that each set of updates is...
This PR does three things, mostly to reduce overhead of creating several distinct PRs and move this forward quickly:
- Bumps the Docusaurus version
- Adds Typescript support. This makes it easier to work with swizzled/custom components and creating custom plugins.
- Allows multiple versions to be consumed by the guides plugin, by passing the versions through the plugins field of the
docusaurus.config.tsfile.
Feel free to comment if you think this should be separated into multiple PRs!
Problem
When installing a specific dependency into a downstream Go module, the downstream Go module starts to fail with codegen-related errors.
- The dependency is valid: calling it directly from the CLI works
- The error is Go-specific: when installing the same dependency on a Python downstream module, there is no error
- The error seems related to the module's name and contents. Specifically the module name is
dockerand it contains a top-level functionCLI(in Go). It seems ...
There are 2 pages in the current quickstart that contain the experimental note
"Daggerize A Project" and "Write your first function"
This removes that note from those two pages
this PR allows use to set engine image repo.
use case: in corporate settings, usually we have airgapped env and must be able to load images from private registry (mirror).
Implement Dagger Functions for our official markdown linter. Example usage:
dagger call -m github.com/dagger/dagger/functions/linters/markdown \
fix --source ./docs \
export --path ./docs
This is not wired into our CI, but can be used during development.
Due to an undetected conflict, we added a new method BuiltinContainer, which accessed the old Client property.
This fixes the CI failure on main: https://github.com/dagger/dagger/commit/62ced562b1bdd69f35b5112d0d2736a2d2189c7a
Following of #6685 to update the test publish job.
It's weird but some test are not run on push and so we didn't caught this erorr.
https://github.com/dagger/dagger/blob/1759f47a7c6bc8cc13380e193f6f7a1248ca6e0d/.github/workflows/publish.yml#L93
Normally this fixes works and fixes:
Btw, do we actually need these tests? Since we are using Dagger modules now, we don't have use that provisioning feature anymore.
Bumps golang.org/x/mod from 0.14.0 to 0.16.0.
Commits
766dc5d modfile: use new go version string format in WorkFile.add error
fa1ba42 sumdb: replace globsMatchPath with module.MatchPrefixPatterns
See full diff in compare view
[](https://docs.github.com/...
After changes in https://github.com/dagger/dagger/pull/6774, the package name has changed from main to dagger/ - the docs need updating to reflect this.
Follow-up to https://github.com/dagger/dagger/pull/6819
We also need this version update for test-provision-typescript-linux.
See https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/
Saw these warnings on https://github.com/dagger/dagger/actions/runs/8154660264:
We should upgrade our actions versions to fix this.
Updated while fixing the dev module but it's taking longer so this just quickly updates most packages (only used in CI), which supersedes dependabot PRs:
- #6792
- #6793
- #6794
- #6796
Limited pytest, ruff and black due to breaking changes. There's a bigger refactor coming that upgrades these packages.
This PR was auto-generated.
Think this is a regression in v0.10.1 cc @TomChv
See https://github.com/dagger/dagger/pull/6805/files#r1513137070
goroutine 457496 [running]:
runtime/debug.Stack()
/usr/local/go/src/runtime/debug/stack.go:24 +0x5e
github.com/dagger/dagger/dagql.(*Server).resolvePath.func1()
/app/dagql/server.go:642 +0x74
panic({0x1bd65a0?, 0x3139130?})
/usr/local/go/src/runtime/panic.go:914 +0x21f
github.com/dagger/dagger/core/schema.(*containerSchema).terminal(0x1d3a040?, {0x2299038, 0x...
This commit adds a CLI cookbook for common CLI tasks.
This PR is a follow up to #6522 with new features:
- Add
bumpcommand to replace mage's - Bump node default version to
18 - Improve documentation
- Disable outdated provisioning test
โ ๏ธ I'm not sure that the test disabling is accurate because @jedevc told me we would still support connect function without module.
Let me know if I should revert that part, I only did it so now all functions in the modules work and there's only publish to support in order to completely be comp...
since we were using filepath.Join instead of url.JoinPath, the symbolic
URL was not being generated correctly. It was prefixing https:/
instead of https://
Signed-off-by: Marcos Lilljedahl
Improve the TypeScript module internal to be easier to maintain and more clear.
This refactor aims to abstract the scan logic using classes to hide the complexity and expose a simpler interface to interact with. By doing so, we no longer need standalone functions to do the introspection, the class is responsible for his own introspection.
After completing the refactor, most of the scan old code with be replaced by the new logic.
This refactor also aims to simplify some logic with the T...
What is the issue?
When a function has an optional argument with a list of lists, the function is callable from a programmatic way but from the cli an error is thrown.
Link to discord [discussion](#daggernauts message)
Dagger version
dagger v0.10.0 (registry.dagger.io/engine) linux/amd64
Steps to reproduce
You need to have in your module a function with an optional list of lists like that:
type MyMo...
(TODO more detailed description, but uh, yeah, does what it says on the tin, mostly, still wip)
This is another spin-off of https://github.com/dagger/dagger/issues/6747 (sibling to https://github.com/dagger/dagger/pull/6806) with the goal of enabling us to efficiently "walk" IDs in order to find all instances of a given type embedded in their DAG.
This is accomplished by updating the dagql ID format to store a map of digest->fields for ID with that digest, with any other references to IDs being via that digest (whereas previously we recursively repeated every ID every time it occ...
...not just the last one. Not quite sure why I missed this before, but this occurs in some test cases (that are really annoying to add test cases for some reason).
This fixes up the logic from #6809 - see the discord conversation in #1212602528890363955 message.
Not 100% sure why the previous fix wasn't right, but this definitely works, and I don't really have the time to dive into exactly what I'm misunderstanding.
What is the issue?
We have been getting reports of no space left on device errors with Dagger v0.10.x running on GitHub Actions runners. This issue is mean to centralise private discussions and make it transparent to anyone that is affected by this.
If you are affected by this issue, please leave a comment with as much details that you are able to share publicly. We are especially interested in:
- When did you first notice this issue?
- Which version of Dagger are you using?
...
What is the license of the code generated by running dagger init, considering it creates some files without adding an SPDX-License-Identifier?
What are you trying to do?
The current behavior is to load the hosts .docker/config into the dagger session so that existing registry authentications can be used. While this is generally a convenience, there are cases where this is not desirable and there should be an option to opt out of this behavior
Why is this important to you?
No response
How are you currently working around this?
No response
This PR introduces a fully-operational ci/ directory, replacing the old non-functional one.
This new CI allows for all of the following:
- Running our tests
- Utilities like linting, code-gen, bumping
- Building the engine/cli/sdks
[!WARNING]
This isn't fully ready yet, but opening a work-in-progress PR to make it easier to track.
A few things I've realized while doing this that I think are technically out-of-scope for this particular piece of work, but we should make ...
Right now the experience is a bit strange on the docs page because clicking the logo takes you back to the marketing page. We should have this go to the home page of the docs page and perhaps add a new link to go to the marketing site.
Reported here: https://github.com/dagger/dagger/pull/6829#discussion_r1513464630
Based on my testing, the following did not work:
dagger call foo --token env:TOKEN
echo $TOKEN > token.txt
dagger call foo --token file:./token.txt
Breaking out the file parsing code, the token.txt would be parsed with a newline character at the end.
This adds TrimSpace() to file and cmd secret inputs. TrimSpace() trims leading and trailing unicode whitespace characters. I can't thin...
https://github.com/dagger/dagger/pull/6503 removed most of the content of the zenith/ top-level directory, but we kept the README.md around to keep pointing users to the docs.
However, I don't think we're linking to this from anywhere anymore, and now that functions/modules have launched and have a permanent home in the docs, it doesn't really make sense to keep this folder anymore.
What happened? What did you expect to happen?
Previously I had a working Build function with old dagger v0.9 way to build from Dockerfile and push to private registry:
// build image and push to registry
func Build() {
ctx := context.Background()
// initialize Dagger client
client, err := dagger.Connect(ctx, dagger.WithLogOutput(os.Stdout))
if err != nil {
panic(err)
}
defer client.Close()
godotenv.Load()
// read secret from host variable
tag := os.Getenv(...
Follow-up to https://github.com/dagger/dagger/pull/6716 - people were using Query as a method name, see [discord](#daggernauts message).
This could cause name clashes and was annoying. Thankfully, there's only one legitimate need for this field to be public - interfaces.
We can provide a workaround for this with the new WithGraphQLQuery method on generated types, which resets the underlying type, and sets the query.
...
What is the issue?
The generated code missing the private graphql.Client
https://github.com/dagger/dagger/blob/v0.10.1/sdk/go/dagger.gen.go#L5580-L5597
https://github.com/dagger/dagger/blob/v0.10.0/sdk/go/dagger.gen.go#L5745-L5763
Dagger version
v0.10.1
Steps to reproduce
No response
Log output
No response
Should fix https://github.com/dagger/dagger/issues/6850 (cc @morlay)
This regressed in https://github.com/dagger/dagger/pull/6716, and meant that child clients were invalid, and couldn't be called with Do(), as well as causing GraphQLClient() to return an invalid nil value.
This only previously worked because the GraphQL client and the dagger client shared the same name client. When this property was removed, the propagation stopped working. Now, we make this special case explicit...
Bumps https://github.com/tonistiigi/fsutil to current master
Diff:
Relevant to us, this brings in:
- https://github.com/tonistiigi/fsutil/pull/169
- This should unblock https://github.com/moby/buildkit/pull/4455 (cc @sipsma)
- https://github.com/tonistiigi/fsutil/pull/183
- This fixes https://github.com/dagger/dagger/issues/6687 (cc @vito)
What is the issue?
I'm following the steps described in the docs for chaining a terminall command to a container output and the following error appears.
> dagger call -m github.com/shykes/daggerverse/wolfi@v0.1.2 container --packages=cowsay terminal
โ Wolfi.container(packages: ["cowsay"]): Container! 1.5s
โ exec /runtime 1.5s
โ Apko.wolfi(packages: ["cowsay"...
This string is not formatted properly.
There is an extra space in the CLI snippet that causes the command to fail with the following error:
levlaz@Levs-MacBook-Pro ts % dagger call build --source=https://github.com/golang/example/#master:hello --os=linux --architecture =amd64 terminal
zsh: amd64 not found
Removing this space fixes it.
What is the issue?
Some users have reported some issues while getting started with dagger about dagger develop not apparently working as expected. In most of those cases we found out that they didn't run dagger init before calling dagger develop which yielded to some unexpected results.
@shykes suggested (#1215438073694003300 message) making dagger develop to fail if no dagger.json is found which seems reasonable
...
Fixes https://github.com/dagger/dagger/issues/6155 and https://github.com/dagger/dagger/issues/6606
Adds support for views as described in the linked issue to support filtering individual directory args. This also required adding a way of configuring this from the CLI, which entailed all the work of fleshing out dagger config, so that's done now too.
Examples:
# create a new view named cool-view
dagger config views set --name cool-view '**/*.go' '!bin/'
# use the view
...
What is the issue?
When attempting to execute a function that includes an argument named json, I encounter an error, despite anticipating it would function correctly.
This issue arises in the context of developing a Dagger function for cloc. Given that the command-line interface offers options such as --json and --yaml, I aimed to directly correlate these with a boolean parameter in the Dagger function.
Dagger version
dagger v0.10.1 (reg...
Trying out the python dev guide and think there is a self missing here.
Output without self:
dagger call hello-world
โ daggerPotato: DaggerPotato! 0.5s
โ exec /runtime 0.5s
โ DaggerPotato.helloWorld: String! 0.6s
โ exec /runtime 0.6s
โ โญโ Error โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ ...
dagger call/install/develop/publish/functions/config all now take into account the find-up we do of dagger.json so they can work from subdirs.
dagger init is a special case where we don't findup since it would prevent you from initializing a module from a subdir of another.
What happened? What did you expect to happen?
Recently, I was trying to automate Docker builds and was experimenting with different Dagger features.
Trying to assign the whole built image to a variable led to an unexpected error. For example:
image = await client.container().build(
context=workspace, dockerfile=dockerfile_basename
)
value = await image.as_tarball()
printable = await value.contents()
print(printable)
results in such error:
ERROR:root:Unexpecte...
This commit adds a guide about module publishing and links to it from the developer sidebar.
When using multiple files, the src/main.py file should be turned into a package (i.e., src/main/__init__.py). This is explained in https://docs.dagger.io/developer-guide/python/820256/module-structure#multiple-files.
However, it's an easy oversight for users that adds confusion, so dagger init should create a proper package instead of the single main.py module.
ruff even complains with the [implicit-namespace-package (INP001) ](https://docs.astral.sh/ruff/rules/implicit-namesp...
Transfer of content from https://archive.docs.dagger.io/0.9/235290/troubleshooting with additional information from https://discord.com/channels/707636530424053791/1213529490525917265
This commit adds notes to the quickstart based on the user feedback in https://discord.com/channels/707636530424053791/1215318377329983519
This is used by the publish.yaml workflow on the main branch.
If this spec does not run, that workflow fails.
Follow-up to:
Summary
Return only error and no value if return type for a function is Void.
Motivation
It makes no sense for the client to capture a Void value as it's specifically meant for side-effects only. It has no meaning as a value. If you have the following function:
func (m* MyModule) Deploy() error {
// do something that may return an error
}
This should produce the following schema:
type MyModule {
deploy: Void
}
But codegen f...
[dagger/dagger] Pull request opened: #6869 docs: Renames categories, updates user/developer sidebars
This commit
- renames the top-level "user guide" and "developer guide" categories to "user manual" and "developer manual"
- updates the URLs, filesystem paths and links to reflect the new naming scheme
- adds redirections for the previous URLs
- renames the second-level developer "guides" category to a new top-level category named "tutorials"
- updates the URLs, filesystem paths and links to reflect the new naming scheme
- adds redirections for the previous URLs
- in futur...
This PR was auto-generated.
This commit makes our examples consistent with the rest of the docs by changing the examples to use the dagger -m $MODUDLE call pattern.
What is the issue?
A user in discord reported a common trap that exists with our current quickstart. #daggernauts message
Question about the Zenith Doc.
https://docs.dagger.io/quickstart/292472/arguments#pass-a-directory-as-argument
In this section we call the tree command from a local dir.
It's gonna sound stupid but I did it in my home dir and I was wondering why it took minutes to run. I quick...
CC https://discord.com/channels/707636530424053791/1215420048865362030
This commit updates the documentation to use functions instead of fields to access sub classes
Fix https://discord.com/channels/707636530424053791/1215420048865362030
Explanation
I was overriding the variable object in loadResult which broke the loop.
Instead, I use a sub variable inside the loop to store the referenced object and everything went back to normal.
This commit adds a new top-level category for the "administrator manual". This is a parallel category to the "user manual" and "developer manual" added in #6869
This commit:
- transfers the CI code samples from the "user manual -> CI" section to a new "admin manual -> integrations" section
- it also adds pages for Tekton and Kubernetes integrations based on the guides at https://archive.docs.dagger.io/0.9/194031/kubernetes, https://archive.docs.dagger.io/0.9/237420/ci-architecture-kub...
Reported by user in [Discord](#1217212533354533036 message).
When the path to Container.withFiles is absolute:
ctr := c.Container().
From("alpine").
WithWorkdir("/work").
WithFiles("/opt/myfiles", files)
The files were being copied incorrectly:
copy /file1 /opt/opt/myfiles/file1
copy /file2 /opt/opt/myfiles/file2
With this PR:
copy /file1 /opt/myfiles/file1
copy /file2 /opt/m...
This is a tiny fix - it updates the example output in the quickstart so that the casing matches what you see in the terminal.
Current Quickstart text
Here's what you should see:
Hello, world!
Updated text
Here's what you should see:
hello, world!
(We have internal issues for this but making a public facing one since it comes up fairly often)
To improve cold start (i.e. empty cache) latency when using modules, we are planning on adding support to cloud cache for a global/read-only tier that comes pre-loaded with base SDK builds and some number of base module builds. Details on which modules specifically is TBD
It would be great if dagger install always worked, no matter the current working directory:
| If... | Then... | Status |
|---|---|---|
| Workdir is inside a dagger module | Install into the current module | Implemented โ |
| Workdir is NOT inside a dagger module | Install into the home directory as if it were a module | Not yet implemented โ |
I propose implementing the second row: when calling dagger install outside a module, use the home directory as a pseudo-module instead....
This PR adds uv support, using it by default to install python packages.
The need for speed
The main motivation is performance. Some quick numbers:
Without uv:
python -m venvโ โ2.08spip install -r lockโ โ4s (cold)pip install -e sdkโ โ6.30s/3.56s (cold/warm)
With uv:
uv venvโ โ0.03suv pip install -r lockโ โ0.9s...
The Notes update is a suggestion since they are not visible enough IMO.
I'm using the Admonition from Docusaurus.
Let me know if you rather roll back to the original style @vikram-dagger. Thanks ๐
What are you trying to do?
Load docker compose files (just like how dagger can use Dockerfile) and automatically generate map of containers accordingly with docker compose service name as key. Any unsupported setting from docker compose file can be ignored.
Why is this important to you?
I've been using dagger for a while and it's great for running ci/cd pipeline across machines. But i still feel that it hards to replace the simplicity of docker compose when used to run dependencies...
What are you trying to do?
The dagger docs for gitlab / github / etc have each job installing curl followed by installing the dagger CLI to use for a given CI run. It would be much nicer DX, and probably faster to just have an official docker image that can be used that has the CLI already installed?
Why is this important to you?
No response
How are you currently working around this?
No response
Fixes https://github.com/dagger/dagger/issues/6784
This makes whether a .gitignore is created a configurable setting in dagger.json, with the default being true.
For now, this will require hand-editing dagger.json if the setting should be changed to false, but CLI support will come along with the follow ups to https://github.com/dagger/dagger/pull/6857 as a dagger config subcommand.
To prevent the .gitignore from being created, you need to do:
dagger initwith no `--sd...
A runtime module can configure paths for .gitattributes and .gitignore. I also want to add paths for "exclude" in dagger.json, on init/develop --sdk.
What are you trying to do?
I want to be able to publish a Dagger module to an SCM other than GitHub, especially as I work with organisations that use GitLab and self-hosted instances. I like the look of Dagger and can see its benefits. Running CI locally is a game changer, but GitHub isn't always an option.
Why is this important to you?
It provides more freedom regarding where you publish your Dagger modules, greatly increasing Dagger's usability. It also enables other platforms li...
What is the issue?
When inexperienced helm chart and k8s users try to add pod affinity or tolerations to values.yml, whey will simply remove the comments and when they do, the properties are under image instead of engine, where they should be. This will cause the changes to not take effect and they might get stuck asking about it, causing unnecessary work.
To remedy this, the comments just need to be moved over two spaces.
PR coming!
Scott
Dagger version
dagger v0...
What is the issue?
I'm migrating my CI from GH actions to CircleCI in order to use ARM executors. Following is the pipeline for both GH Actions and CircleCI. I'm using the Dagger Python SDK. GH Actions pipeline runs fine, but CircleCI instantly panics when the dagger run command is executed.
Funnily enough, when SSHing into the CircleCI instance and running the same command there, the engine Dagger pipeline works just fine. I could not for the life of me find a related issue, and the ...
What is the issue?
Setting --oci-max-parallelism 2 on the Engine causes deadlocks, both with & without modules.
This is what that looks like from the CLI / user perspective:
https://github.com/dagger/dagger/assets/3342/826ddb73-c36e-469e-9560-f21b3fd13388
Attaching Dagger Engine v0.10.2 logs + SIGQUIT. Thank you @vito for https://vito.github.io/swirly/ and the tips!
- [dagger-engine-010x.sigquit.txt](https://github.com/dagger/dagger/files/14624908/dagger-engine-010x.sigquit...
What is the issue?
If you have a function that accepts *Secret parameters, when you run --help it will print the parameter and an empty default value even when you do not specify that the parameter has a default.
I first noticed this in my Mastodon module which looks like this.
func (m *Mastodon) Toot(
ctx context.Context,
// url of mastodon instance
server string,
// mastodon application client id
clientId string,
// mastodon application client secret
cli...
Today, we can merge directories using Directory.WithDirectory - however, there's no corresponding WithoutDirectory method, like we have on Container.
This is slightly frustrating - imagine the following use case (cc @slumbering):
func (m *MyModule) DoThing(src *Directory) {
// I want to filter src down, and remove a directory:
src = dag.Directory().WithDirectory("/", src, DirectoryWithDirectoryOpts{
Exclude: []string{"node_modules"},
})
// But, ideally I'd just...
Fixes #6897
An empty secret value produced a non-empty ":" string representation:
Flags:
- --access-token Secret mastodon access token (default :)
+ --access-token Secret mastodon access token
In this page
https://docs.dagger.io/developer-guide/typescript/629502/ide-integration
change from
When opening the generated dagger/src/main.py in an IDE to
When opening the generated dagger/src/index.ts in an IDE
It doesn't look like we can specify a version to download in dagger using the instructions here: https://docs.dagger.io/quickstart/729237/cli:
$script = Invoke-WebRequest -UseBasicParsing -Uri https://dl.dagger.io/dagger/install.ps1
$params = "-DaggerVersion 0.9.7"
"$script $params" | Invoke-Expression
If I look at the contents at that script:
> curl https://dl.dagger.io/dagger/install.ps1
# param (
# [Parameter(Mandatory)] $PersonalToken
# )
Clear-Host
@"
...
Noticed this while working on https://github.com/dagger/dagger/pull/6857
Right now if you have two modules in a local repo checkout and there is a dependency between them, if
- Module A does an include of
*.foo - Module B does an exclude of
*.foo
Then the exclude of Module B will override the include from Module A. The direction of the dependency between A and B doesn't matter, the end effect will be the same.
The problem is that module loading currently combines all the includ...
I found that the Glob being used in https://github.com/dagger/dagger/pull/6884 doesnโt work as expected. Also reported by user in [Discord](#1219382409016115200 message).
Assuming the following directory:
files = dag.directory().with_new_file("foo/bar.txt", "foobar")
src = dag.directory().with_direct...
Remove Req graphql client plugin to reduce number of dependencies and uses :httpc that comes with OTP instead.
Instead of start Dagger session when test block start executing, start it only once when test suite start except test that uses Dockerfile since it has failure because of Dockerfile not found error sometimes.
There is a new pull request to replace the stale one.
This adds kapa.ai to the docs. We're evaluating the UX before merging.
Related discord thread: #1220078037542895617 message
By default, exporting a directory resulted in its contents being merged into the target directory on the host, with any files that existed on the host but not in the source dir being untouched during the export.
More often than not, this is the behavior you want, but there are use cases where you'd instead like to replace the contents of the host directory entirely such that i...
What is the issue?
I can't find any information in the most recent documentation on how to persist the cache created by Dagger between pipelines in a CI environment (Github Actions for my use case). This used to be available, such as in version 0.2, but now it seems everything related is pushing me towards Dagger Cloud.
So how can I persist cache in a CI environment?
I think this restriction got added along with restrictions around using it for field/function names, but it was overzealous; can't see any reason why it can't be an arg name.
Related discord thread: #1220153273370280048 message
Some git url formats inline credentials to the URL, in which case dagger ends up printing those creds. If we instead added an arg of type Secret and then internally did the formatting for the user, we could avoid this.
I'm guessing it's possible to do this, it just requires that the user can leave out the creds from the URL in a reasonable way that doesn't result in some amb...
Previously it was possible to start a dependent service in one module API call, and then use it again in a later call, only to have it fail because it cannot resolve the service address, even though it's still running. This happened because each invocation has its own client ID, and client IDs were used to build service addresses.
This change brings service addresses into alignment with the recent change to uniq them by service ID instead of client ID. The overall effect is that services a...
Consider the following Dockerfile:
FROM bash
ARG FOO="vs\n"
RUN cat <> /script
# Cats ($FOO)
# Dogs
echo OK!
EOF
RUN cat -n /script && bash /script
And the following function:
package main
type Dockerfile struct{}
func (m *Dockerfile) Build() *Container {
return dag.Directory().
WithFile("Dockerfile", dag.CurrentModule().Source().File("Dockerfile")).
DockerBuild(DirectoryDockerBuildOpts{
BuildArgs: []BuildArg{
Bui...
This is the last part of the saga around https://github.com/dagger/dagger/issues/6747 that fully isolates sessions to each client and thus enables support for passing host unix sockets to modules, plugging some existing holes in our secret isolation, etc.
This PR doesn't have all that yet, been in the process of rebuilding it cleanly after an initial messy prototype. Sending it out anyways because what I have here seems to fix the problem in https://github.com/dagger/dagger/pull/6914, so m...
wip, need unit tests, just don't want to lose track of this rabbit hole
To no one's surprise, the tricky reflect handling around input objects isn't working properly, resulting in this ID for up --ports 9090:8080:
Service.up(ports: [{frontend: null, backend: 8080, protocol: TCP}])
instead of this:
Service.up(ports: [{frontend: 9090, backend: 8080, protocol: TCP}]):
The actual behavior is correct - the resolver gets 9090, not null - but the serializatio...
What is the issue?
I am trying to write a dagger module that builds a Dockerfile and then returns an intermediate type, which allows the caller to execute subsequent functions like publish or export. However, when I try to implement these functions, I get inconsistent behaviour compared to returning a Dagger built-in type like File and then exporting.
Dagger version
dagger v0.10.2 (registry.dagger.io/engine) darwin/amd64
Steps to reproduce
Here is an example module:
...
What happened? What did you expect to happen?
I really like the look of Dagger and I am about to take the plunge and migrate my existing GitLab workflows. But I admit, I am a little stumped as to what approach I should take. The documentation focuses heavily on Dagger Modules, so I imagine that is the preferred path.
I am in the process of breaking down my existing GitLab pipeline into composable Dagger modules. And this is where the confusion sets in.
Should I:
- Keep the same...
What is the issue?
Hello,
when I initialise a new dagger module and select the go sdk with dagger init --name test --sdk=go --source ., a .gitattributes file is generated but a .gitignore file to exclude the generated code is missing. This seems like unintended behaviour since for e.g. the python sdk, a matching .gitignore file is produced.
Dagger version
dagger v0.10.2 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
- Run `dagger init --name ko --sdk=g...
Hello, I found some typos in the documentation and initially wanted to fix just a few of them. I then ran codespell on the repo and found a bunch more. Please tell me if some files should not be touched.
What is the issue?
Cannot run dagger init on windows
seems it has problem with filepath.IsAbs for windows
Dagger version
dagger v0.10.2 windows/amd64
Steps to reproduce
- install dagger CLI for windows
- run command
dagger init
Log output
Error: failed to get configured module: failed to get local root path: input: moduleSource.resolveContextPathFromCaller resolve: failed to find up root: path is not absolute: C:\projeccts\test
cc @levlaz
If a secret gets passed into a function input, it's useful to be able to determine the original name of the secret.
This is especially significant for the following API:
type Directory {
...
dockerBuild(
...
"""
Secrets to pass to the build.
They will be mounted at /run/secrets/[secret-name].
"""
secrets: [SecretID!] = []
...
): Container!
If we don't know the secret-name, there's no way to get a...
The issue (found at kubecon :tada:):
$ pwd
/tmp/work/fooรฉ/test
$ dagger init --sdk=go --source=.
โ ModuleSource.resolveContextPathFromCaller: String! 0.0s
Error: failed to get configured module: failed to get local root path: input: moduleSource.resolveContextPathFromCaller resolve: failed to find up root: failed to lstat .git: failed to create diff copy client: rpc error: code = Internal desc = rpc error: code = Internal desc = header key "dir-name" contains value with non-prin...
Introduced in https://github.com/dagger/dagger/pull/6860, causing some additional test flake.
This manifested as additional flakiness in the test, causing out to be written to in a racey way:
WARNING: DATA RACE
Write at 0x00c00189a6c0 by goroutine 20341:
github.com/dagger/dagger/core/integration.TestModuleDaggerDevelop.func1.1()
/app/core/integration/module_config_test.go:542 +0x9bd
testing.tRunner()
/usr/local/go/src/testing/testing.go:1595 +0x261
testi...
Imagine the below:
ctr := dag.Container().From("alpine")
ctr.
WithMountedFile("/ctr.tar", ctr.AsTarball()).
WithExec([]string{"ls", "-lh", "/"}).
Sync(ctx)
On the first run, this works as expected:
ctris builtAsTarballtriggers an OCI exportWithExecis run on the result
However, on subsequent runs, this doesn't cache as expected - AsTarball is always executed, which results in ls always being run. I don't observe this change if I com...
Add ' for --dir command to work using branch and subdir
At least using iterm on mac I had to add '' arround the dir flag argument.
The problem is that the autogenerated method for the interface impl tries to call WithGraphQLQuery but that doesn't exist on the type: https://github.com/yann-soubeyrand/daggerverse/blob/0bfceb15f2597da89cb08bd6c8ba5c73baea6df7/test/dagger.gen.go#L598
Due to the current rule that types defined in a module are serialized with their JSON representation rather than their ID, t...
Backfilling for the release tomorrow
After merging https://github.com/dagger/dagger/pull/6615, various provision tests that run on main started failing: https://github.com/dagger/dagger/actions/runs/8433279441/job/23094090218.
We should run our bun tests in CI - to do this we need to install bun dependencies in our GitHub provision test workflows.
Additionally, we restore the old test script to run both the bun and nodejs tests, so that yarn test continues to work.
In https://github.com/dagger/dagger/pull/6905, we changed the HTTP client.
However, we also need to update the HTTP client usage for generate - this ensures that ./hack/make sdk:elixir:generate can now run again.
For example:
This type is wrong - it should instead be:
- pub fn load_container_from_id(&self, id: Container) -> Container {
+ pub fn load_container_from_id(&self, id: ContainerID) -> Container {
The top-level Query.Container has [been deprecated for some time](https://github.com/dagger/dagger/blob/3bc4bd1263570d67ced697d0b453c5d418ceb...
Removes previously deprecated fields - we've had these fields deprecated for several months at this point, so hopefully this should cause minimal impact.
[!WARNING]
Depends on:
This PR was auto-generated.
What is the issue?
Pipeline fails with the above error.
Trace:
goroutine 1 [running]:
github.com/vito/progrock/console.(*textMux).print(0xc000115e60, 0xc0000ba000)
/go/pkg/mod/github.com/vito/progrock@v0.10.2-0.20240221152222-63c8df30db8d/console/printer.go:229 +0x185
github.com/vito/progrock/console.(*Writer).Close(0x410565?)
/go/pkg/mod/github.com/vito/progrock@v0.10.2-0.20240221152222-63c8df30db8d/console/writer.go:87 +0x25
github.com/dagger/dagger/telemetry.LegacyID...
What are you trying to do?
No response
Why is this important to you?
No response
How are you currently working around this?
No response
What are you trying to do?
No response
Why is this important to you?
No response
How are you currently working around this?
No response
Start :ssl application to make it work during download Dagger binary from https site.
Problem
dagger call [ARGS] --help plays a crucial role, and must be kept as lean as possible. At the moment there is clutter that could be removed.
Solution
De-clutter the output of dagger call [ARGS] --help.
- Don't show global flags every time
- Don't show
callflags when a function is selected - Talk about "functions" and "arguments", rather than "function commands" and "flags"
- Other?
Problem
When passing an argument of type Directory, the CLI accepts a git remote url (eg. https://github.com/dagger/dagger) which is awesome; but it does not support passing a sub-directory of that git repo (eg. https://github.com/dagger/dagger/docs) which is not awesome.
Solution
Support passing a sub-directory of a git remote as CLI argument to Dagger CLI.
Problem
Modules are often grouped together in "catalogs" via the Daggerverse Repo pattern. There is no easy way to take advantage of this in the CLI.
For example, this doesn't work:
# Install a daggerverse repo
dagger install github.com/shykes/daggerverse --as=shykes
# Call one sub-module
dagger call -m shykes/supergit --help
# Call another sub-module
dagger call -m shykes/docker --help
The above โ๏ธ will fail because shykes/supergit and shykes/docker are...
Problem
When loading a module from the CLI without specifying a version (for example dagger call -m github.com/shykes/daggerverse/hello, or dagger install github.com/shykes/daggerverse/hello), the default behavior is to load from the last development branch (usually main). Even if there are tagged releases, these will be ignored.
This is incorrect behavior, and will cause unhappy surprises. When there are versioned releases, users expect to use the latest release by default.
...
Problem
There is no way to call core functions from the CLI
Solution
Allow calling core functions from the CLI.
See https://daggerverse.dev/mod/github.com/shykes/core for a userland implementation.
Problem
When dagger call ends on an object (as opposed to a scalar value), it returns an error with a message saying "please query a field of this object".
This is a problem because:
- At a glance, it gives the impression that the user did something wrong, when in fact they did not. So an error is sending the wrong message.
- It makes a valid task (produce an object and look at it) harder than it should be. Just show me the object!
Solution
- Never show an error whe...
Problem
GraphQL supports querying multiple fields from the same object, which is very useful especially for data querying. But the CLI doesn't support this. This drastically limits use cases for dagger call. Basically it makes it impossible to use a Dagger Module as a practical data interface, usable from the CLI.
For an example, see https://daggerverse.dev/mod/github.com/dagger/dagger/linters/markdown
Querying multiple fields can also be applied for easy parallelism: advanced c...
Problem
The user experience for authenticating Dagger CLI to Dagger Cloud, is sub-par. There is a dagger login command, but it doesn't actually do anything.
Solution
Actually implement dagger login, to authenticate the Dagger CLI against Dagger Cloud.
- For an initial implementation, storing credentials in a file in the user's home directory is fine
- As a follow-up improvement, integrate with native OS credentials manager, for example Keychain in Mac OS, etc.
This appears to be a regression introduced in 0.10.2, things work as expected in 0.10.1
From @nipuna-perera on Discord:
Basically run (container A + service).
file = get file from (container A + service)
Try to run (container B + file) fails with:
host alias: lookup t6sjv1ru3serq on 10.87.0.1:53: no such host
โ lookup t6sjv1ru3serq.c1mh4mk35essm.dagger.local on 10.87.0.1:53: no such host
Problem
In some situations, a module may define a type which has a perfectly valid name, but still encounters a naming conflict. The conflict may be with a type defined by a dependency, or with a core type.
The conflict occurs when concat(, ) is equal to either concat(, ), or ``.
For example:
- If a module
Gitdefines a typeRepository, it will conflict with the core typeGitRepository - If a module
Dockerdefines a typeComposeProject, it will conflict with a de...
What is the issue?
The command to init module not working when we are behind coorporate proxy.
dagger develop --sdk=go
It try to access direcly on internet instead to use coorporate proxy (env http_proxy / https_proxy / no_proxy). It seems it ignore standard environment variable to drive proxy ...
Dagger version
dagger 0.10.2
Steps to reproduce
Set proxy with on local computer with:
- HTTP_PROXY
- HTTPS_PROXY
- NO_PROXY
Set the $HOME//.docker/con...
This was added in https://github.com/dagger/dagger/pull/2136
We no longer use github projects to manage tasks, so it doesn't make sense to keep using this action (it just clutters up the issue tasks):
I think this is good to delete now? We're now pretty much exclusively using linear to manage and organize tasks - the github project isn't even acc...
What happened? What did you expect to happen?
How can I get access to the host from a dagger function?
I miss the Host() , Is there any way to to this?
package main
import (
"context"
)
type MyModule struct{}
func (m *MyModule) Test(
ctx context.Context,
) string {
// Host() does not exists
myDir := dag.Host().Directory("/tmp/my-directory")
content, err := myDir.File("my-file").Contents(ctx)
if err != nil {
panic(err)
}
...
What happened? What did you expect to happen?
facing issue when build docker image
my code is like
`// A generated module for TestDagger functions
//
// This module has been generated via dagger init and serves as a reference to
// basic module structure as you get started with Dagger.
//
// Two functions have been pre-created. You can modify, delete, or add to them,
// as needed. They demonstrate usage of arguments and return types using simple
// echo and grep commands. Th...
Problem
When calling a Dagger Function from the CLI, I can pass the path of a local file as an argument of type File, but not the URL of a remote file. This would be very useful.
Solution
Add support for remote URLs when passing arguments of type File from the CLI.
This comment is not useful for the user and pretty confusing in my opinion so I removed it
Start of a few cleanup prs, I am fixing some of the best practices in gen.rs so that we don't ship as many warnings
Remove unneeded return statement
What is the issue?
In the Python SDK, the signatures of Directory.with_new_file and Container.with_new_file are inconsistent. For Directory, contents is a required positional argument, while for Container, contents is a keyword-only argument. This inconsistency is confusing and often requires referencing the API documentation to determine the correct usage. I vote for setting up a PR, if you could give me a hint on the preferred behaviour.
Dagger version
dagger v0.10.2 ...
:WARNING: This PR didn't test it well. The functionality may not work as expected
Add OpenTelemetry to support feature from #6835.
Problem
When initializing an SDK with dagger develop or dagger init --sdk, source files are generated in a subdirectory called ./dagger by default. It seems that most users are either confused by that default, or actively dislike it. I personally always use --source .. I would prefer for . to be the default, and I think most users will agree.
Solution
Change the default for dagger develop --source and dagger init --source to . instead of ./dagger.
Contex...
What is the issue?
I have two modules, ModuleA written in Python using string fields with default values. I depend on this module in my second module written in Golang. It seems that the generated code in dagger.gen.go does not respect the default values of the fields, and requires to set values for these fields again.
Dagger version
dagger v0.10.2 (registry.dagger.io/engine) linux/amd64
Steps to reproduce
I've setup https://github.com/skycaptain/dagger-issue-6964 to illu...
What is the issue?
I am running a service dagger call ... up. The service, which is a Java app, continuously outputs to stdout. However, from the Dagger TUI, I only see a continuous tail of the log. I have no way to get to the part of the log that has "scrolled off" the screen.
This also affects the output of any "ENTRYPOINT" script. I have a substantial script that outputs a lot to stdout but I can't get to that log when I run the service or after I terminate it.
Dagger versio...
This commit improves the Go builder example in the quickstart based on the discussion at https://discord.com/channels/707636530424053791/1223010377097547857
Let's try:
$ ./hack/dev
$ with-dev dagger init --sdk=elixir potato
Initialized module potato in potato
$ cd potato
$ with-dev dagger functions
Name Description
container-echo -
grep-dir -
$ with-dev dagger call container-echo --string-arg 'Hello, Dagger' stdout
Hello, Dagger
Nestru is now used only in dagger_codegen but not for the SDK. This patch remove it out of the SDK.
For example, if the type is name def, the codegen will normalize the name into _.
Closes #6940
What are you trying to do?
I would like to have more detailed data available for the File model, including file permissions and ownership.
Why is this important to you?
This would allow to add some structure tests for the containers created by dagger similarly to container-structure-test.
How are you currently working around this?
Depending on image binaries like ls and withExec which may not work in al...
The Python dev module has been broken since the removal of dag.Host. This is a new implementation that fixes it.
Bumps smallrye-graphql.version from 2.7.0 to 2.8.1.
Updates io.smallrye:smallrye-graphql-client-api from 2.7.0 to 2.8.1
Updates io.smallrye:smallrye-graphql-client-implementation-vertx from 2.7.0 to 2.8.1
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You...
Bumps com.spotify.fmt:fmt-maven-plugin from 2.22.1 to 2.23.
Release notes
Sourced from com.spotify.fmt:fmt-maven-plugin's releases.
2.23
What's Changed
Update foss-root to 17 by @โcaesar-ralf in spotify/fmt-maven-plugin#187
Bump google format & other dependencies by @โcaesar-ralf in spotify/fmt-maven-plugin#188
Full Changelog: https://github.com/spotify/fmt-maven-plugin/compare/2.22.1...2.23
Commits
a89d6df [maven-release-plugin] prep...
Bumps github.com/Khan/genqlient from 0.6.0 to 0.7.0.
Release notes
Sourced from github.com/Khan/genqlient's releases.
v0.7.0
In addition to several new features and bugfixes, along with this release comes reorganized documentation for genqlient. Note that genqlient now requires Go 1.20 or higher, and is tested through Go 1.22.
What's Changed
Add "generic" option to the "optional" configuration for handling nullable types by @โDylanRJ...
Bumps golang.org/x/sys from 0.17.0 to 0.18.0.
Commits
360f961 unix: add API for fsconfig system call
7ff74af unix: drop go version tags for unsupported versions
6b4eab5 unix: suppress ENOMEM errors from sysctl's implementing Uname(uname *Utsname)...
2f2cc5d unix: update IFLA and NETKIT constants with Linux kernel 6.7
See full diff in compare view
[
config.md: allow empty mappings for [r]idmap (#1224)
features-linux: Expose idmap information (#1219)
mount: Allow relative mount destinations on Linux (#1225)
features: add potentiallyUnsafeConfigAnnotations (#1205)
co...
Bumps github.com/go-git/go-git/v5 from 5.11.0 to 5.12.0.
Release notes
Sourced from github.com/go-git/go-git/v5's releases.
v5.12.0
What's Changed
git: Worktree.AddWithOptions: add skipStatus option when providing a specific path by @โmoranCohen26 in go-git/go-git#994
git: Signer: fix usage of crypto.Signer interface by @โwlynch in go-git/go-git#1029
git: Remote, fetch, adds the prune option. by @โjuliens in go-git/go-git#366
git: Add crypto.Signer optio...
Bumps github.com/moby/buildkit from 0.13.0-beta3 to 0.13.0.
Release notes
Sourced from github.com/moby/buildkit's releases.
v0.13.0
buildkit 0.13.0
Welcome to the 0.13.0 release of buildkit!
Please try out the release binaries and report any issues at
https://github.com/moby/buildkit/issues.
Contributors
Tรตnis Tiigi
CrazyMax
Justin Chadwell
Sebastiaan van Stijn
Akihiro Suda
Jonathan A. Sternberg
Kohei Tokunaga
David Karlsson
Leandro Santiago
Gabriel Adri...
Bumps golang.org/x/tools from 0.17.0 to 0.19.0.
Commits
7656c4c go.mod: update golang.org/x dependencies
5bf7d00 cmd/callgraph: add 'posn' template helper
283fce2 x/tools: drop go1.18 support
7f348c7 internal/versions: updates the meaning of FileVersions.
38b0e9b x/tools: add explicit Unalias operations
a6c03c8 x/tools: update telemetry import (new Start API)
1f7dbdf gopls/internal/cache: add debug assertions for bug report
4d4e802 gopls/doc: address addit...
Bumps typescript from 5.3.3 to 5.4.3.
Release notes
Sourced from typescript's releases.
TypeScript 5.4.3
For release notes, check out the release announcement.
For the complete list of fixed issues, check out the
fixed issues query for Typescript 5.4.0 (Beta).
fixed issues query for Typescript 5.4.1 (RC).
fixed issues query for Typescript 5.4.2 (Stable).
fixed issues query for Typescript 5.4.3 (Stable).
Downloads are available on:
NuGet package
...
Bumps node-color-log from 11.0.0 to 12.0.0.
Commits
64a00be 12.0.0
7ced8b1 use stderr for default logger output
e7be68b fix test
93badd2 setup tests for different platforms
ef8703f update CI
6642c2a 11.0.2
d01d106 Compatibility to cf workers
213b7d4 bump vesrsion
9bc2e04 Add import statement for Stream in index.d.ts
b442a1b update files
Additional commits viewable in compare view
[: bump mypy from 1.8.0 to 1.9.0 in /sdk/python
Bumps mypy from 1.8.0 to 1.9.0.
Changelog
Sourced from mypy's changelog.
Mypy Release Notes
Mypy 1.9
Weโve just uploaded mypy 1.9 to the Python Package Index (PyPI). Mypy is a static type checker for Python. This release includes new features, performance improvements and bug fixes. You can install it as follows:
python3 -m pip install -U mypy
You can read the full documentation for this release on Read the Docs.
Breaking Changes
Because the version of typ...
[dagger/dagger] Issue opened: #6989 ๐ DOCKER_HOST is not respected when DAGGER_CLOUD_TOKEN is set
What is the issue?
I am running docker on a remote VM and connecting to it using the DOCKER_HOST env var. I can run docker commands without any issues on the remote host and when I try to call a dagger function I see the dagger engine image getting pulled on the remote host. However, when I try to execute a dagger function, I get an error telling me that the docker daemon is not running.
If I unset DAGGER_CLOUD_TOKEN then everything works as expected and the dagger function is ex...
What are you trying to do?
I want to be able to make changes to code locally and see them reflected in my running Dagger services similar to how docker-compose and docker run --v works.
Discussion about this can be found here: #1224583500569514024 message
Why is this important to you?
The introduction of *Service has made it really easy to get a one liner dev environment up and running on my local laptop using the d...
Some big dependency updates for go.mod - we should aim to merge this after v0.11, to allow some time to soak in main.
Some significant updates:
- Buildkit: https://github.com/moby/buildkit/compare/1981eb123dc979fc71d097adeb5bbb84110aa9f4...cbb116dcc38acb40408743697b575f0ff2a7df6a
- This is kind of large, and we should have avoided it getting this bad again.
- Containerd: https://github.com/containerd/containerd/compare/v1.7.12...0dcf21c1528a
This PR replaces:
Fixes:
- https://github.com/dagger/dagger/issues/6913
- https://github.com/dagger/dagger/issues/5930
- https://github.com/dagger/dagger/issues/4243
This PR adds withAuthToken and withAuthHeader methods to GitRepository so that we can use credentials to clone git repos. Most of the code for doing this is pretty simple :smile: The tests were a bit of a pain (since apparently, as it turns out, we weren't able to clone using dumb http).
Fixes https://github.com/dagger/dagger/issues/3670
This allows for grabbing the default branch, according to point 1 in https://github.com/dagger/dagger/issues/3670#issuecomment-2022321233.
Potentially, we could rework the git API a bit more in the future, but that feels out-of-scope for this issue right now.
What is the issue?
I am trying to start Dagger Engine on RHEL but it fails to start due to a CNI setup error.
Dagger version
dagger v0.10.3 (registry.dagger.io/engine) linux/amd64
Steps to reproduce
sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum install docker-ce
sudo systemctl start docker
sudo usermod -aG docker $USER
curl -L https://dl.dagger.io/dagger/install.sh | BIN_DIR=$HOME/....
This adds a section the troubleshooting doc on how to get Dagger Engine to run on RHEL. Documents the issue that was fixed here: https://github.com/dagger/dagger/issues/6995
What is the issue?
Thanks for the great work on Dagger! I noticed that the link for building Dockerfiles under the Python section on https://dagger.io/blog/dockerfiles-with-dagger results in a 404. The 404 link is: https://dagger-io.readthedocs.io/en/latest/api.html#dagger.api.gen.Directory.docker_build .
Make beartype v0.18.0 happy. This version added type checking for default values and we still had a couple no-noes after:
These are actually fine in practice, but better to have correct types:
[]shouldnโt be used as a default value because itโs mutable, but in our generated client, itโs never mutated.- Enums have...
What are you trying to do?
I wan't to make the exported tar for ctr i import, but now I could't added any custom annotation into index.json,
which is important for https://github.com/containerd/containerd/blob/main/core/images/annotations.go#L22`
Why is this important to you?
exported ocr tar can ctr i import directly without manual tag
How are you currently working around this?
No response
Should fix the currently failing provision tests on main: https://github.com/dagger/dagger/actions/runs/8536672759/job/23386879376
The new traceExec function introduced in #6835 was discarding all stdout/stderr - we need to capture this so that we can detect the case of multiple engines being spun up in parallel with each other.
Quite a few of these log statements take up a huge proportion of the total lines and are mostly useless. Some of them used to be at trace level but got changed to debug at some point, changing them back to trace.
Will see what the improvement is in the log output and go from there, may update with more log changes if I find any more noisy+unhelpful lines.
Fixes https://github.com/dagger/dagger/issues/6923 :tada:
[!WARNING]
Depends on https://github.com/tonistiigi/fsutil/pull/196
Still needs some tidy-ups, but I managed to actually get this working on windows again!
Love filepaths. So fun.
What this is
Adds documentation for the new Traces feature in Dagger Cloud.
- Adds Traces to the Get Started page as a peer to Runs
- Clarifies that Traces is used for engines in the next release and Runs for previous engine versions
- Adds Traces UI description to the User Interface section
Updates are under this path: https://docs.dagger.io/manuals/user/cloud
follow-up to #6835
- fix extra
--helpoutput caused by two-pass flag parsing - fix engine inheriting
DAGGER_CLOUD_TOKENand sending redundant data to Cloud - send engine logs to Cloud over OTLP
Should fix https://github.com/dagger/dagger/issues/6989 But need to add a test since even trying to repro manually is challenging (need to setup a remote dockerd that doesn't listen on /var/run/docker.sock).
Problem
When dagger call returns an error, the contents of the error is printed twice to the screen:
- A first time within the call trace
- A second time at the end of the output
When the call trace is large, or the error message is long, or both, this makes the output very hard to read. The user will often get lost trying to isolate a useful snippet of text to read.
Solution
Only print the error message once, outside the call trace.
| | Before | After |
| Show err...
What is the issue?
If a version is provided to the install script containing a v prefix, it will fail:
โฏ curl -L https://dl.dagger.io/dagger/install.sh | DAGGER_VERSION=v0.10.3 sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 8674 100 8674 0 0 116k 0 --:--:-- --:--:-- --:--:-- 128k
sh debug downloading files into /var/folders/sb/61521rmd5nb...
This fixes the currently failing typescript tests on main: https://github.com/dagger/dagger/actions/runs/8549788696/job/23425690833
This was the intention - but with the node/bun split, we were running all the tests for node, and only one of the tests for bun:
$ yarn run test:node && yarn run test:bun -g 'Automatic Provisioned CLI Binary'
The other tests aren't designed to run in this environment, so should be skipped.
Can be useful for debugging.
This allows old clients like dagger v0.10.3 to still connect to and use dagger engine v0.11.0. While this isn't a strict requirement, it's nice to not break this if we don't have to, and based on a couple tests, it seems like this was the only blocker for that.
The other option for this was to introduce an explicit failure for when clients mismatch, but... this is potentially a bit more destructive, this change is pretty minimal.
This commit adds an example of integrating with GitLab Runners using the Kubernetes executor.
This PR was auto-generated.
What is the issue?
With the latest version, the generated .gitignore file is missing an entry for /internal/telemetry (unless itโs intended?). Is https://github.com/dagger/dagger/blob/fa782c5f25e178e20d58cb7e9610f89bcd38e8ba/core/schema/sdk.go#L331 the right place to fix this?
Dagger version
dagger v0.11.0 (registry.dagger.io/engine) linux/amd64
Steps to reproduce
Execute dagger develop in a Go module and see that Git has new untracked files.
Log output
No response
During our test runs, we should enable the debug scheduler (see https://github.com/dagger/dagger/pull/6991#issuecomment-2032750326), so that we have a better chance of catching the nastiness around:
- #6111
- #6234
This commit ports the Spring guide at https://archive.docs.dagger.io/0.9/882813/build-test-publish-java-spring to use Dagger Functions.
There is a way to configure the size of the local buildkit cache, but it's not in the docs.
Related discord thread: https://discord.com/channels/707636530424053791/1225451746868985967
It's unknown if ZFS is actually a culprit somehow, but this hasn't been repro'd on other Debian versions with other filesystems yet, so it stands out as an outlier right now.
Error:
dagger init --sdk=python test2
โ ModuleSource.asModule: Module! 0.9s
! failed to create module: select: failed to update codegen and runtime: failed to generate code: failed to call sdk module codegen: select:...
I currently run a GHA workflow that, at the end, invokes another workflow. Is this supported in dagger? What if the second workflow runs on a different type of GH runner pool?
Bumps golang.org/x/tools from 0.19.0 to 0.20.0.
Commits
11c692e gopls/internal/test/marker/testdata: skip hover size tests on 32-bit arm
fc660e5 go.mod: update golang.org/x dependencies
6590f47 internal/gcimporter: renable tests of issue50259.go
f1d5252 gopls/internal/golang: Hover: show wasted % of struct space
951bb40 gopls/internal/test/integration/misc: fix flaky test
c9b0c65 gopls/internal/analysis/fillreturns: skip test if gotypesalias=1
c623a28 gopl...
This commit adds a new page to the Integrations category demonstrating how to create Dagger Functions to test and publish a generic PHP application. It is based on the archived guide at https://archive.docs.dagger.io/0.9/128409/build-test-publish-php/
Allows the user to set the priorityClassName in the Helm Chart to avoid eviction and ensure that the Dagger engine is always present on the node.
Before this, there was no way to get the version of an engine - this is really useful if the engine is running remotely, and you want to make a query for it to get it programatically (it's always been possible by analyzing logs, etc).
One of my main use cases is for working out what version of dagger the playground is using: https://play.dagger.cloud/playground - there's actually no way to do that right now (this PR would let you).
What feels frustrating is that `checkVersionCompatibi...
What is the issue?
If you type any dagger command in a git worktree, you'll get the following Warning message:
WRN failed to get repo HEAD err="reference not found"
The error could potentially come from here:
https://github.com/dagger/dagger/blob/95b4ce550a2dcd1fa73f8b55199c7e9ed0ef1fc3/telemetry/labels.go#L109-L113
Dagger version
dagger v0.11.0 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
1 - Clone a repository with the flag --bare:
`git clone --bare...
See the rationale in https://github.com/dagger/dagger/pull/7013, https://github.com/dagger/dagger/pull/7001#discussion_r1549487821. TL;DR, during the release of v0.11.0, we broke compatibility with older clients, but didn't really have the tooling to make sure that this errored cleanly out.
This PR ensures that this doesn't happen again - both the client and the server are able to specify a minimum version, defined in engine/version.go. If a client/server doesn't satisfy these constrai...
Take the following go module:
package main
import (
"context"
"strings"
)
type Playground struct{}
func (m *Playground) Foo(ctx context.Context, progress string) (string, error) {
return strings.ToUpper(progress), nil
}
On call:
$ dagger-dev call foo --progress=plain
Connected to engine ff7f91f8a66b (version 4b825dc642cb6eb9a060e54bf8d69288fbee4904)
โ connect 0.2s
โ initialize 3.5s
! flag already exists: progress
โ ModuleSource.resolveFromCall...
Python Modules now (since v0.11.0) create a requirements.lock file by default, but does this only on dagger init (or develop if thereโs no pyproject.toml), so itโs up to the user to update manually from then on:
uv compile --generate-hashes -o requirements.lock sdk/pyproject pyproject
This can create a catch 22 situation where the SDKโs dependencies have changed, you need to codegen to get th...
Itโs surprising that you can create a module, make some functions, run them, remove main.go and itโll still run, just with the default ones from the template.
Instead of stopping dagger call from doing codegen automatically, I think it would be more reasonable to just not use the template unless youโre using --sdk for a new module. So if you remove main.go or some other file, it errors rather than re-creating on an ephemeral container, which is more surprising.
The client will s...
What is the issue?
Fail to set InstallPath on Windows with PowerShell v7.4.1
Dagger version
dagger v0.11.0
Steps to reproduce
$script = Invoke-WebRequest -UseBasicParsing -Uri https://dl.dagger.io/dagger/install.ps1
$params = "-InstallPath A:\dagger"
"$script $params" | Invoke-Expression
Log output
-InstallPath:
Line |
78 | -InstallPath A:\dagger
| ~~~~~~~~~~~~
| The term '-InstallPath' is not recognized as a name of a cmdlet, functi...
This PR adds a new serializer for graphql input. The previous serializer (serde_json) was just a regular json parser, however, as graphql input functions aren't strictly json (missing quotes on keyes, and enums) it turned out to not be a great fit, and couldn't implement a lot of the functionality we wanted.
As such this pr introduces a purpose built serializer which can handle this.
This should also fix: #5928
What is the issue?
When an error occurs. I.e. a .sync().await? fails we get a bloated error response back from the dagger engine, which contains details the client shouldn't need to see.
Such as
[78.0s] error[E0635]: unknown feature `stdsimd`
62: [78.0s] --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/ahash-0.7.7/src/lib.rs:33:42
62: [78.0s] |
62: [78.0s] 33 | #![cfg_attr(feature = "stdsimd", feature(stdsimd))]
62: [78.0s] | ...
This feature should allow both id and regular structs/objects/scalars to be passed in to a function. This was initially brought on by: #6933.
Which now allows removing deprecated input
Use regular expression instead of dictionary of words to enable any module that use acronym word to generate correct name in Elixir.
Updates #6310
[dagger] New discussion #7040: Any recommendation to avoid "Too many requests" limit with Python SDK
We're currently considering using Dagger for production. As our main language is Python, we want to write our Dagger modules in Python. At the moment, we're using the default Python SDK that Dagger provides. This SDK fetches python:3.11-slim from Docker Hub.
However, we've recently encountered the "Too Many Requests" limit on Docker Hub while trying to scale for production. We usually bypass this issue by proxying external images through our Artifactory server. The problem is, the image ...
What is the issue?
I have a module called cloud-utils
When I try to search for it in Daggerverse it does not show up in the results. I suspect its due to the dash in the name.
https://daggerverse.dev/search?q=cloud-utils
Dagger version
n/a
Steps to reproduce
No response
Log output
No response
What is the issue?
Installed dagger using "brew install dagger" on macos M1 arm64 chip.
It says "dagger install github.com/kpenfound/dagger-modules/golang@57352e06a1cfbcb5307c009d37c0201b2719b935". Then I get:
Error: failed to get configured module: no dagger.json found in directory . or any parents up to git root
Dagger version
dagger v0.11.0 (regist...
I just realized that I answered my question more or less already in #6318: We could just fork the python-sdk and make passing the base image configurable via dagger.json.
What is the issue?
The startup time for Dagger Functions takes a long time, even on subsequent runs. It seems to be the step where the function is prepared, compiled, dependencies fetched. Watching the logs, once the function code is reached, it goes very quickly
Dagger version
0.11.0
Steps to reproduce
cd tmp
โ tmp git:(main) โ
dagger init --sdk=go repro-go
12:01:19 WRN no LICENSE file found; generating one for you, feel free to change or remove license=Apache-2....
What happened? What did you expect to happen?
I initialized my dagger module with dagger init --name=simple-frontend --sdk=go. Now i modified the available Functions and removed the default generated ones. Now the dagger.gen.go contains errors, because of referencing the default functions initially generated with dagger init (ContainerEchoand GrepDir). What is the intended usage of the dagger.gen.go file. I didn't found a documented way to regenerate the file?
What is the issue?
I installed dagger.exe and ran dagger.exe and got no output.
Dagger version
no ouput, but dagger v0.11.0 amd64 Windows
Steps to reproduce
Go to user's home directory.
run
Invoke-WebRequest -UseBasicParsing -Uri https://dl.dagger.io/dagger/install.ps1 | Invoke-Expression
execute
./dagger/dagger.exe
Log output
Fixes failing jobs on main after merge of #6843 https://github.com/dagger/dagger/actions/runs/8598160866/job/23558410143.
What is the issue?
logs
Dagger version
dagger v0.11.0
Steps to reproduce
No response
Log output
No response
Thereโs an easier solution in v0.11, via pyproject.toml:
[tool.dagger]
base-image = "โฆ"
The engine supports a mirrors setting. Have you tried that? Or doesnโt your Artifactory server work as a mirror?
That's awesome; I will definitely give it a try. Meanwhile I also experimented with registry mirrors in engine.toml, which is fine for our CI, but not for local development as developers would forget to run a custom engine container with the patched engine.toml
Yes, I have and it's working great. However, I think we can only use this for CI, but not for local development as developers would forget to run a custom engine container with the patched engine.toml.
To reproduce on main:
$ dagger call --source=. sdk go generate entries
sdk
(hangs here, even though the task is complete)
Dumping trace logs on the engine:
time="2024-04-08T11:58:34Z" level=trace msg="server removed" client_call_digest= client_hostname=daggerdoer client_id=jui8v1z5en9a42r1l9sncx1zp server_id=cl0so4twc5tpx6ggse1v4rpxa
time="2024-04-08T11:58:34Z" level=debug msg="session call done" client_call_digest= client_hostname=daggerdoer client_id=jui8v1z5en9...
Not 100% certain why this was enabled in the first place - but it was, and it's not needed, we only need to be able to run as root here I think.
This avoids the issue encountered in https://github.com/dagger/dagger/issues/7048, and we don't really need it anyways.
Start to fix https://github.com/dagger/dagger/issues/6901.
This script was removed in https://github.com/dagger/dagger/commit/5a9c772020363668c18e73472534f01a5b03b8d5, and we still have windows install instructions, so we should probably restore this!
I've also updated the script with a few additions, like making the function names map to the same as the unix script.
Follow-up to #6843.
Fixes:
- Broken Go SDK publish on
main: https://github.com/dagger/dagger/actions/runs/8602295935/job/23571547672- Due to an incorrect refactoring, we need to restore some of the original functionality
- Broken image publish on
main: https://github.com/dagger/dagger/actions/runs/8602589466/job/23572487550- Due to completely inconsistent handling of version data
- Instead of just applying a simple fix in the shim, we need to rework how versioning works entir...
Spotted this failure just now: https://github.com/dagger/dagger/pull/6959/checks?check_run_id=23515980223
No aliases :cry:
/cc @benjaminstrasser
It'll pick the right thing all on its own; no need to manually set it. This way we can still have the nice TUI in ./hack/dev
What are you trying to do?
When I start a dagger call with the --debug flag, it would be helpful to not automatically clean up the terminal but rather leave the full logs visible.
Why is this important to you?
Even with --debug enabled I did not find a simple way to observe a dagger call invocation in the terminal with greater detail.
How are you currently working around this?
Trying to spot lines before they are deleted or clicking through all command invocations in the da...
What is the issue?
While developing locally, I often use --progress=plain for long-running tasks. This allows me to better understand what's happening and to detect early warnings. With prior releases, this worked well, as the logs were streamed to my console and I could follow along with the build. However, it appears that there's a regression with v0.11.0. Now, when I run any dagger --progress=plain call ... command, I only see Connected to engine 14def8fb732a (version v0.11.0) for an ...
env: prefix is only supported for secrets.
Agh, more: https://github.com/dagger/dagger/actions/runs/8613689129/job/23605520739
I was using GO SDK, connected to Dagger engine. In one session, firstly run a shell command in container A, and then run a shell command in container B.
The pull images operations were cached for small images like alpine, busybox etc.., but not cached for some big images. Anything I can do the cache image pull operations, since it's time consumed.
Here's my environment
SDK: Dagger GO SDK
OS: mac OS
Docker: Docker Desktop 4.20.0 (Engine 24.0.2)
What are you trying to do?
Need to know engine version that a module was built with so can know if a module is compatible with my engine version.
Want to filter for modules by engine version.
Why is this important to you?
Modules created with an engine version different from the one I'm running might not behave properly.
How are you currently working around this?
You can look at the dagger.json in a module's git repo.
Also, don't bother adding a shim for this one - it's not worth it, we can directly use dagger-for-github.
Again, testing this is a pain.
Follow up to:
- #6884
To simplify not needing to install the SDK's dependencies for codegen, the Python codegen script has been moved into an independent package with a minimal dependency.
Added a codegen introspect subcommand avoid the need for the Python codegen to have HTTP capabilities in order to introspect from the API directly.
This helped simplifiy the runtime module. Now, if a module has a requirements.lock file, it'll be re-compiled automatically (without upgrading pac...
Right now you can only set the module's name at dagger init either with --name or by default the name of the containing directory will be used.
I found this odd and expected to be able to do this:
dagger init
dagger develop --sdk=go --name=foobar --source=.
Side note: since
dagger initassumes.I'd wantdagger developto assumesource=.also.
https://github.com/dagger/dagger/issues/6963
Instead, I got this error with the above:
dogfish โค dagger init...
Still some cleanup left, but good enough for feedback. TODOs:
- [ ] finish description
- [ ] dedupe some of the distro ca installation code
- [ ] make ca installation/uninstallation non-fatal and cleaned up in case of failure partial way through
- [ ] make final call on whether to only selectively enable or just apply to all containers when custom CAs are installed in the engine (at
/usr/local/share/ca-certificates)
This adds support for automatic installation of custom CA cer...
This data allows the UI to track where lazy operations came from so we can tie them back to the call site that installed them (i.e. withExec). This visualization angle is super useful when you're trying to gauge the "cost" of
Something like this (note the "shadow bars" - UI subject to change):
NOTE: As a prerequisite, I moved the ftp_proxy hackery back to Container.WithExec instead ...
Add s390x and ppc64le support
ignore the release that not exist
See https://github.com/dagger/dagger/pull/6843#discussion_r1552464269
This ensures that we use the host creds in the test container, so we don't end up maxing out our anonymous usage of docker hub.
We may be able to get rid of this once #6916 lands? But in the meantime, we're seeing a ton of ephemeral failures which are quite annoying :tada:
Came across this while working on continued modularization - ideally, we want to end up in a place where all of our CI is just a dagger call away! Then we can use https://github.com/dagger/dagger-for-github, and dogfood that more.
This step is more fiddly to modularize (which we want to do so it would show up in dagger cloud) - I think it can be done, but I think we might also just be able to remove it. It was added quite a while ago in https://github.com/dagger/dagger/pull/3785, to he...
:warning: The traces are not sent to dagger cloud, I need to investigate to understand why
This allows any nested client to use this, including the SDK tests, not just the engine tests.
What is the issue?
Bash completion is failing since version v0.11.0 with the following error: Completion ended with directive ShellCompDirectiveNofileComp
More details in this discord thread https://discordapp.com/channels/707636530424053791/1227602359547592745
Dagger version
dagger v0.11.0 (registry.dagger.io/engine) linux/amd64
Steps to reproduce
Install version v0.11.0
try to complete in a bash shell a dagger command.
Log output
No response
What is the issue?
Hey there,
After upgrading to v0.11, I noticed that when using --progress plain, the stderr is outputted only at the end of the run. Why is this important? When running in CI, there will be no feedback given to the user (unless the go code explicitly writes to stdout/err) until the end of the run. This may take minutes.
Expected: the dagger/container/services stderr is streamed as it generated like in <= 0.10
Actual Behaviour: the dagger/container/services ...
What is the issue?
With dagger v0.11.0, when running dagger develop and the module is in a folder called .dagger the package main/internal/telemetry is not added to the dagger.gen.go fille. The imports are as follows.
import (
"context"
"encoding/json"
"fmt"
"log/slog"
"os"
"main/internal/dagger"
"go.opentelemetry.io/otel"
"go.opentelemetry.io/otel/attribute"
"go.opentelemetry.io/otel/sdk/resource"
semconv "go.opentelemetry.io/otel/semconv/v1.4.0"
...
In https://github.com/dagger/dagger/pull/6835, we finally removed _EXPERIMENTAL_DAGGER_CLOUD_TOKEN, and replaced it with DAGGER_CLOUD_TOKEN.
However, we were exploiting an undocumented use of this - we could use DAGGER_CLOUD_TOKEN to enable cloud cache + telemetry, while we could use _EXPERIMENTAL_DAGGER_CLOUD_TOKEN to just enable telemetry for security reasons. We want all PRs to use telemetry (so we can get traces), but we don't want all PRs to use caching - since that could intr...
The previous image was just a manifest explicitly only for amd64:
$ docker buildx imagetools inspect node:21.3-alpine@sha256:cacb4e3a208aa34e0f821b56256e446ad984960d4f9aca66c7026e16b87db89f
Name: docker.io/library/node:21.3-alpine@sha256:cacb4e3a208aa34e0f821b56256e446ad984960d4f9aca66c7026e16b87db89f
MediaType: application/vnd.docker.distribution.manifest.v2+json
Digest: sha256:cacb4e3a208aa34e0f821b56256e446ad984960d4f9aca66c7026e16b87db89f
$ docker buildx imagetools i...
- Bun cache volume should include the version number
- tsx installation should be part of the base image (so cannot be cache invalidated)
- @TomChv I think there's some more low-hanging fruit here - the pipeline here doesn't seem to cache in the expected way, we should ensure that wherever possible we can install the dependencies with as few cachebusters around as possible
Split out from https://github.com/dagger/dagger/pull/7018 to avoid blocking the release.
cc @matipan @gerhard
Just a simple suggestion to change docs.
What is the issue?
As a follow-up of this discord thread: https://discord.com/channels/707636530424053791/1227300888050139146 and this previous issue: https://github.com/dagger/dagger/issues/6462, seems like dagger call is randomly uploading the context in consecutive calls.
We confirmed this happens in all v0.10.{2,3} and v0.11.0 versions.
Dagger version
v0.11.0
Steps to reproduce
As described in: #1227300888050139146 message...
At the moment our CI costs have gotten quite high. As a way of optimizing (although we are unsure of how much this will help us) we want to reduce the amount of parallel jobs running. The current setup is allowing all jobs of all commits in a PR to complete, even when new commits have been pushed. While this can certainly be useful, it is way too costly. Each time we run jobs for a pull request in our legacy CI we are requesting approximately 64 cores and 384 Gi of memory. This is definitely ...
What is the issue?
Running dagger develop --sdk=go fails if under a go.mod with go 1.22 (but works with go 1.22.1)
Dagger version
dagger v0.11.0 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
$ mkdir temp
$ cd temp
$ cat > go.mod << EOF
module example.com/temp
go 1.22
EOF
$ dagger init
$ dagger develop --sdk=go
Log output
โ ModuleSource.as...
[dagger/dagger] Pull request opened: #7088 docs: initial github container registry integration guide
An initial guide to how to push to ghcr: integrating GitHub Actions, Dagger, and GitHub Container Registry.
What is the issue?
As of v0.11.0, running dagger version returns a warning when used in a git worktree. I do all my development in git worktrees and this is annoying. This did not happen before:
BEFORE:
โฏ dagger version
dagger v0.10.3 (registry.dagger.io/engine) darwin/amd64
AFTER:
โฏ dagger version
dagger v0.11.0 (registry.dagger.io/engine) darwin/amd64
20:23:06 WRN failed to get repo HEAD err="refe...
I also think having .NET SDK support would be great!
What happened? What did you expect to happen?
๐ Have been playing with dagger by building my own module for running Terraform and other scripts. Am running into a weird issue where previous deploy / destroy runs have been cached to the point where Dagger just shows the previous successful run rather than deploying infrastructure again even though it no longer exists. In essence making multiple runs quite tricky. While searching for a solution I found this in the archive as a workaround t...
What is the issue?
When you use a function name that contains a protocol name like TCP, UDP, IP, HTTP, HTTPS, many users would assume they should use PascalCase for their public function names, for example, TcpTest or HttpsTest, but when those function names are run through codegen in the Go SDK at least, certain substrings containing protocol names are upcased. So the functions above become TCPTest and HTTPSTest.
On the other hand, a function name like FooTest results in `F...
Replace the unofficial node module by the one created by Dagger which impact severals code snippets and flows of execution.
This PR updates the code snippets and documentation related to this.
/cc @vikram-dagger I updated the TS snippets, I let you do the Go and Python ๐
This issue aims to regroup all my tests and dig into the SDK performances improvement.
Init
- Env: compiled a binary from main: (bdce95d0abfa9014a35f5e3962a64afce03d5fca)
- Use dagger cli
v0.11.0 - Use latest dagger cloud
time dagger init --name=perf --sdk=typescript
Initialized module perf in .
dagger init --name=perf --sdk=typescript 0.98s user 0.73s system 11% cpu 14.829 total
โ perfs git:(main) โ time dagger function...
Fixes #7045 (nightmare issue yay)
Essentially, with the new TUI, we were failing to set the TUI to raw mode. The reason for this was that we were passing a non-input buffer to containerd/console (through os.Stdin). Unlike on *nix, on windows, the raw mode we were trying to set is not interchangeable between stdin/stdout.
Something is insanely weird about what bubbletea is doing here - it's making loads of funky assumptions about how terminals can be constructed, and honestly I'm not...
Following https://github.com/dagger/dagger/issues/7093, I found that most of the time is spent downloading dependencies, it seems I can drastically reduce the download time using yarn and the --production flag to only install production dependencies.
This is a first step toward improving TS performances, we might switch to pnpm later, this require some tests though because I'm hitting an issue (see https://github.com/dagger/dagger/issues/7093#issuecomment-2057038646)
As suggested in #5697 & coordinated with @kjuulh.
Adds 3 examples of how to use the dagger Rust sdk to sdk/rust/examples.
The 3 examples are:
- Building a simple CLI application
- Building & packaging a Axum based backend
- Building & packagang a Leptos based frontend
Fixes https://github.com/dagger/dagger/issues/7030.
Git worktrees use a .git/commondir to ensure that refs and similar are shared. We need to explicitly enable this with go-git.
Technically, this change is only required in the telemetry package to fix the above issue, but we can also just add it everywhere that we call this function.
This PR was not auto-generated. Looks like I accidentally deleted the step that did this as part of engine:publish while doing #6843.
Thankfully, we can add this back in later, and this is non-critical :tada:
Elixir publish --hex-apikey had a typo:
$ dagger call --source=. sdk elixir publish --help
Publish the Elixir SDK
Usage:
dagger call sdk elixir publish [flags]
Flags:
--dry-run
--hex-apikey Secret
--tag string
Global Flags:
-d, --debug show debug logs and full verbosity
--json Present result as JSON
-m, --mod string Path to dagger.json config file for the module or a directory containing that file....
Ugh, again. The elixir path wasn't right here, this would mean we were instead publishing v0.0.0.
What is the issue?
Coming from here: https://discord.com/channels/707636530424053791/1229798907362414673
Looks like our helm chart doesn't really work with the latest version of Dagger and it's pinned to a v0.9.x engine. We should try to keep it updated every time we release a new version.
cc @gerhard @matipan
Dagger version
dagger v0.11.1
Steps to reproduce
Follow the guide here: https://docs.dagger.io/integrations/104820/kubernetes
Try updating the engine image f...
Right now if something goes wrong internal to the shim before all the OpenTelemetry plumbing can be wired up, you just get an exit status 125 with no other output. (The shim currently has to manually send the command's stdout/stderr to OpenTelemetry logging, so there are extra moving parts.)
I added a "break glass to debug telemetry" bit that prints Buildkit logs to stderr, but didn't make it configurable, figuring it would only be useful to me while I bootstrap the OpenTelemetry stack.
...
Fixes #6943 (partially for now, but foundation)
Details of current draft implementation
@helderco we had a sync, but I might have forgotten some parts ahah. Feel free to tell if I'm completely off on some interpretation / implementation:
-
[x] Add line break between error and usage
This has been intentionally added incmd/dagger/functions.go -
[x] Style headings inย BOLD UPPERCASEย to help break sections visually
A new helper function has been added and the corresponding t...
Temporary PR to temporarily test the performance of different runners
This patch updates all the go base images to versions that have go 1.22.
Note! We can't update the version used to build runc, due to an upstream incompatability - however, because the build is separate, we can keep building it using an older version of go.
Also note, we can't yet bump to actually use 1.22 in our code by updating the go.mod. This is because the ci package must continue using 1.21 until the next release (insert elaborate codegen reasons here) - and then the ci pack...
Just a fun little experiment :tada:
What are you trying to do?
When running integration tests, we have noticed that even when a run is fully cached, the service will still be started and instantly shut down without the said integration tests running since the integration container and the services it is bound to are already cached.
ctr (cached) --> service a (cached)
ctr (cached) --> service b (cached)
I am aware this is a known behaviour, but is there a reason why the service containers are started anywa...
What is the issue?
building a Dockerfile with dagger doesn't show any of the outputs the Dockerfile currently performs. This used to be the case before v0.11.x so it's very likely a regression on the new telemetry solution.
Dagger version
v0.11.1
Steps to reproduce
FROM alpine
RUN find /
func (m *Test) Build(ctx context.Context, df *File) (*Container, error) {
return dag.Directory().WithFile("Dockerfile", df).
DockerBuild().Sync(ctx)
}
...
What is the issue?
When running dagger init in an emply directory, it will fail with an error message if the directory does not have a .git directory.
There is another issue that is related but not the same, I'll file another issue for that one and link it back.
I traced it back in the dagger codebase to the buildit module's filesync.go. Based on something I ran into years ago, my suspicion is that the CreateFile needs either a UNC path or double slashes on Windows. I wasn't ab...
What is the issue?
This is a semi followup to #7114 with what looks like a different cause. If one follows the steps in that issue, you'll eventually end up with a git repo that has a dagger.json in it. Running 'dagger init' there will throw a duplicate module error.
Dagger version
dagger v0.11.1 (registry.dagger.io/engine) windows/amd64
Steps to reproduce
mkdir dagger-test
cd .\dagger-test\
dagger init
git init
dagger init
New-Item -Type File -Path dagger.json
dag...
Running a simple script with 0.11.1 results in lots of error messages like this:
Transient error StatusCode.UNAVAILABLE encountered while exporting traces to localhost:4317, retrying in 1s.
Transient error StatusCode.UNAVAILABLE encountered while exporting traces to localhost:4317, retrying in 2s.
Transient error StatusCode.UNAVAILABLE encountered while exporting traces to localhost:4317, retrying in 4s.
Transient ...
Did you run it with dagger run or just executing the script (or with python) directly?
Required after a fresh clone.
Also:
- Bump ci module Engine version to v0.11.1
- Remove
$from ci README code snippets
Fixes #6923 #7114 (second time's the charm hopefully).
Right. Descriptions are split up into commits to make it a bit easier to understand, but TL;DR, there were two main issues:
- Paths weren't being correctly decoded after being encoded on the wire - I should have caught this and didn't (my bad). The correct way to do this is to handle the encoding/decoding as close as possible in the code to sending/receiving, then it doesn't sneak everywhere through the code.
- Windows has differen...
Essentially, by calling readlink on the source, we can get the location without any symlinks. This allows a dev (like me) to create a symlink to these scripts, dump those in a bin folder somewhere on my system and then access them from anywhere.
Pragmas were not being correctly parsed when we had windows line endings - this fix ensures that we correctly handle these.
This was resulting in some very weird to debug issues where optional arguments could be detected as required instead.
Sorry about that @rgilton! It's a bug. I thought dagger run was setting the telemetry env vars but it doesn't. I've actually been working on that this week so it should be fixed by next release.
I'll see if there's an env var you can use to disable it in the meantime.
Sorry about that @rgilton! It's a bug. I thought dagger run was setting the telemetry env vars but it doesn't. I've actually been working on that this week so it should be fixed by next release.
I'll see if there's an env var you can use to disable it in the meantime.
No problem! I'm actually quite relieved it's a bug, and not a misunderstanding on my part!
Sorry about that @rgilton! It's a bug. I thought dagger run was setting the telemetry env vars but it doesn't. I've actually been working on that this week so it should be fixed by next release.
I'll see if there's an env var you can use to disable it in the meantime.
Try disabling with this (before dagger.connection()):
import logging
from opentelemetry import trace
logging.getLogger("opentelemetry").addHandler(logging.NullHandler())
trace.get_tracer_provider().shutdown()
The logger statement is to avoid showing the "Already shotdown, dropping span" message.
dagger query is not the main entrypoint of the dagger CLI anymore. Even though the special template made some sense, it is a code duplication to maintain. With the following changes (titles in bold, etc ...) and the remaining presence of the example on the command's help, it does make sense to remove it and keep a single source of truth
New output
./dagger query --help
Send API queries to a dagger engine.
When no document file is provided, reads query from standard in...
Part of the de-clutter CLI implementation: https://github.com/dagger/dagger/issues/6943#issuecomment-2021310987.
Takes inspiration from the gh CLI to visually break the heading sections. It relies on a helper function directly used on the template.
New style:
Part of the de-clutter CLI implementation: https://github.com/dagger/dagger/issues/6943#issuecomment-2021310987.
When querying dagger call --help and dagger functions --help without being in a module or for an inexistant function, an error is being raised. This commit adds a newline between the two, as it was hard to distinct between them
Example:
./dagger -m . functions toto --help
โ initialize 41.2s
Error: no function 'toto' in object type 'Dagger'
Closes https://github.com/dagger/dagger/issues/7020
Just enabling everywhere (including published images) for now since users are hitting this too and may be helpful to grab these logs from them.
Basically, opposite of https://github.com/dagger/dagger/issues/7020. Adding these in https://github.com/dagger/dagger/pull/7128 but we don't want them forever since they are extra noise once we're done debugging the scheduler issues (https://github.com/dagger/dagger/issues/6234 and https://github.com/dagger/dagger/issues/6111)
I would love to be able to search the Daggerverse from the command-line.
I propose a new command dagger search to do this.
Exact design of the command: TBD :)
Problem
When calling Directory.export() or File.export() from the CLI, the output is confusing: it just prints true without context or explanation.
Example:
$ dagger call \
-m github.com/shykes/core@770692357aeac6bf898f28177614763ae5cc620c \
directory \
export
true
Solution
Change the CLI output to something less confusing. I propose no output, which is the expected convention for a command that completes successfully.
When calling export from the CLI, the argument path is mandatory. This makes sense (you need to tell the engine where to export to), but the CLI should allow the argument to be omitted. When it is omitted, a temporary file (for File.export) or directory (for Directory.export) should be used.
Problem
When running a service container in Dagger, sometimes things go wrong and you want to look at log files. Unfortunately there is no documented way to do this.
Solution
Document how to get log files created by a service, and add it to the administrator guide.
One of the action items discussed in https://github.com/dagger/dagger/pull/7107#issuecomment-2061525961
Reposition flags below commands to find them more easily on big dagger call outputs.
New output
./dagger -m github.com/levlaz/daggerverse/mariadb@v0.2.1 call base --help
Return MariaDB Container
USAGE
dagger call base [flags]
dagger call base [flags] [command]
FUNCTION COMMANDS
as-service Turn the container into a Service.
as-ta...
There should be no actual behavior changes here, this just brings in the changes that were merged to fsutil master that we were previously pulling from my fork (for the windows fixes).
Specifically, see these 3 PRs:
- https://github.com/tonistiigi/fsutil/pull/196 (this is the one we were using a replace directive for)
- https://github.com/tonistiigi/fsutil/pull/197
- https://github.com/tonistiigi/fsutil/pull/195
This seems to work, but I seem to get absolutely no output on the console any more (e.g. no build process info) -- is that expected?
No, that should disable only "opentelemetry" logs. What kind of output do you see without it? Can you share a bit more details on your setup? Do you having logging configured? Are you using the log_output config?
The script I am running is in the gist that I linked to in the original question.
If I run that script with 0.10.3, then I get a bunch of console output, along these lines:
โ Downloading dagger CLI1: connect
โ Creating new Engine session1: starting engine
โ Creating new Engine session1: starting engine [1.40s]
1: starting engine [0.06s]
1: starting session
โ Creating new Engine session1: [2.28s] OK!
1: starting session [0.10s]
1: connect DONE
5: resolve image config for...
I also have this issue with no output in 0.11
Quick tip: you don't need to pass the client around instance anymore, see the Global Client.
I don't know if this is a feature of 0.11.1, or something to do with the logging...
It's from dagger 0.11, not Python specifically. You should see some progress while it's happening and in the end it goes away to leave only the script's own output.
If you run the script through dagger run you have more control. You can...
So, in 0.11, there is no way of getting the "complete" output without running dagger run?
Quick tip: you don't need to pass the client around instance anymore, see the Global Client.
:smiley:
You should see some progress while it's happening and in the end it goes away to leave only the script's own output.
Yea, I saw literally that one line flash up and no other lines!
Ok, if I run it via dagger run in the way you say (didn't know I could do that!) then I do get more output.
It was also useful to be able to run the script without having had to install the dagger binary separately: if it's just in a python script, it's just a pip install dagger-io to get it to work. Whereas if dagger has to be around then there has to be some way of installing that first...
If that is the case could I put in a huge request that that be reverted?
Best create an issue asking for it. There was a similar issue here for dagger run:
The difference is you need it on an SDK's automatic provisioning (it's the SDK downloading and executing the CLI underneath).
Alternative solution to:
Flipped the default on withExec instead. Currently you need to explicitly skip the entrypoint, but with this change, you'll have to explicitly use it instead. Otherwise the entrypoint is still in the Container object, and preserved on publish.
It's a breaking change for anyone relying on the entrypoint in withExec.
What are you trying to do?
Dagger 0.11 made changes to the console output which I believe to be a large downgrade.
What I used to do:
I would run my pipeline without the dagger binary, simply running python main.py. This would print the output from the container as well as my program output (i.e., calls to logger.info()) to the console in real time. Once the process was complete, all the container logs + my own would still be clearly visible for reference.
I found this a...
:tada: This fixes DaggerRun, so hopefully we can have our CI go green again! (cc @matipan @gerhard who helped investigate)
This was "introduced" in #7069, when we changed our plain progress to include colors - in conjunction with the new TUI output, this means that we don't have a plain "Container.From", instead, we have magical control codes strewn throughout it. The trick to fix this, is to just set NO_COLOR, and the test passes again!
However! There's another issue here - this test...
[dagger/dagger] Issue opened: #7139 ๐ Python Telemetry: detect when to configure from environment
More context in:
It affects Python users not using modules in v0.11.1 (dagger run python script.py or python script.py). In the meantime, been suggesting that they turn telemetry off:
import logging
import opentelemetry
# TODO: Remove when **not** in v0.11.1
logging.getLogger("opentelemetry").propa...
Clicked merge on the ca cert PR before refreshing the page and seeing it was out of date with main, so missed this signature needing updating.
When nested execs (i.e. execs that can call back to the dagger API) were originally added, they weren't safe since they gave full blown access to the original caller's FS, but that's no longer the case. We can instead make this behavior the default for convenience and instead have a flag for opting out.
There's one last pre-req first, which is handled as part of https://github.com/dagger/dagger/pull/6916. That PR results in nested execs connecting back to the same server (among many other ...
One of the action items discussed in https://github.com/dagger/dagger/pull/7107#issuecomment-2061525961.
Unifies the DX around usage across all commands. The convention follows the standards (gh / git CLIs) as well as the defaults from cobra.
The grammar is as follow:
- []: optional
- <>: user input, to differenciate with static args
- ...: one or more
Another point: [flags] shall always be positioned after the subcommand
This PR applies the grammar everywhere for consistency. ...
Update 370239-module-structure.mdx
What is the issue?
Investigation after a report by @sagikazarmark in:
It appears that dagger init --sdk go overwrites an existing go.mod when run in a context directory with a go package. The context directory is usually the directory that has .git, but if no parent directory has one, it defaults to the directory where dagger.json is.
Also tested on v0.10.3 and got the same result.
Dagger versi...
Similar to Python SDK, uses introspection from t.Dagger.instrospection to generate schema file and mounting it to the container to generate code.
- Upgrade
ex_docto latest version. - Update documentation on the
Daggermodule. - Remove
getting_started.livemd, it's quite out-of-date.
[dagger/dagger] Pull request opened: #7148 fix(sdk/elixir): format function only deprecation message
Follow-up conversation in
https://github.com/dagger/dagger/pull/6559#discussion_r1539733323. The function in backquote should convert to snake case only deprecation message.
Fixes #6939
when I want to add feature for linter makezero in PR https://github.com/ashanbrown/makezero/pull/15 , I run a github action for real world repos, and github action report this bug.
I not going to add this makezero to your golangci.yaml , but I suggest to set to enable-all: true and add some disable linters.
What is the issue?
Many concepts presented in the docs will be more clear to more people of varying experience levels if the prose is accompanied by a diagram giving a visual explanation to reenforce/complement the text.
For example
What are you trying to do?
I see from https://discord.com/channels/707636530424053791/1230428619755753553 and realize that we didnโt export the GraphQL client. Solution that come to my mine at the moment is add special function to Client module to return the graphql client in the codegen.
Why is this important to you?
No response
How are you currently working around this?
No response
Using functions that can error in Container.With is a bad idea. So, what we can do is to put the actual computation into an error group (which has the convenient little side-effect that they all get computed in parallel, hopefully improving build times).
This lets us remove the panic, which was crashing the binary. Because of (I think) telemetry draining, this meant that the client job hung forever on this kind of failure.
cc @helderco I know we discussed previously :tada:
The default is 360 minutes (6 hours) - at this point, something has definitely gone wrong for us, so we should explicitly fail.
Also, for jobs that are known to be short, we can cap at 10 minutes: specifically SDK linting + testing jobs.
This would have prevented long run-away jobs like we discovered with the failed typescript linting intersecting with a crash (causing a client hang):
I may be missing something simple, but I'm currently struggling with Directory.glob returning an empty list instead of the files. Consider this example where I want to match all the files in the deploy/sdk directory. Note the different tmp-* directories:
mydir = (
dag.directory()
.with_new_file("build/tmp-build-a/deploy/sdk/test.txt", "FOO")
.with_new_file("build/tmp-build-a/deploy/sdk/test.manifest", "BAR")
.with_new_file("build/tmp-build-b/deploy/ipk/...
What is the issue?
Per discussion with Jeremy And Solomon on Discord, dropping a request to have the recent (or anything similar) workshop documented in the docs as a tutorial.
For a bit of context, I had been reading up on the prior method of developing Dagger (dagger call) and was ...
This is the "proper" implementation of #6739. This allows us to preserve the original scalar name.
Implemented functionality:
- [x]
TypeDefs have anAsScalarfield, so that they can be connected to their original value.- For example, this allows the CLI to know that a flag is a
dagger.Platformflag. Eventually, this could allow us to have a special value, like"current"as a shorthand to represent the client platform.
- For example, this allows the CLI to know that a flag is a
- ...
What are you trying to do?
Expose the GraphQL client directory from the dag variable
See https://discord.com/channels/707636530424053791/1230428619755753553
Why is this important to you?
Allow greater flexibility and special use case like calling other module
How are you currently working around this?
Current workaround from [this discord message](#1230428619755753553 message)
connect(
async (client:...
What is the issue?
I ran my CI script dagger run npx tsx ci.mts and it made my block cursor disappear.
Dagger version
dagger v0.11.0 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
dagger run npx tsx ci.mts with some Docker stuff that fails.
Log output
โ Container.stderr: String! 47.2s
! failed to compute cache key: write /var/lib/dagger/runc-overlayfs/snapshots/snapshots/36/fs/usr/lib/aarch64-linux-gnu/libx265.so
date: [ 'Mon, 22 Ap...
What is the issue?
The dagger publish command does not work as expected when you are working with git tags and puts the daggerverse into a strange state.
Here is what I expect.
Running dagger publish or dagger publish $TAG inside of a dagger module should publish the latest tag into the daggerverse.
Here is what happens.
- If I run
dagger publishit will publish the most recent commit and even find the correct git tag that shows up in the daggerverse UI. But tryi...
Update _install-cli.mdx to mention macports
What happened? What did you expect to happen?
Dear Dagger Development Team.
Thank you for this amazing toolkit, this project in actuality creates new dimension into CI/CD and software development. I really like all the concepts and different language SDKs.
So my question is, I was trying to integrate dagger into our current system as a controller for our testing pipeline, where we need to evaluate interactions between dozens of services. First I wanted to do this kind of testin...
What happened? What did you expect to happen?
I'd like to pass a container from one module to another. I'm currently doing something like this:
TTL_SH_CONTAINER=$(dagger -m github.com/Dudesons/daggerverse/infrabox call terragrunt container \
...
publish --address ttl.sh/terragrunt-$RANDOM)
dagger -m github.com/Dudesons/daggerverse call terragrunt \
with-container --ctr $TTL_SH_CONTAINER \
...
This definitely works at the moment, but I wish I could keep it loc...
See https://github.com/jedevc/dagger-iface-issue. The issue is that the bar module cannot re-export FooCustomIface.
This should get caught on this error, something like this:
$ dagger -m github.com/jedevc/dagger-iface-issue/bar functions
Error: input: module.withSource.initialize resolve: failed to initialize module: failed to add object to module "bar": failed to validate t...
Fixes https://github.com/dagger/dagger/issues/7139
This refactor was part of adding live progress support to Python telemetry, but it fixes the above and we need it in next release as I won't have time to finish otherwise. It'll make the live progress PR easier to review anyway.
Notable changes
- Moved telemetry code to
dagger.telemetryto establish a convention, after Go. - `da...
Fixes a couple of instances where the base object is changed instead of the copy.
:wave: seems like a bug in the glob pattern matching function. According to this: https://github.com/moby/patternmatcher/blob/main/patternmatcher_test.go#L140 that pattern should work. I even cloned that repository and added the following test case:
tests := []matchesTestCase{
{"build/tmp-*/deploy/sdk*", "build/tmp-build-a/deploy/sdk/test.manifest", true},
and this passed.
It's very likely an issue coming from https://github.com/marcosnils/dagger/blob/9baaa467f14b...
Discussed in https://github.com/dagger/dagger/discussions/7156
Originally posted by skycaptain April 22, 2024
I may be missing something simple, but I'm currently struggling with Directory.glob returning an empty list instead of the files. Consider this example where I want to match all the files in the deploy/sdk directory. Note the different tmp-* directories:
mydir = (
dag.directory()
.with_new_file("build/tmp-build-a/deploy/sdk/test.txt", "FOO...
One of the action items discussed in https://github.com/dagger/dagger/pull/7107#issuecomment-2061525961. It is the first one discussed from the
Branched from https://github.com/dagger/dagger/pull/7143, needs to be merged prior this one.
- Rename all the flag mentions to "options", as proposed by Helder in https://github.com/dagger/dagger/pull/7107#issuecomment-2061525961
- Remove the automatic [flags] append on all commands: https://github.com/dagger/dagger/pull/7107#discussion_r15690...
Problem
Dagger has no direct equivalent to this simple Dockerfile line: ENV PATH=foo:${PATH}.
Solution
Add an optional argument Container.withEnvVariable to allow interpolating the current container's env variables into string arguments. And possibly, add it to other Container functions as well.
The default for this new argument should be true, I think. In other words, interpolation should happen by default.
Then this would work out of the box:
func ...
This is the first in a series of commits to improve the Dagger quickstart. In response to user feedback that some of the examples are too simplistic and "hello world"-y, this commit tightens up the current quickstart to remove or update those examples.
The withEnvVariable API will expand shell env variable by default.
Closes #7171
Partially inspired by https://github.com/moby/buildkit/pull/4828 upstream.
Unused parameters can sometimes indicate weird issues, at the very least that are a bit of a code smell (additionally, gopls in vscode loves to flag these, which is the main reason I wanted to clear them up lol).
Thankfully, none of these are significant, there are no hiding bugs, it's just a little bit of a tidy up.
unparam definitely seems to be optimized for less "noise", and doesn't pick up on every un...
Follow-up to https://github.com/dagger/dagger/pull/6843.
Looks like https://github.com/dagger/dagger/pull/6767 accidentally got removed (by me) during our modularization refactoring, and we got a weird go.mod. So, I'm bringing it back!
This updates the helm app version to the latest release engine.
What are you trying to do?
- Expose functions as
jsonindagger functions.
[
{
"Name": "containerEcho",
"Description": "example usage: \"dagger call container-echo --string-arg yo stdout\"",
"ReturnType": {
"Kind": "OBJECT_KIND",
"Optional": false,
"AsObject": {
"Name": "Container",
"Functions": null,
"Fields": null,
"Constructor": null,
"SourceModuleName": ""
},
"AsInterface...
What is the issue?
Today we have a note box in the docs that says
https://docs.dagger.io/manuals/developer/go/264203/functions/
NOTE
The context and error return are optional in the module's function signature; remove them if you don't need them.
but not all developers will know when they need them or not.
In fact we have a Hello function that uses context, but doesn't need it, which is confusing.
We should expand to say something like
NOTE
The cont...
- Use
dotnetversion 8. - Add editorconfig to make
dotnet formatworks. - Run
dotnet formatto all projects.
What is the issue?
I have a module, where using credentials is optional, e.g.
import dagger
from dagger import function, object_type
@object_type
class Test:
username: str | None = None
token: dagger.Secret | None = None
name: str | None = None
@function
def call(self) -> str:
return f"Hello, {self.name}!"
When I call this module like this, I get a valid response:
$ MY_TOKEN="very_secret_variable" dagger call -m tes...
Already in the Go SDK through several PRs.
Related:
- #7159
- #7152
dagger functions func1 --help is currently breaking, as --help is interpreted / manually parsed as a function and not as a flag
This was discussed here: https://github.com/dagger/dagger/issues/6943#issuecomment-2067514623.
Branched from https://github.com/dagger/dagger/pull/7170. To be rebased once merged
What is the issue?
Our quickstart recommends a few daggerverse modules, including yamlinvaders, but this module does not start up anymore. We should either fix this module, or remove the example from the docs.
Play a game of yamlinvaders: dagger -m github.com/sipsma/daggerverse/yamlinvaders call play terminal
What is the issue?
We're using service containers as a form of basic local up for our developers. This means that we've got a basic set of features available during either development or a local go test ./... that can use these databases.
client.
Container().
From("rabbitmq").
WithExposedPorts(...)
AsService().
Start(ctx)
What we've experienced is that these tests run fine once, but on the second run they cannot form a connection with the service containers. We...
This PR updates the shim to propagate DAGGER_ENGINE_* environ on the engine to pipeline containers. Part of #6599
Alternative solution to #7183
Discussed in https://github.com/dagger/dagger/issues/6943#issuecomment-2067514623.
Example
dagger -m github.com/levlaz/daggerverse/mariadb@v0.2.1 functions base --help
Before
Error: no function '--help' in object type 'Container'
After
List available functions in a module.
This is similar to `dagger call --help`, but only focused on showing the
available functions.
USAGE
dagger functions [flags] ...
This PR adds the option of running the engine on top of the Wolfi base image.
There are some advantages to using Wolfi here:
- similarly small size to the Alpine image
- support for glibc
- support for GPU tools
This PR is really a work-in-progress, but I wanted to get some feedback. To test, I manually set the base image in the struct, ran hack/dev then verified the engine container was running on-top of Wolf...
What is the issue?
On errors the dagger-rust sdk doesn't understand how to parse the errors from the graphql endpoint
Dagger version
dagger v0.10.2
Steps to reproduce
Simply get a rust dagger program to crash
Log output
Error: failed to query dagger engine: http error: Failed to parse response: Error("invalid type: sequence, expected a string", line: 1, column: 211). The response body is: {"errors":[{"message":"resolve: container: withFile: withExec: withEntrypoint...
Attempting to revive #6248 - see discussion in discord [here](#go message).
What is the issue?
We've hit this error a few times in https://github.com/dagger/dagger/actions/runs/8821414426/job/24217223788?pr=7082, part of:
2024-04-24T18:36:16.3979153Z [95m117: [0mDONE 1325 tests, 3 skipped, 2 failures in 605.184s
2024-04-24T18:36:16.3979462Z
2024-04-24T18:36:16.3979728Z panic: runtime error: invalid memory address or nil pointer dereference
2024-04-24T18:36:16.3980302Z [signal SIGSEGV: segmentation viola...
Fixes #7145 - essentially, we need to a more careful merge of go.mod and go.sum when adding dependencies, instead of replacing them.
Essentially, when doing a dagger init --sdk=go in an existing go repo, we were following a code path that meant we weren't using the builtin go.mod/go.sums at all, and were instead relying on go mod tidy to do something reasonable (which is also slower!).
Additionally, when using dagger develop, we never preserved go.sum, always completel...
Description
A tiny sort of boy-scout contribution. I've noticed that there are some unused variables that can be easily removed to keep the code clean and readable. It's related to [this](#maintainers message)
Is this an intermediary step that we can take towards migrating to new CI runners? Related to:
If the Engine & CLI workflows passes, I would be tempted to merge this before the other PR. The focus is to migrate off the legacy CI as soon as possible.
Trade-offs:
- If we keep the current
DAGGER_CLOUD_TOKEN, we will not be able to use the Cloud Cache in PRs coming from forks - If we add the
DAGGER_CLOUD_TOKENsecret, this will not be avai...
Problem
There are two types of Dagger modules: those that are standalone software projects, and those that exist in the context of a software project. Let's call those standalone modules and contextual modules, respectively.
Dagger is designed to support both, which is good, but causes friction for users in some areas.
- Contextual modules almost always need access to their context directory. Today this requires an explicit argument, which is verbose.
- Contextual modules oft...
Backfill the changelog with recent CLI changes that have been merged
What are you trying to do?
First class or at least decent support for pushing to Git repositories.
Why is this important to you?
Dagger already has first-class support for pulling from Git repositories (even if private repo support isn't trivial).
It's often important to push changes back to a repository. A couple use cases in mind:
- Regenerate SDKs from API descriptors upon change
- Update GitOps manifests when a new version is out
Unfortunately, feeding credentials int...
This PR was auto-generated.
An automatic upgrade here seems to have caused an issue where colima was not available.
Previously, we would mark a parameter as optional in two cases:
- With a
// +optionalpragma comment, - Any pointer to a primitive (string, integer, boolean)
This second one is a leftover from when optionals in the Go SDK was purely indicated using pointer-iness. When working on this before, I think I must have missed this one, or I would have tried to remove it then :D
In this PR try to modernize DotNet SDK by do the following:
- Upgrade .net from 7 to 8.
- Setup
.editorconfigto makedotnet formatworks. - Rework on query builder by introduce
QueryBuilderclass and port the logic from Go to it. Mostly feature is covered I guess. - Restructure folder from
DaggerSDKtoDagger.SDK. - Temporary move
DaggerSDKCodegenout of the solution. We will tackle next after this PR. :)
What is the issue?
Some Mac users have been having issues lately as they have either rosetta or the DEFAULT_PLATFORM variable set to something other than arm64 when using Dagger with Docker Desktop installed. ref: https://discord.com/channels/707636530424053791/1232715125480493127
We should add a note in our docs that in case of issues running our hello example in Mac + Docker Desktop, to double check this. It's also important to clarify that if they effectively ran into this is...
Repro test:
func TestLogDrop(t *testing.T) {
t.Parallel()
var logs safeBuffer
c, ctx := connect(t, dagger.WithLogOutput(&logs))
_, err := c.Container().
From(alpineImage).
WithEnvVariable("BUST", identity.NewID()).
WithExec([]string{"sh", "-c", `i=0; while [ $i -lt 2000 ]; do echo ` + strings.Repeat("$i", 100) + `; i=$((i + 1)); done`}).
Sync(ctx)
require.NoError(t, err)
require.NoError(t, c.Close())
scanner := bufio.NewScanner(&logs)
var i int
expe...
Problem
Cache volumes exist in the engine's global namespace: if modules A and B each create a cache volume with id foo, they will share read and write access to the same volume, as long as they are run on the same engine. This allows one module to corrupt the data of another module, either accidentally or maliciously.
Solution
Namespace the name of cache volumes, so that each module can only read and write to its own cache volumes.
Problem
When loading a local module, absolute paths are not supported.
Example:
dagger -m /foo/bar functions
Output:
! local module source root path is absolute: /foo/bar
Solution
Allow loading local modules from a local path.
This is a combo of:
- A few parts extracted out from: https://github.com/dagger/dagger/pull/6916
- A cherry-pick of @vito's fix here: https://github.com/dagger/dagger/pull/6914
Basically, I finally got back to #6916 and found the bare minimum changes needed to get #6914 working fully, which is the first commit here. But then I also realized that I actually needed #6914 in order for services to work and existing tests to pass; basically, the changes ended up being codependent and I had to...
Fixes gitlab beore script by installing the Dagger CLI in a location that's availabe in the $PATH
This feels insane, I'm not quite sure what is going on here. There appear to be 2 separate vulnerability advisories, one in runc and one in cri-o (which doesn't seem to be available yet).
However, this issue definitely doesn't affect us - we don't use cri-o anywhere in our stack, we're not spawning pods in the dagger engine, etc.
There's also not a version of runc we can feasibly upgrade to - 1.2.0-rc1 (as suggested in https://github.com/advisories/GHSA-c5pj-mqfh-rvc3), is a minor relea...
Some linters don't like this, which is a small issue, but it's super easy to fix :D
Problem
In many cases it's not clear for module consumers how to use them once they find them in the Daggerverse. Even though https://daggerverse.dev has detailed docs about the module functions, their arguments and return types, sometimes modules are designed to be consumed in a particular way which is currently hard to express given the current module documentation features.
For example, looking at this module: https://daggerverse.dev/mod/github.com/jcsirot/daggerverse/java@c591e9...
Problem
Dagger modules and Daggerverse do not work with other SCM than GitHub.
For the past few months, several discussions have occurred around the best way to solve it. This is now a top-priority on the backlog. Your opinion is extremely valuable to assess what behavior you would expect as a user, taking into account the pros and cons of each alternative, especially scope and DX wise.
Context
The current way of calling a [module ref](https://github....
Alternative to #7216 - turns out, #7216 is an issue but for the opposite reason.
MarshalJSON should always be defined on the base, not on a pointer receiver - we had mismatched between the object + interface in our codegen, this PR updates our interface to be the pointer receiver.
Sorry @aweris :cry:
What is the issue?
While working on #7202 I noticed that mounting an SSH key as a secret in a container always leads to Load key "/ssh-key": error in libcrypto errors.
Dagger version
dagger v0.11.2 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
The code reproducing the issue can be found in my daggerverse:
git clone https://github.com/sagikazarmark/daggerverse.git
cd daggerverse
git checkout ssh-key-repro
cd ssh-key-repro
chmod 600 id_ed25519
...
This commit updates the troubleshooting guide on the basis of the discussion at https://discord.com/channels/707636530424053791/1232715125480493127
Closes #7209
Specifically! This doesn't spin up a docker container with a dev version of dagger, it spins up a dagger service with a dev version of dagger - dagger in dagger!
This simplifies deployment to the new CI runners.
At some point, it would be nice to have the ./hack/dev script use this as well - however, I'm not 100% sure how this would work with other core devs' workflows. Personally, I periodically run ./hack/dev to build and restart the docker engine, and use ./hack/with-dev...
Follow-up to https://github.com/dagger/dagger/pull/7215.
It looks like https://github.com/advisories/GHSA-c5pj-mqfh-rvc3 has now been withdrawn - trivy seems to have picked up on this now, so we can remove this file now :tada:
Still not sure why this happens, but I'll be on PTO soon, so best to apply a band-aid for now.
So far I've only seen this happen when there's total loss of data from the dagger-engine otel service, indicating something went very wrong with the engine pub/sub, since that's >~90% of the data.
A log will help for now.
This removes the ftp_proxy hack we've had for a while for passing uncached metadata to containers (previously a lot, but recently trimmed down to just ServerID).
Instead, we take advantage of the new custom executor added recently and use that to set the _DAGGER_SERVER_ID env var in containers. The plumbing passes the ServerID via job values, which get read by the solver's ResolveOp callback and used to tell the Executor for ExecOps which ServerID to set in the container.
There's quite ...
What are you trying to do?
Pass a Secret to a commands stdin (without having to resolve it first):
secret := dag.SetSecret()
ctr.WithExec(
[]string{"helm", "login", "--username", "foo", "--password-stdin"},
ContainerWithExecOpts{SecretStdin: secret},
)
Why is this important to you?
Passing secrets to commands in plaintext isn't particularly safe. Although the documentation says that logs ar...
Problem
In monorepos, it's common for each sub-project of the repo to have its own submodule. But there is no easy way for the root module to "pass through" the functions of its submodules to the user. For example:
- submodules
frontendandbackendare installed in the root module dagger call frontend buildwon't work: insteaddagger call -m frontend buildis required.dagger functionsshows no functions
Solution
Allow specifying a dependency as exported. Th...
This significantly improves initial directory upload speed, on my computer this goes from 4.8s to a much better 2.5s.
Ideally, we could also avoid uploading the git directory. This is a bit of a pain right now though, so we don't do it!
This is a very bad default to recommend - essentially this "de-secrets" a value, and this could then be leaked accidentally:
- Potentially into OTEL spans
- Potentially into cache keys
- Potentially into engine logs
We should recommend using WithSecretVariable instead, which is much better - then rely on the shell to do the interpolation, which avoids all of these problems. The secret scrubber will then guarantee that we don't secrets leaked into logs.
Use these newer methods instead of using container and file to load IDs, which is deprecated and going to be removed soon.
Follow-up to #7231
Previously, we were using this to generate a work-tree hash, so that new builds would have a different version tag, which helped to solve some weird caching issues with nested execs.
However! A problem with this was that we needed to upload the entire git directory every time we built - which is an expensive operation, my .git directory for dagger/dagger is 147MB.
Instead of relying on git for this, we can use the ID of the input directory! Because of our use of ...