#github-feed
1 messages · Page 8 of 1
Problem
When creating a Dagger module, the source of the module has to be at the root of the module (ie. in the same directory as dagger.json). This is not always practical. In particular, when embedding a Dagger module in an existing software project, the ideal location is not the same for dagger.json and for the module source:
- Ideal location for
dagger.json: the root of the parent software project. This could be the root of the repository, or in the case of a monorepo, the ...
What are you trying to do?
Some software may need more complex readiness checks in addition to checking port availability (eg. to deal with eventual consistency).
Most common example is calling an HTTP endpoint and checking it's result.
Why is this important to you?
Both Docker Compose and Kubernetes have these kinds of checks. When moving from any of those to a Dagger based developer environment, this may be an important bit when checking feature parity.
How are you curren...
This PR was auto-generated.
Without this we're getting nil panics when using dagger shell.
Went unnoticed because we haven't added test coverage for dagger shell to the integ tests yet due to the fact that testing tty programs in our current testing setup is very non-obvious.
I will add whatever best test I can in a follow up to this PR, but sending the fix separately since it is quite trivial and probably an order of magnitude less time consuming than figuring out a test.
During the most recent release we caught a typo in the URL paths used to download cli/checksums in the Python SDK during the bump engine PR (fix).
This worked as expected in that it caught the problem before we published the SDK, but it would have been slightly more convenient if we caught it earlier than the bump engine PR (which is the last step before publishing the SDKs).
The problem is th...
Sometimes the engine publish job needs to re-run independent of the CLI publish, but right now because it all happens in the same job you can't run one without the other, which can create headaches where a re-run results in partial success (re-running engine publish) but failure during CLI publish.
If the jobs were separate but dependent this could be a lot cleaner to deal with.
cc @gerhard, creating issue for what we mentioned during the last release process
This commit updates the warning in the CLI reference to be more explicit.
This is attempt numero due to fix Nix package publishing to dagger/nix.
https://github.com/dagger/dagger/pull/6063 added Nix to the GitHub Actions workflow, but GoReleaser actually runs in Dagger using a GoReleaser Pro image.
This PR removes Nix from the GHA workflow and adds Nix to the GoReleaser image.
(Reminder: we only need nix-prefetch-url for GoReleaser to work, but it's not bundled with their image and installing Nix from the Alpine package repo seems to be the easiest way t...
What are you trying to do?
I'm trying to show nonexecution messages in my module execution in focus mode to give the user meaningful information. However, it's impossible to do it without using the container WithFocus + WithExec at the moment. It would be amazing to have some logging support in generated client code.
Why is this important to you?
Some useful or important information to make execution is lost in execution.
How are you currently working around this?
Wrapping ...
Previously, these logging messages were only added on the publish job provisioning tests: https://github.com/dagger/dagger/blob/9a0f81a7367a675b13854f0be82694d4ebc44dd3/.github/workflows/publish.yml#L251-L256
This meant that failures in the engine and cli jobs didn't trigger this type of message, and so makes crashes more difficult to debug. We already print the kernel logs, we just don't grab the engine logs.
This would have been useful when encountering https://github.com/dagger/dagge...
When building a module that has a "go.mod" that depends on a commit sha from a repository, we may require the git binary to be present.
Since this is not included in "golang:alpine" official images, we should explicitly install it.
I seem to remember a discord discussion around this, but given discord's wonderous search, I can't seem to find it :scream:
This is a small-ish scale refactor that results in the code we use to parse various types/functions/etc. in the go module codegen code. There should be no functional changes, just code refactor+cleanup.
The gist of the idea is that rather than having single methods that do both the type parsing and then return generated code for typedefs, we have a method that does the type parsing and then returns a type that implements an interface which has separate methods for getting the generated cod...
This PR has two distinct parts (I can split up if it helps, but they made sense to bundle together to me).
In part 1, I merge a couple more consts into the shared common internal/mage/consts package which was recently introduced in https://github.com/dagger/dagger/pull/5557/files#diff-1d8655625df99d708502c2f351eef188e9079cfbd8b3634adc614ca7ddd41f04. Previously, we were just duplicating certain magic string values, which was error-prone. There's also some general cleanup here.
In part ...
Main goal here was to add integ test coverage for dagger shell after missing a really straightforward nil panic as a result of not having coverage: https://github.com/dagger/dagger/pull/6240
We didn't have coverage before because integ testing TUI programs is not usually straightforward. The solution here uses the https://github.com/Netflix/go-expect library to drive the program and run some simple commands in an alpine shell and verify their output. It worked out reasonably well and base...
What is the issue?
When I created a module constructor with // +optional=true missing flag returned a pointer of the empty object instead of nil.
Example Code:
package main
func New(
// +optional=true
src *Directory,
) *A {
return &A{Src: src}
}
type A struct {
Src *Directory
}
func (m *A) IsEmpty() bool {
return m.Src == nil
}
Log output
dagger call is-empty
✔ dagger call is-empty [1.38s]
┃ false
• Cloud URL: https://dagger.c...
Fixes https://linear.app/dagger/issue/DEV-3086/pull-user-commit-message-in-a-context-pr
When collecting labels on the engine in a VCS context, sometimes, the commit head is an appended commit (from that VCS) [PR / MR]. This fix skips the merge request commit when it is the head.
Repro/test: https://gist.github.com/grouville/6cf442d86c41c0746bbef1812160e7c0
This adds initial support for interfaces: https://github.com/dagger/dagger/issues/6213. See that issue for a description of the problems it's solving.
The support here is very much MVP and has a lot of restrictions (mentioned below). However the PR is already borderline too big so I think we can merge with approximately the current feature set and fill in gaps as needed in follow ups.
**NOTE: it's getting a bit late and taking a while to finish documenting everything, so some sections s...
What is the issue?
I've tried to run Dagger in docker-in-docker on top of sysbox, but it doesn't work - because it seems like sysbox doesn't allow Dagger to create a new network namespace
Log output
time="2023-12-12T09:19:13Z" level=info msg="detected mtu 1500 via interface eth0"
dnsmasq[89]: started, version 2.89 cachesize 150
dnsmasq[89]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-nftset auth no-cryptohash ...
What are you trying to do?
When grouping various actions in a "submodule", there is no way to assign an action to the parent at the moment.
Given the following module:
type Ci struct{}
func (m *Ci) Lint() *Lint {
return &Lint{}
}
type Lint struct{}
func (m *Lint) All(ctx context.Context) error {
var group errgroup.Group
group.Go(func() error {
_, err := m.Go().Sync(ctx)
if err != nil {
return err
}
return nil
})
group.Go(func() error...
Fixes #6252 (the equivalent #6227, but for core types instead of user module types).
In #6167, it looks like we missed another nil check, which manifests as core module types not being set to their zero value but to an empty struct.
Additionally, it looks we regressed on #6057, and we weren't correctly converting field names back into the field names that the module requested. Thankfully, this is a pretty simple fix, and I've verified manually this works. I'm not quite sure of a test ...
This goes some way to fixing #6071 (@sipsma up to you if you want to leave it open for tracking the subpackage aspect, or splitting up core)
This allows a module "foo" to define it's own "FooContainer" type that won't be additionally namespaced into "FooFooContainer".
Previously, we skipped namespacing if the object was named the same as the module.
However, with this patch we can now additionally skip namespacing if the object if prefixed with the namespace.
This prevents a tiny visual glitch which is confusing in the TUI output where we get identical custom names.
I noted this in a debugging session with @marcosnils where we were seeing the same message in the TUI and in the cloud. Eventually, it would be nice to remove this, but adding this in at least helps to remove the visual confusion as to why there are duplicates.
What are you trying to do?
Discussed in discord with @vito and @marcosnils: #maintainers message
It would be nice to have some subcommands for the dagger cli that can help inspect and prune the cache. At a basic level, it would be nice to have similar behavior to buildctl du and buildctl prune.
Future extension ideas:
- Nice visualization of cache records and how they link to each other
- Listing and pruning o...
Stopping the engine regardless of build status is a recommended best practice to make sure cache is always uploaded.
The current Zenith quickstart uses a pre-built module and focuses on teaching the user the various sub-commands/features of the Dagger CLI. While this is a good learning path for the CLI itself, it does not do Dagger justice as it fails to capture the power of creating reusable modules and leveraging the Daggerverse. It is also less impactful than the pre-Zenith quickstart, which provides a more hands-on learning experience by having the user build a new pipeline from scratch.
This commit ...
What are you trying to do?
I've been looking into using Dagger for our CI pipeline in which one of the main tools we use is Bazel.
The issue with using Bazel in Dagger is that the Bazel startup time(Analysis phase) grows as your repository grows.
Most organizations using Bazel end up using persistent CI workers to lower this startup cost since Bazel keeps the repository state in memory and this makes incremental build very fast once the analysis phase is over.
This model is kind...
How to always execute specific withExec(...), without checking for cache.
In cue we had flag on docker.#Run always: true
You can use a cachebuster value, as described in the cookbook: https://docs.dagger.io/cookbook/#invalidate-cache.
You can use a cachebuster value, as described in the cookbook: https://docs.dagger.io/cookbook/#invalidate-cache.
Reported by @jedevc in https://github.com/dagger/dagger/pull/6258#issuecomment-1853740495
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/pytest-of-root/pytest-0/cache_home0/dagger/dagger-0.0.0'
The automatic provisioning garbage collector probably needs a lock:
https://github.com/dagger/dagger/blob/970bcfe512cfc699005c46992f52a8...
What is the issue?
Noticed during #6117 that some integration tests were causing a panic to show in the TUI. @sipsma reported in https://github.com/dagger/dagger/pull/6117#pullrequestreview-1778643232.
The tests pass fine and the SDK gets a correct dagger.ExecError, but the panic pollutes the screen and makes it seem like there's a bigger problem.
The issue is in the shim:
You can also get support and suggest ideas on the Dagger Discord - https://discord.gg/dagger-io.
We could create a GetStarted module that opens an interactive shell and teaches you how to use Dagger.
You could take this really far, but as a baseline it could just be a container w/ the dagger CLI and some example module code. It then presents you with prompts for dagger CLI commands to run that show off the various things you can do.
More interesting stuff you could layer on top of that baseline:
- Per-SDK tutorials (i.e. specific ones for Go, Python, Node, etc.)
- You could...
Adds quite a few python test cases for existing tests in Go.
Signed-off-by: Marcos Lilljedahl
Fixes argOrder regexp when default arg is set.
Add test on overriding default arg on registry test. Set return type as optional when input type is void. Add tests for Typescript in module_test.go.
Fix ModuleRuntime to include codebase.
- This fixes the
dagger mod installcommand - This fixes using a module without
sdkgenerated in the host.
Fix loading arg to handle array and strings.
Fix entrypoint to load parent state too.
Check for defined result.
Serialize fields that ha...
Summary
With host to container networking we have a better workaround than the current Load Container Images into a Local Docker Engine guide. Use a similar approach to 📖 Add import image from docker guide.
Rationale
Same as #5235, even though we don’t have the plumbing to use a service in Container.publish yet, we can automat...
What is the issue?
A module that used to work in Dagger v0.9.3 doesn't work in v0.9.4:
dagger-0.9.4 -m github.com/vito/daggerverse/test call testcontainers
Log output
┃ Error: response from query: input:1: main.testcontainers failed to get function output directory: process "/runtime" did not complete successfully: exit code: 2
✘ testcontainers ERROR [3.01s]
✘ exec /runtime ERROR [3.01s]
┃ input:1: testcontainers.dockerService failed to get function output d...
This commit removes the docs/current stub. which is not required any longer.
fixes #6066
No real UX improvement from before since it's still async and won't surface any crawl errors, but it at least does something now.
What is the issue?
Assume closed intranet, with no Internet access.
I’ve seen questions about this in Discord and it’s essentially what this OP is asking for:
There’s a few pieces of documentation to put this together and a few responses in different places but it would be helpful for those with this use case to have a unified body of documentation.
If not a guide on https://docs.dagger.io, it can be a section in the [operator manu...
When calling GetRemotes to get a descriptor for the local source, so we can put into our custom BlobSource, buildkit creates a custom buildkit/createdat annotation on the descriptor that represents the timestamp that the blob was created at.
By default, we were pulling all of the descriptor annotations into the source identifier, which as a result changed the LLB definition (and the vertex digest, which obviously causes all of the dependents to change as well). This can be observed i...
Did a dagger mod sync on snippets with a dagger.json, removed all generated files from the others.
Oh look it's #6181 #5972 #6068 again.
This behavior regressed in v0.9.4 (with #6181 lol).
Fields can have zero names - in which case we shouldn't accidentally discard the entire field, woops.
I've added a pretty comprehensive test for all these scenarios, getting very annoyed having to fix them all.
Also some other smallish related fixes I ran into while trying to get this working.
Fixes https://github.com/dagger/dagger/issues/6044
⚠️ Warning
Based on https://github.com/dagger/dagger/pull/6278 so don't merge before that. To review, filter for last commit. Also, perhaps better to merge only after the christmas holidays.
What?
When Container.withEntrypoint is set, it will clear Container.defaultArgs, unless withEntrypoint(args: [...], keepDefaultArgs: true) is set.
Fixes https://github.com/dagger/dagger/issues/6051
⚠️ Warning
Based on https://github.com/dagger/dagger/pull/6280 so don't merge before that. To review, filter for last commit. Also, perhaps better to merge the breaking change only after the christmas holidays.
What?
The args field of Container.withDefaultArgs is no longer optional:
- ctr = ctr.WithDefaultArgs(ContainerWithDefaultArgsOpts{Args: []string{"foo"}})
+ ctr = ctr.WithDefaultArgs([]string{"foo"}...
See https://github.com/dagger/dagger/issues/6272#issuecomment-1858003650:
https://github.com/dagger/dagger/commit/77760c2754575695f6a9329c79c4c6a2d6078a65#diff-42df7f581f0c9e41a3320a7be6c79027f0b373d77e57231d767b3539643a4da8L155-R152 modified the logic so that the following struct would be code-gened:
type Foo struct {
X string
}
However, if Foo is not reachable from methods/fields on the main struct, then we should not include it on our code-gen and field decla...
Continuing my journey through the forest of a thousand go-sdk papercuts :tada: (sorry for all the small PRs, I figure they're easier to review and merge separately, and I'm just opening them as I find them and have time to fix them :cry:)
Previously, if two methods had the same name (but on different struct receivers), it was accidentally possible to confuse the two.
With this patch we now ensure that as well as matching the names, we also match the receiver name.
Saw while reviewing PRs that the TestModuleDaggerShell test was flaking sometimes specifically in the testdev workflow. Have never seen this flake in the other "normal" integ test workflow or locally.
From the logs I saw it looks like it is running as expected but just extremely slow, to the point that the generous timeouts weren't enough.
The testdev workflow is extra slow and overloaded for various unrelated reasons (doesn't actually run on the shared runner and doesn't have the same ...
What is the issue?
New issue to test linear integration.
Dagger version
v0.9.4
Steps to reproduce
No response
Log output
No response
What is the issue?
When attempting to run the examples provided in the dagger module's documentation, I encountered two issues that presumably have the same underlying cause regarding the automatic camelCase conversion performed in the Python SDK.
First issue
Take the following example (taken from here):
"""A Dagger module for saying hello world!."""
from dagger im...
⚠️ Warning
Based on https://github.com/dagger/dagger/pull/6268.
Will fix https://github.com/dagger/dagger/issues/6286, but no actual fix yet. Just added test to reproduce reported use case.
Problem is that the parent value of a function call is sending the GraphQL cased field names instead of original names.
Example
from dagger import field, function, object_type
@object_type
class HelloWorld:
my_name: str = field(default="World")
@func...
This patch starts to simplify the connhelpers and docker-image helper into specific engine drivers (see https://github.com/dagger/dagger/issues/5583) - adding new drivers now becomes easier.
Each driver registers itself under a name, and is called when connecting to a URL with that scheme. Additionally, during connection, we provide a set of additional parameters.
This is mostly just a refactor around the connhelpers, which we can't use directly out of the box, since we want to support ...
In Modules using the Go SDK you get a pre-made dagger client called dag that's ready to use at init.
For non-module Go SDK code (i.e. SDK code that runs directly on a caller's host), you still have to explicitly create a dagger client with dagger.Connect and use that.
We should retain support for dagger.Connect since it has useful options like configuring the destination of log output that users may sometimes want to customize. However we can also add support for a pre-configured ...
What is the issue?
From documentation
https://archive.docs.dagger.io/0.2/1200/local-dev
it says:
git clone https://github.com/dagger/todoapp
cd todoapp
dagger project update
dagger do build
But get error:
dagger project update
Error: unknown command "project" for "dagger"
Run 'dagger --help' for usage.
Currently, by default the engine loads the directory tree at a module's dagger.json and nothing else. However, to support cases where there are files/dirs the module relies on that are outside that directory tree (i.e. a go.mod, package.json, another dependency module that exists relative to the module, etc.) there exists a root field in dagger.json that allows you to specify a parent directory that the engine will load instead.
This technically works but is inherently very confusi...
Right now when checking out git repos (whether users of our Git API in core or Dagger's internal use for e.g. loading modules), even if only one subdirectory of a git repo is needed, the full repo still needs a clone (to my knowledge).
We use buildkit's Git source implementation, which does jump through hoops to use sparse checkouts and performance optimizations, but it doesn't yet support features in newer versions of git that enable only pulling the files needed for a certain subdirec...
This lays out of some of the low-level plumbing needed to support https://github.com/dagger/dagger/issues/6229 :
- Adds the ability for clients to inspect the entirety of the current schema as a set of
TypeDefs.- Previously callers could only do this for a single module; now it can for everything loaded into the schema, including core APIs.
- Adds an internal flag to the CLI plumbing to optionally include the
coretype defs it now has access to thanks to the above - Adds a f...
Fixes https://github.com/dagger/dagger/issues/6265
I considered adding a file lock to the provisioning which would also prevent downloading the CLI multiple times, but it's not done in the other SDKs. Quick fix here is to just not complain if the file to remove doesn't exist anymore (race condition).
The synchronization primitive is not necessary to fix the issue but since I was looking at the Go implementation this matches it a bit more closely.
Follow up to https://github.com/dagger/dagger/pull/6280 for doc snippet updates.
⚠️ Warning
To merge after the above is released.
Summary
Update our docs to use the simpler global client—on SDKs that support it—instead of requiring the client instance to be passed around.
Background
The suggestion was initially made by @aluzzardi in https://github.com/dagger/dagger/pull/5060#discussion_r1189242491 regarding a simpler DX in the (experimental) Zenith modules:
Expand quote
[…] since we're in the process of radically changing the DX, I'm going to put it out th...
This is an early draft PR, will add more context soon, just want to get a PR up early.
This PR swaps out our GraphQL server infrastructure for DagQL.
goals
- better telemetry / visualization
- a stable, useful format for IDs
- shorter IDs
- saving and loading pipelines (#3923)
- global query cache to replace ad-hoc caching (modules, container build/import)
- a clean purpose-built GraphQL stack to replace our two forks
What is the issue?
I'm trying to follow the getting started guide for Python and getting the below error.
Guide: https://docs.dagger.io/sdk/python/628797/get-started
Error:
dagger run python test.py
┣─╮
│ ▽ init
│ █ [1.47s] connect
│ ┣ [0.18s] starting engine
│ ┣ [0.23s] starting session
│ ┃ OK!
│ ┻
█ [0.58s] ERROR python test.py
┃ Traceback (most recent call last):
┃ File "/Users/lulopzpe/build/apps/lm/eNext/POC/core-ui/test...
Follow Go and Python quickstart to create one for Typescript.
Update generated doc with latest changes.
Related to DEV-3148
Follow up to https://github.com/dagger/dagger/pull/6281 for doc snippet updates.
⚠️ Warning
To merge after or when the above is released. Based on it, filter dedicated commit to review.
this doesn't have any security implications since the token onyl has
access to send telemtry to cloud and cannot access any caching
resources. The cache access in our self-hosted runners is handled by the
DAGGER_CLOUD_TOKEN env var which is set at the runner level
Signed-off-by: Marcos Lilljedahl
Example:
function hello(msg = 'hey') {}
Hit this while backfilling integ test coverage for dagger up as part of CLI changes. Repro below.
Module code:
package main
import "context"
func New(ctx context.Context) *Test {
return &Test{
Ctr: dag.Container().
From("python").
WithMountedDirectory(
"/srv/www",
dag.Directory().WithNewFile("index.html", "hey there"),
).
WithWorkdir("/srv/www").
WithExposedPort(...
cc @dagger/sdk-rust :heart:
I frequently see this rust test failing: https://github.com/dagger/dagger/actions/runs/7263920431/job/19790293305 (which passes upon a re-run):
Diff :
failed to query dagger engine: domain error:
Look at json field for more details
pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
Not quite sure why this shows up, but it appears reasonably frequently, so wou...
This implements my suggestion from https://github.com/dagger/dagger/pull/6280#issuecomment-1864269265.
withoutEntrypoint also modifies the entrypoint, and so should follow the same style and reset the default args (allowing toggling this behavior in the same way as withEntrypoint).
Fixes https://github.com/dagger/dagger/pull/6245#issuecomment-1866175753 (cc @sagikazarmark)
The apk package for nix is only available in alpine:edge atm, and goreleaser does not use alpine:edge.
So, we can install it using the same method we were previously using in github actions - the logic is borrowed from https://github.com/cachix/install-nix-action/blob/master/install-nix.sh#L76 and https://github.com/cachix/install-nix-action/blob/master/install-nix.sh#L104.
What is the issue?
Our docs do a good job discussing why its necessary to have a privileged container (https://github.com/dagger/dagger/blob/main/core/docs/d7yxc-operator_manual.md) but we do not mention why it is safe to do so.
We should provider some additional documentation so that security teams can have more context to make the right infrastructure decisions for their organization.
This PR was not auto-generated. The v0.9.5 publish job failed: https://github.com/dagger/dagger/actions/runs/7289942610/job/19865637361.
However, only nix failed, everything else succeeded - so I've just opened this PR manually to continue with the release.
(The nix issue seems related to permissions, I suspect that RELEASE_DAGGER_CI_TOKEN doesn't have access to write to https://github.com/dagger/nix)
What is the issue?
See https://hexdocs.pm/dagger/Dagger.Container.html#experimental_with_all_gp_us/1. The function name should be experimental_with_all_gpus, experimental_with_all_gp_us
Dagger version
dagger v0.9.4
Steps to reproduce
No response
Log output
No response
When module code uses dag.Host(), the "host" it refers to is the module container's "host", not the CLI caller's host.
While this is technically consistent, it's very non-obvious at first glance and a constant source of confusion.
I think at a minimum we need to change Host to something with a more obvious name. TBD if this change also impacts non-module SDKs or if it's somehow scoped just to the codegen for modules.
There's certainly larger scope changes to the API that could a...
Private tracker related issue: https://linear.app/dagger/issue/DEV-2944/cli-pass-secret-arguments-by-name-not-by-value
This PR changes how secrets are passed as args in the dagger CLI.
Whereas previously a function arg of type Secret was passed in the cli by plaintext, now secrets are passed on by specifying a source of the secret. This is intended to be much more secure and convenient to users.
This PR adds support for:
env:MY_TOKEN- read the secret from the env var `MY_TOKE...
Noticed by @gerhard during the v0.9.5 release:
Noticed that the https://docs.dagger.io/current/sdk/nodejs/reference/modules/api_client_gen link is now broken, most likely after the Docusaurus v3.0 refactoring. The links comes from https://github.com/dagger/dagger/releases/tag/sdk%2Fnodejs%2Fv0.9.5
In #6311, I've fixed the docs link for future releases, but we should add a redirect for previous changelogs. It looks like this was changed during #6164.
Before
dagger functions dumps all functions available in all types for a given module, regardless of arguments. So I can't see what functions are available at a given stage of the pipeline.
Example:
$ dagger -s -m github.com/shykes/daggerverse/wolfi functions
object name function name description return type
*Wolfi ...
I would like to utilize Dagger along with the Python SDK to configure my CI pipelines across multiple projects. In order to avoid unnecessary repetition, I intend to externalize certain functions into a shared Python library called my-private-library. However, since this code is intended to remain private, I opt to utilize a private PyPI registry. My pyproject.toml looks like this:
[project]
name = "main"
version = "1.0.0"
description = ""
dependencies = [
"my-private...
Add generated java sdk schema for engine versions 0.9.4 and 0.9.5.
Upgrade Maven to get rid of validation issues from an old maven version.
[WARNING] Plugin validation issues were detected in 1 plugin(s)
[WARNING]
[WARNING] * org.apache.maven.plugins:maven-plugin-plugin:3.7.1
[WARNING] Declared at location(s):
[WARNING] * org.apache.maven:maven-core:3.9.2:default-lifecycle-bindings @ line -1
[WARNING] Used in module(s):
[WARNING] * io.dagger:dagger-codegen-maven-plugin:1.0.0-SNAPSHOT (dagger-codegen-maven-plugin/pom.xml)
Overview
I regularly see developers get confused (sometimes severely) by File.Export, Directory.Export, and Container.Export, to the point of failing to "get" Dagger, and sometimes even giving up entirely.
I think we should consider the possibility of deprecating these functions.
The timing matters, because we are currently discussing a new CLI experience for Zenith (dagger call etc) which might rely on these export functions. So it seems important to discuss the future of these e...
By specifying the digest of images pulled by the core, we save network back-and-forth, which helps with performance especially on slow internet links.
Now that modules have constructors, we have a way to reduce the verbosity of calling them from the command-line: write module configuration to a config file.
Hi!
Thanks, first of all, to the creators of dagger. Really cool project 👏
Background
I have a short list of operations I would like my CI run to perform, for my Rust monorepo:
cargo clippy -p {{ function-name }} -- --deny warnings
cargo test -p {{ function-name }}
cargo deny --manifest-path "./functions/{{ function-name }}/Cargo.toml" check
cargo +nightly udeps -p {{ function-name }}
cargo audit
To try and make this reasonably efficient, I've first de...
The idea behind this PR is to attach the JSON representation of the underlying LLB to each vertex in the progress output. This data should be available to be ingested by the cloud service, so it can be used for better visualizations.
This piece is just the client-side part. To see an example, you can use _EXPERIMENTAL_DAGGER_PROGROCK_JOURNAL:
$ _EXPERIMENTAL_DAGGER_PROGROCK_JOURNAL=/tmp/progrock.json dagger call -m github.com/jedevc/daggerverse/hugo build --target git@github.com:...
Fixes #6289, and enables #6296.
As suggested in #6289, we create a new dagger.io/dagger/dag package which contains all the same methods that a client does. The client itself is constructed lazily behind the scenes on first access.
Opening since I've got something working, but I've also broken a few other things that need tidying up :tada:
This resolves CVE-2023-49568.
Noticed in a run of scan-engine: https://github.com/dagger/dagger/actions/runs/7349325989/job/20009051487?pr=6326:
...
{
"Target": "usr/local/bin/dagger-shim",
"Class": "lang-pkgs",
"Type": "gobinary",
"Vulnerabilities": [
{
"VulnerabilityID": "CVE-2023-49568",
"PkgName": "github.com/go-git/go-git/v5",
"InstalledVersion": "v5.9.0",
"FixedVersion": "5.11.0",
...
Related discord question: #1190052885686407179 message
Right now a module that has the same name as a core type (e.g. Module, Container, etc.) will eventually result in an error. This is not only due to conflicts in the SDK code (depending on the SDK language) but ultimately also on the graphql schema level.
At a bare minimum, we should error out in dagger mod init if a module has a name that will result in a conflict. T...
How to reproduce
go mod init github.com/samalba/sandbox/test
dagger mod init --name=test --sdk=go
Output
✘ generatedCode ERROR [0.57s]
✘ exec /usr/local/bin/codegen --module . --propagate-logs=true --introspection-json-path /schema.json ERROR [0.34s]
┃ Error: load package ".": err: exit status 1: stderr: go: go.mod requires go >= 1.21.5 (running go 1.21.3; GOTOOLCHAIN=local)
✘ generating go module: test ERROR [0.04s]
├ [0.00s] go mod tidy
┃ writ...
As discussed in https://github.com/dagger/dagger/pull/6165
I removed the Dagger\Dagger namespace and most of Dagger prefix in class names.
Should we keep DaggerScalar and DaggerId ?
Bumps pytest-httpx from 0.27.0 to 0.28.0.
Release notes
Sourced from pytest-httpx's releases.
0.28.0 (2023-12-21)
Changed
Requires httpx==0.26.*
Changelog
Sourced from pytest-httpx's changelog.
[0.28.0] - 2023-12-21
Changed
Requires httpx==0.26.*
Commits
0abf1eb Merge pull request #130 from Colin-b/develop
ef6fc63 Merge pull request #129 from Colin-b/feature/latest_httpx
7a611eb Merge remote-tracking branch 'origin/develop' into feature...
Bumps attrs from 23.1.0 to 23.2.0.
Commits
See full diff in compare view
Dependabot will resolve any conflicts with this PR as long a...
Bumps anyio from 4.1.0 to 4.2.0.
Release notes
Sourced from anyio's releases.
4.2.0
Add support for byte-based paths in connect_unix, create_unix_listeners, create_unix_datagram_socket, and create_connected_unix_datagram_socket. (PR by Lura Skye)
Enabled the Event and CapacityLimiter classes to be instantiated outside an event loop thread
Broadly improved/fixed the type annotations. Among other things, many functions and methods that take variadic...
Bumps pathspec from 0.11.2 to 0.12.1.
Release notes
Sourced from pathspec's releases.
v0.12.1
Release v0.12.1. See CHANGES.rst.
v0.12.0
Release v0.12.0. See CHANGES.rst.
Changelog
Sourced from pathspec's changelog.
0.12.1 (2023-12-10)
Bug fixes:
Issue #84_: PathSpec.match_file() returns None since 0.12.0.
.. _Issue #84: cpburnz/p...
[dagger/dagger] Pull request opened: #6335 chore(deps): bump mypy from 1.7.1 to 1.8.0 in /sdk/python
Bumps mypy from 1.7.1 to 1.8.0.
Changelog
Sourced from mypy's changelog.
Mypy Release Notes
Next release
Mypy 1.8
We’ve just uploaded mypy 1.8 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.
Type-checking Improvements
Do...
Bumps golang.org/x/oauth2 from 0.13.0 to 0.15.0.
Commits
6e9ec93 go.mod: update golang.org/x dependencies
e067960 go.mod: update golang.org/x dependencies
4c91c17 google: adds header to security considerations section
See full diff in compare view
[
Make timeout per-request (#1181), thanks to @Kern--
fix: rollback snapshot to prevent bolt deadlock (#1326), thanks to @goller
Protect node.ents and node.entsCached with a mutex (#13...
Bumps github.com/google/uuid from 1.4.0 to 1.5.0.
Release notes
Sourced from github.com/google/uuid's releases.
v1.5.0
1.5.0 (2023-12-12)
Features
Validate UUID without creating new UUID (#141) (9ee7366)
Changelog
Sourced from github.com/google/uuid's changelog.
1.5.0 (2023-12-12)
Features
Validate UUID without creating new UUID (#141) (9ee7366)
Commits
4d47f8e chore(master): release 1.5.0 (#145)
9ee7366 feat: Validate UUID without creating new ...
Bumps google.golang.org/grpc from 1.59.0 to 1.60.1.
Release notes
Sourced from google.golang.org/grpc's releases.
Release v1.60.1
Bug Fixes
server: fix two bugs that could lead to panics at shutdown when using NumStreamWorkers (experimental feature).
Release 1.60.0
Security
credentials/tls: if not set, set TLS MinVersion to 1.2 and CipherSuites according to supported suites not forbidden by RFC7540.
This is a behavior change to bring us into better ali...
Bumps github.com/charmbracelet/bubbles from 0.16.1 to 0.17.1.
Release notes
Sourced from github.com/charmbracelet/bubbles's releases.
v0.17.1
What's Changed
feat: upgrade bubbletea and remove deprecated code by @aymanbagabas in charmbracelet/bubbles#448
Full Changelog: https://github.com/charmbracelet/bubbles/compare/v0.17.0...v0.17.1
Thoughts? Questions? We love hearing from you. Feel free to reach out on Twitter, The Fediverse, or on Discor...
Bumps eslint from 8.52.0 to 8.56.0.
Release notes
Sourced from eslint's releases.
v8.56.0
Features
0dd9704 feat: Support custom severity when reporting unused disable directives (#17212) (Bryan Mishkin)
31a7e3f feat: fix no-restricted-properties false negatives with unknown objects (#17818) (Arka Pratim Chaudhuri)
Bug Fixes
7d5e5f6 fix: TypeError: fs.exists is not a function on read-only file system (#17846) (Francesco Trotta)
74739c8 fix: suggestion w...
Bumps prettier from 2.8.7 to 3.1.1.
Release notes
Sourced from prettier's releases.
3.1.1
🔗 Changelog
3.1.0
diff
🔗 Release note
3.0.3
🔗 Changelog
3.0.2
🔗 Changelog
3.0.1
🔗 Changelog
3.0.0
diff
🔗 Release note
3.0.0-alpha.6
What's Changed
Update .d.ts files of plugins to use export default ... by @fisker in prettier/prettier#14435
Other changes since v2, see 3.0.0-alpha.1 release notes
Full Changelog: https://github.com/prettier/prettier/compare/3.0....
Bumps typescript from 5.2.2 to 5.3.3.
Release notes
Sourced from typescript's releases.
TypeScript 5.3.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.3.0 (Beta).
fixed issues query for Typescript 5.3.1 (RC).
fixed issues query for Typescript 5.3.2 (Stable).
fixed issues query for Typescript 5.3.3 (Stable).
Downloads are available on:
NuGet package
...
Bumps eslint-config-prettier from 9.0.0 to 9.1.0.
Changelog
Sourced from eslint-config-prettier's changelog.
Version 9.1.0 (2023-12-02)
Added: [unicorn/template-indent], (as a [special rule][unicorn/template-indent-special]). Thanks to Gürgün Dayıoğlu (@gurgunday)!
Changed: All the [formatting rules that were deprecated in ESLint 8.53.0][deprecated-8.53.0] are now excluded if you set the ESLINT_CONFIG_PRETTIER_NO_DEPRECATED environment...
Bumps smallrye-graphql.version from 2.5.1 to 2.6.1.
Updates io.smallrye:smallrye-graphql-client-api from 2.5.1 to 2.6.1
Updates io.smallrye:smallrye-graphql-client-implementation-vertx from 2.5.1 to 2.6.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 org.assertj:assertj-core from 3.24.2 to 3.25.0.
Release notes
Sourced from org.assertj:assertj-core's releases.
v3.25.0
:jigsaw: Binary Compatibility
The release is binary compatible with the previous minor version.
:no_entry_sign: Deprecated
Core
Deprecate the following date/time related assertions in favor of isCloseTo:
isEqualToIgnoringHours
isEqualToIgnoringMinutes
isEqualToIgnoringSeconds
isEqualToIgnoringMillis
isEqualToIgnoringNanos
isInS...
Bumps org.mockito:mockito-core from 5.6.0 to 5.8.0.
Release notes
Sourced from org.mockito:mockito-core's releases.
v5.8.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.8.0
2023-12-01 - 15 commit(s) by Andreas Turban, Mikaël Francoeur, dependabot[bot], jfrantzius
#3000: fix ArrayIndexOutOfBoundsException (#3190)
Bump com.diffplug.spotless from 6.23.1 to 6.23.2 (#3188)
Bump com.diffplug.spotless...
Bumps de.m3y.maven:inject-maven-plugin from 1.4 to 1.5.
Release notes
Sourced from de.m3y.maven:inject-maven-plugin's releases.
1.5
This release migrates from previous javassist to bytebuddy for injecting byte-code.
Migrate from javassist to bytebuddy #148
Note: As a side effect, the plugin now also works with latest JDK 21
See release milestone for details.
Commits
77fa2a8 [maven-release-plugin] prepare release inject-maven-plugin-1...
cc @marcosnils as the last person to edit this file :eyes:
As far as I'm aware, this Dockerfile isn't actually used for anything? It's not used in our own internal/mage package, and it isn't referenced anywhere in our docs, I think this is legacy from before dagger was built in dagger? Also, since go 1.21, this dockerfile no longer even builds! (gotta love the best error message of all time invalid go version '1.21.5': must match format 1.23)
Additionally, the constants for go version...
Consolidates and replaces:
- https://github.com/dagger/dagger/pull/6340
- https://github.com/dagger/dagger/pull/6339
- https://github.com/dagger/dagger/pull/6338
- https://github.com/dagger/dagger/pull/6337
- https://github.com/dagger/dagger/pull/6336
These all look minor, would be surprised if this caused any breakages.
This patch updates the labels added to internal/mage PRs to include the area/ci tag (and not the area/tooling tag which no longer exists).
Additionally, we can remove the docker package, the only dockerfiles we have in-tree our docs/examples related (see also https://github.com/dagger/dagger/pull/6350).
That said, a cached run still takes ~18 seconds to execute, whereas just running the steps outside of dagger takes ~4 seconds.
that's quite strange. It definitely shouldn't take that much time. Were you able to spot which operation in your pipeline is the one that takes 18 seconds? I'd assume there's a misconfiguration somewhere that's causing the caching not to be kicking in accordingly.
This PR changes how services are stopped:
- Calls to
Service.Stopnow block until the service exits - Services are now stopped using
SIGTERMinstead ofSIGKILL
- This can be changed by setting the new
killoption totrue, which sendsSIGKILLinstead
- Services that are automatically cleaned up (e.g. client disconnection, all bindings are detached) are now gracefully stopped using
SIGTERM+SIGKILLafter a default 10 seconds has passed.
- This isn't really ideal reall...
From what I can see. It can be because there is a lot of data to be sent between the different docker contexts.
When you got the 4 sec time, was that just running pure cargo, or was it an image and then the commands?
It may also be because when you load the directory. It by default loads everything. I can see that it is used above, but you should be able to see it in the output how much it is loading it will say something like Transferring context (x Mbs)
It was pure cargo, yep 👍 No docker involved at all
This seems to be the same issue as upstream in buildkit: https://github.com/moby/buildkit/issues/2950 (cc @sipsma)
We've seen from a customer, as well as reported on discord: #1191805052378161192 message:
I've not seen the issue happening without a large amount of files being exported, so this might be related indeed
We should try and commit some debugging resources to trying to track down the deadlock upstream, so that we ...
[dagger/dagger] Pull request opened: #6356 fix(cmd/shim): fix panic when exec-ing an unknown command
Fixes https://github.com/dagger/dagger/issues/6266.
When an unknown command is executed, the returned error is *exec.Error.
Example code (Go playground: https://go.dev/play/p/ybni3fJpo46):
package main
import (
"log"
"os/exec"
)
func main() {
if err := exec.Command("foobar").Run(); err != nil {
log.Printf("%T: %+v", err, err)
}
if err := exec.Command("false").Run(); err != nil {
log.Printf("%T: %+v", err, err)
}
}
Output:
2009/11/...
As described in this comment, we want to add a -o flag for smartly redirecting output in dagger call.
This flag would be applicable for any return type and result in that result being written to the caller's filesystem rather than written to stdout.
For simple cases like a string return type, this would have the same end effect as a shell redirection. The difference is that we would allow some special...
https://github.com/dagger/dagger/pull/6293 exposed the core API in dagger call, which results in --help and dagger functions output to be pretty overwhelming and messy when dealing with core types like Container.
There's most likely going to be a lot of little things needed to address this, possibly including but not limited to:
- displaying multi-line doc strings better
- sorting of functions more cleanly
I think we should start out trying to do this purely from the CLI wit...
As described in this comment (and that issue generally), we need to make some adjustments to the CLIs behavior when dagger call ends in various core types.
There's a handful of related adjustments needed here. Creating as a checklist for now to save issue spam; can break down into more issues if useful though. I'm including my initial suggestions on how to handle these, but to be clear these are not finalized decisio...
Right now https://github.com/dagger/dagger/pull/6293 went with hiding id fields on types from the CLI because IDs are not generally safe to re-use across sessions.
However, https://github.com/dagger/dagger/pull/6297 will drastically improve the ID system and opens the possibility of allowing IDs to be re-used in some circumstances. We can thus consider whether to embrace that in the CLI and add some mechanism for getting the IDs of objects and re-use those.
To be clear, this isn't _su...
As described in this comment, we want to centralize call+shell+up to all be part of a common CLI command via exposing shell and up functionality as chainable APIs from Container/Service.
The original idea described there was to update the core API with "side-effect-only" APIs that result in the relevant behavior being triggered (similar to how export APIs work), e.g. as strawman starter ideas
- A `she...
Follow-up for previous PR that added a lot of this fairly intricate new codegen (https://github.com/dagger/dagger/pull/6254#issuecomment-1877837257)
I was a bit torn on whether to include as many concrete examples in the comments since it technically adds a small maintainance burden to keep the comments up to date whenever we change things.
However, in practice as working on this code I always ended up writing temporary throw-away comments like this (to help reason through the code to w...
hi. Hello everyone. I'm currently looking for a cicd tool that will suit my needs. I hope someone can give me some opinions.
My team currently uses Jenkins as the cicd tool, but you know what. Jenkins is not very convenient to use. In the past week, I spent a lot of effort getting jekins in docker and docker in jenkins running. Soon, I will have to write many, many scripts (or Makefiles) on it. It makes me miss the fun days of using Github Action.
I have been trying to replace jenki...
What is the issue?
I encounter errors when I run Kubernetes engine (k3s) inside a Dagger pipeline.
It works well with a previous version of Dagger (0.6.4).
It seems to be related to this issue : #5593 and with a potential fix https://github.com/moby/buildkit/pull/4308
I don't understand very well what this fix does.
Dagger version 0.9.5 uses the buildkit version github.com/moby/buildkit v0.13.0-beta1.0.20231107172747-c4f191410a41
So it is supposed to be fixed but I think I missed ...
Hello @cathaysia,
Before digging into the details, yes, you can easily execute your tests, build and run docker containers, manage artifacts, call APIs, etc... from a Dagger pipeline. You can then run this pipeline either locally from your machine or from Jenkins or from any infrastructure. Dagger Cloud can then allow you to visualize the running status (logs and errors) from a Web UI.
I would go over the following resources, in that order (relevant to the point...
Follow up to https://github.com/dagger/dagger/pull/6254
You can't yet use types from the core api like Container/Directory/etc. to implement a given interface due to some internal technical limitations that are better addressed after https://github.com/dagger/dagger/pull/6297 is merged
Follow-up to https://github.com/dagger/dagger/pull/6254
Right now there's a fairly annoying limitation in that in Go modules it's not possible to use an object you've defined in your module to implement an interface you've defined in your module.
This is due to the fact that interfaces are passed by ID by right now objects defined in a module are still passed by raw json in the context of themselves (some previous discussion with more context on why [here](https://github.com/dagger/dagg...
Right now in the (likely obscure) case where an object has a field/function defined that is the same with the namespaced as* field added for interfaces it implements, there will just be an error.
There's some discussion on better approaches here: https://github.com/dagger/dagger/pull/6254#discussion_r1441940034
Thank you very much, I will learn more about dagger from the material you provided。 :)
Hello @cathaysia,
Before digging into the details, yes, you can easily execute your tests, build and run docker containers, manage artifacts, call APIs, etc... from a Dagger pipeline. You can then run this pipeline either locally from your machine or from Jenkins or from any infrastructure. Dagger Cloud can then allow you to visualize the running status (logs and errors) from a Web UI.
I would go over the following resources, in that order (relevant to the point...
What is the issue?
This is coming from a Discord question here: https://discord.com/channels/707636530424053791/1193141267903815700
Answering my own question: It seems that the sdk defined in dagger.json is also just a module (great design choice). Hence, it is possible to fully customize the runtime container, where my-private-library is installed in, e.g.:
{
"name": "potato",
"sdk": "../sdk/python/my-custom-runtime",
"root": "../"
}
This way I can use a pre-built image that has all batteries included.
Answering my own question: It seems that the sdk defined in dagger.json is also just a module (great design choice). Hence, it is possible to fully customize the runtime container, where my-private-library is installed in, e.g.:
{
"name": "potato",
"sdk": "../sdk/python/my-custom-runtime",
"root": "../"
}
This way I can use a pre-built image that has all batteries included.
What is the issue?
When using Optional in a module field type (combined with constructors) Dagger yields the following error:
Error: query module objects: json: error calling MarshalJSON for type *dagger.Module: returned error 400 Bad Request: failed to get schema for module "ci": failed to create field: failed to get mod type for field "githubActor"
Dagger version
dagger v0.9.5 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
Create a module with optional f...
Yes, that's what I'd suggest for now, the problem I see with this is how do pass the secret value (for gitlab's token)? You'll have to cache that token into the runtime container in the my-cutom-runtime module as a normal env var or explicitly in the source code if you're using Dagger's native secrets. I'd suggest using an external secret store like infisical ([website](https://i...
Fixes https://github.com/dagger/dagger/issues/6369.
This is easier than attempting to handle this case, which would make the optional handling logic spill out to even more places (which I'd really like to avoid for now).
@sipsma @vito what do you think about removing the Optional type and relying entirely on // +optional for the RC? If we're going to break some things, feels like this is a good candidate.
Btw, have you already tried doing the custom runtime? Does it work? A few weeks back I tried it quickly and remember that there was a piece missing to make it work but don't remember what. So good feedback if you got it to work or not 🙂
Thank you for your insights. At the moment, I am in the process of exploring Dagger modules to ascertain their suitability for our needs and to identify areas where adjustments to my CX libraries may be necessary. My use case is that I have a Python library so that I can reuse code (I know that is kind of contrary to the modules approach) in my CX pipelines in multiple projects with the CX pipelines being Dagger modules. The question now is, how do I include my library from a private reposito...
Fixes DEV-2853.
This allows modules to also access ExecErrors, so they can analyze return codes, etc.
Sidenote: this adds to our little template collection. In light of the discussion around #6213 and trying to move more to jennifer where possible for our Go SDK codegen, I think the following divide makes sense:
- All "static" code can be defined in templates
- All "dynamic" code generated from the graphql introspection / typedefs s...
Diffs:
- https://github.com/opencontainers/runc/compare/v1.1.9...v1.1.11
- https://github.com/containerd/containerd/compare/v1.7.8...v1.7.11
I started by bumping conta...
Update
sdk/nodejs->sdk/typescript- All mentions of NodeJS SDK to Typescript SDK
- Generator, Mage and Runtime wording
- Docs reference
- Docs snippet tab went from
Node.jstoTypescript - Relative path and filenames.
- Release process (@jedevc I'll be with you for the next release because this PR might break things in our release)
Note
- I kept mention of a Node.js environment, since it's not related to the SDK but to the environment (or runtime) required ...
Currently, we are stuck on the current version of buildkit, since https://github.com/moby/buildkit/pull/4347#issuecomment-1872217571 seems to have introduced a deadlock.
To reproduce: update buildkit in go.mod to ca71a446d9f4e31ca7c4fa30fb8fb8861b8b0117, and run a large number of integration tests. The engine will lock up after some time - after sending SIGUIT to the engine, you can observe the stack trace:
goroutine 441 [sync.Mutex.Lock, 4 minutes]:
runtime.gopark(0xc01d5eb...
What are you trying to do?
While working on replacing a GHA workflow with pure Dagger (ie. no initial checkout step the GHA workflow), I noticed the directly pulling a commit from a ref not being fetched by default (ie. belonging to a PR: refs/pull/5/merge) fails.
This is quite understandable, but I had a hard time figuring out a workaround.
Here is what I tried:
source = dag.Git("https://github.com/openmeterio/benthos-openmeter.git", GitOpts{
KeepGitDir: true,
}).Co...
Fix #6375.
As suggested by @sagikazarmark, it feels odd to put refs/pull/5/merge and similar into a commit/branch/tag selection - it's a ref, so we should have a generic ref selection.
To handle the rust codegen case, we need to do some magic since ref is a strict keyword. We can resolve this using a raw identifier. @dagger/sdk-...
This mitigates GHSA-9763-4f94-gfch, and fixes the failing scan engine job on main: https://github.com/dagger/dagger/actions/runs/7460295076/job/20298322166#step:3:307.
github.com/cloudflare/circl is required by go-git:
$ go mod why -m github.com/cloudflare/circl
# github.com/cloudflare/circl
github.com/dagger/dagger/cmd/dagger
github.com/go-git/go-git/v5
github.com/ProtonMail/go-crypto/openpgp
github.com/ProtonMail/go-crypto/openpgp/internal/ecc
github.com/cloudflare/...
Somehow ImmutableRefs can be nil - not 100% sure how this happens, but upstream buildkit does include checks in appropriate places for this case. We should probably do the same as well.
What is the issue?
│ panic: runtime error: invalid memory address or nil pointer dereference │
│ [signal SIGSEGV: segmentation violation code=0x1 addr=0x98 pc=0x10cf51a] │
│ ...
Fixes I wrote while playing around with interfaces introduced in #6213.
Replace #6373 with a simpler set of changes that only concerns our codebase and Zenith documentation.
List of updates:
- Our GitHub Actions (/cc @gerhard)
- Our release doc (/cc @jedevc)
sdk/nodejs->sdk/typescript- Mage
sdk:nodejs->sdk:typescript - Our generator
- I created a label
sdk/typescripton GH
I also deleted the reference directory in current_docs, since these are generated files.
This PR should be way easier to review than the previous one si...
Just to let you know. One issue I encountered with the custom SDK is this:
49: exec /runtime
49: exec /runtime ERROR: secret core.Secret:eyJuYW1lIjoiQVJUSUZBQ1RPUllfVVNFUiJ9: not found
It occurs sporadically after a few runs of my pipeline, indicating a potential connection to caching. I will do further investigation.
This patch refactors the go codegen templates so as to allow a more template-centric approach, further improving upon the approach in #6326.
Essentially, the codegen now looks for every *.go.tmpl file in the templates directory and attempts to render it. This allows for easily adding new code-gen files, which will be useful for when we want to put the server API into a sub-package, i.e. dagger/dagger.gen.go.
The main change here is to rework the visiting, so instead of having the ca...
What is the issue?
Since SDKs are modules themselves, it is possible to use a custom SDK. In #6318, a custom SDK is used to install additional Python dependencies from a private repository, with the required credentials passed from a .env file. You can find an example at https://github.com/skycaptain/dagger/blob/python-sdk-runtime-with-env/sdk/python/runtime/main.go.
In this example, dag.SetSecret and ctr.WithSecretVariable are used to set the credentials before installing the P...
It has been a while. But here are some updates to some dependencies. The update to the version should also include some quite major improvements I didn't release in December. Such as better support for lifetimes in rust.
Also did some minor refactoring with the dependencies, and moved them and the versions to the main Cargo.toml, this should make it easier in the future to bump the version, as well as holistically update dependencies.
Remove the flaky test, as it turns out, if you're unauthenticated and trying to pull an invalid image, you can get rate limited. It is too much of a bother to actually setup authentication for this kind of a test, as such I am just removing it.
Fixes https://github.com/dagger/dagger/issues/6291
Very rough draft (been much trickier than I originally imagined), but got some manual tests of init/install/sync working so sending out a checkpoint.
TODOs:
- [ ] Update the existing integ tests
- [ ] Add test coverage for new cases
- [ ] Handle old dagger.json (at min error out w/ helpful message, maybe automatic update for simple cases)
- [ ] Double check that impact on daggerverse will be minimal
- From what I've look...
What is the issue?
When running dagger export --output , Dagger creates directory if it doesn’t already exist. However, it does so without respecting the configured umask: on my system, umask is set to 022, so permissions should be 755, but it’s actually 700.
Dagger version
dagger v0.9.5 (registry.dagger.io/engine) linux/amd64
Steps to reproduce
mkdir testcd !$dagger mod init --name test --sdk go
cat < main.go
package main
type Te...
Fixes a potential concurrency issue introduced in https://github.com/dagger/dagger/pull/6167 - it looks like during the lock refactors, we missed a couple cases.
In a past testdev run (https://github.com/dagger/dagger/actions/runs/7459047868/job/20294230186), the tests failed with:
fatal error: concurrent map read and map write
goroutine 569315 [running]:
github.com/dagger/dagger/core/schema.(*APIServer).ServeHTTP(0xc0197f3900, {0x1f9c9a0, 0xc0100aa460}, 0xc00eed5800)
/app/cor...
This commit reformats and updates the archiving instructions file.
This is one part of our efforts to consolidate dagger CLI commands. It removes dagger shell in favor of using a shell api chained from the core Container type.
For example, previously you'd do:
dagger shell my-ctr
Now you do:
dagger call my-ctr shell
This required some adjustments in the core API. Namely, shellEndpoint: String! is replaced with
shell(args: [String!]) InteractiveShell! on the Container type.
The new InteractiveShell type currently only has a fiel...
Bumps golang.org/x/sync from 0.5.0 to 0.6.0.
Commits
59c1ca1 errgroup: add reference to sync.WaitGroup
See full diff in compare view
Bumps golang.org/x/sync from 0.4.0 to 0.6.0.
Commits
59c1ca1 errgroup: add reference to sync.WaitGroup
10739b0 all: update go directive to 1.18
See full diff in compare view
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-de...
Bumps golang.org/x/tools from 0.15.0 to 0.16.1.
Commits
2acb2e6 gopls/internal/test/marker: minor clean up of marker test doc
28b92af internal/typeparams: eliminate remainining compatibility shims
ee35f8e gopls/internal/lsp/source: hovering over broken packages is not an error
67611a1 internal/typeparams: eliminate type aliases
23c86e8 internal/typeparams: delete const Enabled=true and simplify
e46688f gopls/internal/analysis/fillstruct: don't panic with i...
Bumps github.com/rs/zerolog from 1.30.0 to 1.31.0.
Commits
8344fc0 Bump actions/checkout from 3 to 4 (#588)
4cb8cc5 Update dependencies
ae9b265 Update Build Status Badge (#589)
1bac5cc added support for NO_COLOR (#586)
b81cc57 Fix the standard logger output example (#584)
ad77222 chore: improve coverage report
95cf29c chore: switch to go-goverage-report action as gocover.io is closing
802c88f chore: adding any function to context (#580)
158e4ad Update logben...
Bumps golang.org/x/crypto from 0.17.0 to 0.18.0.
Commits
dbb6ec1 ssh/test: skip tests on darwin that fail on the darwin-amd64-longtest LUCI bu...
403f699 ssh/test: avoid leaking a net.UnixConn in server.TryDialWithAddr
055043d go.mod: update golang.org/x dependencies
08396bb internal/poly1305: drop Go 1.12 compatibility
See full diff in compare view
[
Move documentation sources to site/content by @umarcor in spf13/cobra#1428
Add 'one required flag...
Bumps gql from 3.4.1 to 3.5.0.
Release notes
Sourced from gql's releases.
v3.5.0
IMPORTANT: graphql-core has been reverted to the stable versions 3.2.x
See #427
A new pre-release version will be made shortly with the graphql-core versions 3.3.x
New features
Add execute-timeout argument for gql-cli (#349)
Add HTTPX transport (#370)
Don't try to close the aiohttp session if connector_owner is False (#382)
Feature allow to set the content-type of file ...
Bumps smallrye-graphql.version from 2.6.1 to 2.7.0.
Updates io.smallrye:smallrye-graphql-client-api from 2.6.1 to 2.7.0
Updates io.smallrye:smallrye-graphql-client-implementation-vertx from 2.6.1 to 2.7.0
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 node-color-log from 10.0.2 to 11.0.0.
Commits
4a4f293 11.0.0
See full diff in compare view
Depend...
Bumps prettier from 2.8.7 to 3.1.1.
Release notes
Sourced from prettier's releases.
3.1.1
🔗 Changelog
3.1.0
diff
🔗 Release note
3.0.3
🔗 Changelog
3.0.2
🔗 Changelog
3.0.1
🔗 Changelog
3.0.0
diff
🔗 Release note
3.0.0-alpha.6
What's Changed
Update .d.ts files of plugins to use export default ... by @fisker in prettier/prettier#14435
Other changes since v2, see 3.0.0-alpha.1 release notes
Full Changelog: https://github.com/prettier/prettier/compare/3.0....
This PR merges in the full DagQL repository as a toplevel dagql/ subdirectory, keeping its history intact.
I know we usually do squashed commits for PRs but this feels like a bit of a special case where I'd prefer to keep the git blame since some of the commits have a lot of explanation. In total it's 99 commits which doesn't seem too crazy. I'll probably add another on top to remove the redundant LICENSE file, which would bring us to a pleasant :100:.
...
What is the issue?
Right now linkDependencyBlobs walks over an object's map[string]any and uses the object's field definitions to convert each any to a HasPBDefinitions so it can find blobs to link to the current session.
The problem is private fields don't actually have a field definition, so we don't know how to convert it to a HasPBDefinitions-able value.
Maybe we need to also register private fields, and just mark them private so they don't show up in the schema?
###...
This is one part of our efforts to consolidate dagger CLI commands, along side https://github.com/dagger/dagger/pull/6390. It removes dagger up in favor of using a up api chained from the core Service type.
For example, previously you'd do:
dagger up my-svc --port 8080:80 --port 2222:22
Now you do:
dagger call my-svc up --ports 8080:80 --ports 2222:22
or
dagger call my-svc up --native
or just
dagger call my-svc up (use any available local port)
This change seems...
Fixes https://github.com/dagger/dagger/issues/6312
Opening this purely to have a discussion right now, the changes amount to find+replace on the host name right now, but not even entirely yet (need to update tests, etc.)
Background
The name Host has become extremely confusing in the context of modules. So far, it seems that more often than not users very reasonably assume that in a module when they use dag.Host they are interacting with the original "host" where the module was ...
What are you trying to do?
I have a module with the following constructor:
func New(
// ...
// Disable mounting cache volumes.
disableCache Optional[bool],
// Module cache volume to mount at /go/pkg/mod.
modCache Optional[*CacheVolume],
// Build cache volume to mount at ~/.cache/go-build.
buildCache Optional[*CacheVolume],
) *Go {
// ...
}
Currently, running this module in the CLI fails due to CacheVolume being an unsupported CLI argument:
This PR was not auto-generated. The v0.9.6 publish job failed: #1193910832166342777 message. However, only nix failed, everything else succeeded - so I've just opened this PR manually to continue with the release (similar to as in https://github.com/dagger/dagger/pull/6309).
The nix issue seems related to branch protection, I suspect that dagger/nix has some branch protection that dagger/homebrew-tap doesn't have (the ...
Bumps golang.org/x/tools from 0.15.0 to 0.17.0.
Commits
0b1f1d4 gopls/internal/lsp/cache: (re-)ensure clean shutdown
706525d gopls/internal/lsp/source/completion: support postfix completion (iferr,
581c0b3 gopls/internal/lsp/source: add receiver name to stubbed methods
c95fa0f gopls/internal/test: skip marker tests on darwin builders if -short
25a0e9d go.mod: update golang.org/x dependencies
c9c95f9 internal/refactor/inline: improve a confusing error messa...
This avoids a possible credential leak, in case the user accidentally passes the env variable instead of its name. This is particularly likely because until very recently, that's exactly what we told users to do. So there is a real risk of leaks for early adopters, which this change mitigates.
What is the issue?
When creating a new module via dagger mod init or updating a module with dagger mod sync, under dagger CLI 0.9.6 I'm ending up with files like
python:
sdk/src/dagger/_engine/_version.py
# Code generated by dagger. DO NOT EDIT.
CLI_VERSION = "0.9.5"
typescript:
sdk/provisioning/default.ts
// Code generated by dagger. DO NOT EDIT.
export const CLI_VERSION = "0.9.5"
Dagger version
dagger v0.9.6 darwin and windows arm64
...
What are you trying to do?
Files passed to dagger call currently does not preserve the name of a file passed to it.
Why is this important to you?
Some tools often require the original file name (for example: Spectral requires the file name do determine the file type)
Discussed it with @sipsma here: #daggernauts message
How are you currently working around this?
I pass the original file name to the mod...
What is the issue?
After running the command dagger run go run xxx/main.go when it finishes, the mouse becomes useless.
This is annoying especially because you can't scroll and copy the output or any information in terminal after that.
Dagger version
dagger v0.9.6 (registry.dagger.io/engine) windows/amd64
Steps to reproduce
Use any terminal in windows terminal. Tested with Powershell but other shells affected
Log output
What is the issue?
Consider the following example
dag.container().from_("registry.dagger.io/engine:v0.9.6").with_exec(["apk", "add", "--no-cache", "nodejs"])
This example errors with:
218: exec dagger-entrypoint.sh apk add --no-cache nodejs npm
218: [0.06s] mkdir: can't create directory '/sys/fs/cgroup/init': Read-only file system
218: exec dagger-entrypoint.sh apk add --no-cache nodejs npm ERROR: process "dagger-entrypoint.sh apk add --no-cache nodej...
What happened? What did you expect to happen?
I timed out when executing CI after deploying to the server
connection timed out
Found this during the release of v0.9.6.
This step should always run - otherwise, it can accidentally cache, and we wouldn't run the rest of the pipeline, even when we would have new tags/branches/commits.
The "correct" solution long term is to ensure that we use the top-level client.Git method here - however, due to a weird upstream bug, we end up confusing tags and branches when cloning, which causes the filter-branch command we use to fail. (I'm following up with this upstream).
This behavior is explicitly disabled in buildkit - mounts only use slow content-based cache when both:
- The mount is not the root mount
- The mount is read-only
This is to avoid computing expensive content-based checksums. The root mount case often makes sense for us as well: I really struggle to imagine a scenario where caching this would be super useful. It w...
Just opening this PR for mostly minor things caught post-merge, will keep adding as they come up until it slows down.
So far:
- Automatically set description for deprecated args (https://github.com/dagger/dagger/pull/6297#discussion_r1452612145)
- Fixed
TypeDefinitioncomments (https://github.com/dagger/dagger/pull/6405#discussion_r1452508428)
Correctly load type argument prior to value to correctly serialize it.
Fix Quickstart issue found by @d3rp3tt3 (#daggernauts message).
➜ ci git:(main) ✗ dagger call hello-world --count 10 --mashed
✔ dagger call hello-world [2.34s]
┃ Hello world, I have mashed 10 potatoes
• Engine: c7de3eb13d57 (version de...
Before this, services provided as CLI flag values were not automatically started, so user module code needed to explicitly start them (or implicitly start them via a service binding), which is somewhat surprising and boilerplatey since there's not really any cases where a user wouldn't want the host service to already be running. This is debatable though.
Now, the CLI calls start on host services provided as flag args.
In order for this to work, there was also a change needed in the int...
What is the issue?
After upgrading to a new Dagger version, attempting to create a module fails on first attempt. The new engine container is downloaded and started, but command execution seems to "freeze". The only workaround is to cancel and reattempt the command and in this case it executes correctly and immediately.
Dagger version
dagger v0.9.6 (registry.dagger.io/engine) linux/amd64
Steps to reproduce
Initial setup:
Dagger 0.9.5 installed and 0.9.5 container running.
...
After upgrading to Docusaurus 3.x, various pages containing numbered lists have visual errors, where the numbering is reset on every list item. This is due to incorrect indentation, which seems to have been parsed less strictly in earlier versions of Docusaurus. commit fixes the indentation and consequent list numbering errors.
This PR implements handling of InputObjects in queries.
Added a unit test in ClientTest to demonstrate use of the PipelineLabel input object.
Note : Leaving as draft because I still need to rebase but noticed some breaking change after DagQL commits.
What is the issue?
Initially repoted by @matipan here: #daggernauts message
Given the current function
func (m *Foo) Nginx(ctx context.Context) error {
svc := dag.Container().
From("nginx").
WithExposedPort(80).
AsService()
tunnel, err := dag.Host().Tunnel(svc).Start(ctx)
if err != nil {
return err
}
defer tunnel.Stop(ctx)
endpoint, err := tunnel.Endpoint(ctx)
if err != nil {
r...
This commit improve the entrypoint registration:
- Use
reflect-metadatato register modules' class constructor.
This commit includes several changes around the runtime:
- Add a proxy entrypoint to execute dagger entrypoint as a sub-package.
- Install the TypeScript SDK in the project
package.jsonif required. - Update project
tsconfig.jsonif the paths alias is missing. - Add
src/index.tsif missing in the codebase. - Simplify template install
daggeras a sub package.
Al...
What is the issue?
ref: https://discord.com/channels/707636530424053791/1196918439185494116
We should add a note here that mounted or volume directores (and their contents) as well as files cannot be exported using the Export step. This is by design how
Hit a case where files weren't being deleted while working on dagger.json changes and thought I had completely lost my mind for a bit, but turns out it's just a bug that's existed since the beginning of time apparently 😮💨
I'm trying to understand how the dagger-shell command works with entrypoints. Consider the following example:
...
@function
def debug() -> dagger.Container:
return (
dag.container()
.from_("debian:bookworm")
.with_exec(["apt-get", "update"])
.with_exec(["apt-get", "install", "-y", "python3", "python3-venv"])
.with_exec(["python3", "-m", "venv", "/venv"])
.with_new_file(
"/usr/bin/local/entrypoint.sh",
...
This commit updates the register:
- Arguments order is send with the inputs args.
- Remove old argument order functions.
- Reorder arguments based on the given order.
This commit updates the entrypoint:
- Get the arguments order based on the scanner.
Add tests on that in both TypeScript SDK and integration tests.
Fixes DEV-3313
There's an issue in shell with reporting errors. So a failed execution of the entrypoint just exits without a proper non-zero return code and error message. In your case, you can debug manually with --entrypoint, which forces the command to use:
❯ dagger shell debug --entrypoint=bash
root@urjt6mj2624m0:/# /usr/bin/local/entrypoint.sh /bin/bash
/usr/bin/local/entrypoint.sh: line 2: !#/bin/sh: No such file or directory
root@urjt6mj2624m0:/# which sh
/usr/bin/sh
This exp...
For more information on this, check this article: Elegantly activating a virtualenv in a Dockerfile
Indeed, the command not returning an error misled me. I was finally able to get it to work. The error in the hashbang was just a typo when I wrote the ticket, nevertheless a good catch. There was another issue with the sourced script. Thanks for pointing me into the right direction and showing how to debug.
As for virtual environments, I'm aware of this approach. I only used it here as an example to simplify things, so I apologize for any confusion. There are other ecosystems, such as Yoct...
What is the issue?
I get the following error message when I try to install the Trivy integration:
❯ dagger mod install github.com/jpadams/daggerverse/trivy@21f9211e5727a0b6acce8a0ab6c35d01896dc642
✘ generatedCode ERROR [1.24s]
✘ exec /usr/local/bin/codegen --module . --propagate-logs=true --introspection-json-path /schema.json ERROR [0.64s]
┃ Error: generate code: template: module.go.tmpl:74:3: executing "_dagger.gen.go/module.go.tmpl" at : error calling ModuleMainSrc: cann
...
There's an issue in shell with reporting errors. So a failed execution of the entrypoint just exits without a proper non-zero return code and error message. In your case, you can debug manually with --entrypoint, which forces the command to use:
❯ dagger shell debug --entrypoint=bash
root@urjt6mj2624m0:/# /usr/bin/local/entrypoint.sh /bin/bash
/usr/bin/local/entrypoint.sh: line 2: !#/bin/sh: No such file or directory
root@urjt6mj2624m0:/# which sh
/usr/bin/sh
This exp...
This commit updates entrypoint loading by:
- Loading args type in constructor
This commit fixes argument loading by:
- Correctly serializing input and parentJSON
- Fixing loadArg to correctly supports list
- Fixing loadArg to load object with ID only
- Refactor load to avoid repetition
This commit fixes register by:
- Correctly assigning constructor if there's
Fixes DEV-3309
What are you trying to do?
Windows has a "package manager" called winget and the community can contribute to add new packages to the official repository.
This will be an alternative to the current script installation. I created the initial package and the PR can be found here: https://github.com/microsoft/winget-pkgs/pull/135188
There's an automated workflow that can be created in order to update...
Questions around how to write progress directly from module code come up fairly often. Right now all modules can do is write to stdout+stderr and it will show up in the progress output in the same way other exec output shows up. Very barebones.
Various problems that have been raised w/ the current situation:
- Can't differentiate between debug + normal + error logs. You just write every log or no log.
- In theory you could make the "log level" of your function a parameter, but that c...
Problem
When the Dagger Engine loads a module and serves its API, that API is 1) the module's functions and types, mixed with 2) the engine's core functions and types. This makes the resulting API noisy and difficult to explore, because the core API is huge and drowns out the rest.
Solution
- Only expose the module's functions and types in its API.
- If we want to support calling core functions from the CLI, expose the core API as a module that can be loaded the usual way: ...
This PR implements handling of InputObjects in queries.
Added a unit test in ClientTest to demonstrate use of the PipelineLabel input object.
I split this off a larger WIP PR for adding a bunch more tests to Python modules.
There was a regression when adding constructor support where function descriptions from docstrings were no longer being registered. Noticed on dagger call --help.
Note: First commit is just moving tests over to dedicated file.
A couple small issues potentially introduced by https://github.com/dagger/dagger/pull/6253 (cc @grouville @marcosnils)
So, prior to this PR, we didn't perform any network operations when starting a dagger session. However, after this, we start doing git operations. My worry is that this has introduced subtle bugs with how this works.
Firstly, we could get a potential timeout after 30s if the git operation takes longer than 30s (can't find a CI example off the top of my head, but ...
It was previously possible for stderr to still be being written to while we try and get the logs for it.
This was already only possible in error-cases, but it does make the logs a lot more confusing when it happens.
What are you trying to do?
I started looking into Dagger after I saw it on one DevOps Engineers's video in Youtube. I liked the idea: juggling containers, which are supposed to be the same everywhere: cloud, CI runners, localhost, server, etc. And so I started playing with it and I've been playing with it for a few days now. Here is my feedback
- The Good
- Everything is in containers. This allows me to have complete control over what's happening where
- Programming language sup...
See https://github.com/moby/buildkit/commit/329e945c254cde7144b9300e00dee26d232657ad.
Thinking out loud, mostly curious to see what CI does.
These are the necessary changes for the Zenith visualization experiments I've been working on. I figure we can sneak these out even if we don't have anything that uses them yet, just to have the ability to record a journal file and test the new UI/TUI against it.
The only real change is that Progrock now supports parent/child vertex relationships, which are analogous to parent/child spans in OpenTelemetry. The DagQL telemetry now uses this instead of the weird group-that's-really-a-vertex ...
- Add integration tests for constructors
Additional notes
- Remove inline Eslint nolint instruction in favor of file's scope instruction
- Fixes an issue with
loadArgwhenvalueisundefinied.
Fixes DEV-3323
Fixes DEV-3324
This reverts #6428 :cry:
Since updating, we've seen increased CI failures from:
- Lots of timeouts while running tests, with gaps in the logs that may indicate a potential deadlock
- https://github.com/dagger/dagger/issues/6452 (though this mayy be unrelated)
I'll investigate, and follow-up/
This PR was auto-generated.
What is the issue?
Seems like Dagger is always transferring files to the build context even if they are cached.
Dagger version
v0.9.6
Steps to reproduce
given the following pipeline where bar is a very large file:
_, err = client.Container().From("alpine").WithMountedFile("/tmp/image", client.Host().File("bar")).
WithExec([]string{"ls", "-la", "/tmp/"}).Sync(ctx)
if err != nil {
return err
}
first time the pipeline runs I get the following out...
It seems like https://github.com/dagger/dagger/actions/runs/7586336084/job/20664474209 was broken, due to changes in https://github.com/dagger/dagger/pull/6433/files#diff-dd39eea8d6cc5b9f8f7a2c9645c31136dbef40ad6f79b5d3860fac8bbae44ce9.
See https://docs.npmjs.com/cli/v10/commands/npm-publish#files-included-in-package for more info.
Create documentation around configuring the Dagger engine. Topics such as garbage collection parameters.
Add to Operator Manual
What is the issue?
The core Platform type is converted to string when using a module that references that type.
Dagger version
dagger v0.9.6 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
No response
Log output
No response
Javascript projects were broken because typescript became a required import from 0.9.6 with scan.js importing it.
Currently, if you try to run a JS project, you'll get the following error:
┃ node:internal/modules/esm/resolve:844
┃ throw new ERR_MODULE_NOT_FOUND(packageName, fileURLToPath(ba...
Bumps prettier from 2.8.7 to 3.2.4.
Release notes
Sourced from prettier's releases.
3.2.4
Fix .eslintrc.json format #15947
🔗 Changelog
3.2.3
Format tsconfig.json file with jsonc parser #15927
🔗 Changelog
3.2.2
🔗 Changelog
3.2.1
🔗 Changelog
3.2.0
diff
🔗 Release note
3.1.1
🔗 Changelog
3.1.0
diff
🔗 Release note
3.0.3
🔗 Changelog
3.0.2
🔗 Changelog
3.0.1
🔗 Changelog
3.0.0
diff
🔗 Release note
3.0.0-alpha.6
What's Changed
Update .d.ts files of plugins t...
Currently based on top of https://github.com/dagger/dagger/pull/6386, 3 most recent commits are unique
Goals:
- Add engine version module was most recently updated with to dagger.json for the purposes of tracking as metadata
- Currently updates on
dagger mod init/install/sync - This also opesn up a path to serving modules compatible schemas based on their version
- This PR doesn't include the all the internal functionality for doing so, but in the future if we make backwa...
- Currently updates on
What are you trying to do?
File preserves it's name when mounted to a directory like this:
dag.Directory().WithFile("", file)
It doesn't always make sense to accept a file name when it's being created though.
For example, when building a binary, I may not care about the file name in 99%, so adding an optional name parameter just makes the API more complex with little benefit:
dag.Go().WithSource(dir).Build(GoWithSourceBuildOpts{Name: "mybinary"})
...
What are you trying to do?
I find myself writing code like this lately:
dir := dag.Directory()
for _, file := range files {
dir = dir.WithFile("", file)
}
I'd like to see a shorthand where I can easily add a list of files to a directory:
dir := dag.Directory().WithFiles(files...) // OR: WithFiles(files)
Why is this important to you?
When using CLI tools (or even in Dockerfiles) files and directories are usually described by a path without h...
What are you trying to do?
When working with build results and generating final build artifacts (packages), I often need to create directories and merge them.
In theory, this works using the following:
dag.Directory().WithDirectory("", dag.Directory())
I'm not entirely sure it always merges directories though.
In any case, a function called Merge would reflect better what it does (similarly to Diff)
Why is this important to you?
No response
How are ...
This change ensures that a non-null enumerable value always results in [] rather than null in the response. This changed with v0.9.7, affecting Module.dependencyConfig among other things.
Opening as draft to start discussion while I work on proposed solution in parallel, only change so far are some new tests that exemplify the problem (and commits from the dagger.json updates PR, which this will be based on).
Related to:
- https://github.com/dagger/dagger/issues/6328
- https://github.com/dagger/dagger/issues/6438
- https://github.com/dagger/dagger/issues/6071
The need for better handling of corner case conflicts between a module's objects and dependencies/core has b...
We should avoid holding the server map lock for any long period of time. This should help to prevent a total deadlock in the case where a rogue server holds the lock for too long during shutdown (for currently unknown reasons).
By reducing our usage of the global map lock to only simple operations that won't block, we ensure that this rogue server doesn't block every operation on the controller.
However, because of this refactor, we need to introduce a more precise per-server-id lock. T...
Hello,
I'm considering using dagger inside a Jenkinsfile. We use the Jenkinsfile to define different stages, some of them running in parallel. To integrate dagger, we could call 'dagger run python tests.py', 'dagger run python checks.py', etc in different Jenkins stages.
Does the dagger engine support this?
Thanks in advance
Yup, you should definitely be able to do this :tada:
If you are targeting each stage at the same dagger engine, then the builds will all get done in parallel - additionally, any common items of work between each of the stages, should get deduplicated, so nothing should get done twice :tada:
Fixes #6374.
[!NOTE]
Likely depends on #6479 for... reasons.Somehow, upgrading buildkit last time in https://github.com/dagger/dagger/pull/6428 let to bizarre deadlocks, in which we would hang on shutting down a progrock grpc server - this stalled the entire engine (which it shouldn't do). Still not quite sure why we were hanging on shutting down the progrock grpc server though.
...
Fixes #6359
TODO
- [ ] Tests
- [ ] Arbitrary user objects
What is the issue?
I'm Starting to learn about modules from here:
https://docs.dagger.io/zenith/user/quickstart/120928/setup
but ran into error:
Error: failed to get loaded module ID: input: resolve: host: directory: asModule: failed to call module "example" to get functions: call constructor: process "go build -o /runtime ." did not complete successfully: exit code: 1
when running dagger functions command.
I expected to see something like this:
✔...
We had a Module.description field in the schema but no way of populating it. Rather than make the main object's description the module description, we can cleanly separate those two in the SDKs. The consumer can, for example, default to the main object's description if there's no module description.
Still needs tests, and only Python sets the field for now.
Having issues with elixir and php codegen.
\cc @grouville @jpadams
- Move Typescript related tests into its own files.
- Add
TestModuleTypescriptSignaturesBuildinTypescase
Additional notes
- Fix an issue with variadic arguments not correctly forwarded
💡 This is the final PR related to Typescript Tests.
Fixes DEV-3310
Fixes DEV-3147
Problem
We haven't conclusively answered the question: "what is the best way to scale Dagger in production?". This is in part because there is a wide variety of requirements and preferences, depending on the use case and constraints.
So far there are 2 competing approaches: horizontal scaling and vertical scaling. We have not conclusively decided which one is better, and why.
Solution
Using our collective experience running Dagger in production since the cloak release (0...
This replaces https://github.com/dagger/dagger/pull/6153
The OpenShift GitLab guide has been adapted to the new documentation structure.
Use dagger secrets for concealing secrets in SDK publish steps.
These were added in https://github.com/dagger/dagger/commit/e4e5fa65ac5ebc0ed58b92f6cd9d29156a63e132.
opened, synchronize and reopened make sense to me - these are all cases when changes are made to the PR (and re-opened is quite rare, but given that main may have moved on since then, it can be useful to re-run).
However, ready_for_review often doesn't mean any actual changes to the content of the PR, and happens much more frequently, so it makes sense to skip this.
Follow up to #6447 as I've noticed PHP and Elixir generated files still show in diffs.
Tested with linguist:
Follow-up to #6463 (and related to #6488)
This PR introduces DRY_RUN to all SDK publish mage jobs, allowing any of them to be run and tested locally.
- Adds
DRY_RUNto python, go, typescript and php - Renames
HEX_DRY_RUNtoDRY_RUNfor elixir - Renames
CARGO_PUBLISH_DRYRUNtoDRY_RUNfor rust - Renames
MVN_DEPLOY_DRY_RUNtoDRY_RUNfor java
The idea is to prevent issues like #6464 from appearing only during the release process, and instead to show up as soon as possi...
[!NOTE]
This is an experimental PR which may not end up inmain. It was created from a branch so it has access to secrets. The new workflow is restricted to only run on thedagger/daggerrepository.
The goal is for us to better understand where our workflows spend time before Dagger gets invoked.
Jobs may be queued for longer than normal, steps which run before or after Dagger may be problematic, etc.
Without this, it's very difficult to know where our workflows as a whole s...
I have a pipeline with multiple Services and Containers being passed around. If a Container that has a dependent service is Sync()'ed, future calls to the Service will fail with something like:
lookup 5r4dg8qetp2iq.r4mh9kocl49fi.dagger.local on 10.87.0.1:53: no such host
psuedocode example:
foo := dag.Container().From("postgres").AsService()
bar := dag.Container().From("asdf").WithServiceBinding("db", foo).WithExec(["some", "commands])
_, err := bar.Sync()
baz := ...
Before this, if there was an error when synchronously importing layer cache at engine start, the engine failed to start entirely. Now, the engine will continue running with just the local cache and retry import periodically in the background.
Additionally, that initial synchronous import did not have a timeout previously. It now has a timeout of 1 minute. If that's hit, then the above logic kicks in to gracefully handle the error.
:scream: we're still seeing the weird deadlocks from the buildkit upgrade, even after pulling in https://github.com/dagger/dagger/pull/6479 (it looks like other non-blocked tests keep running now, but the blocked tests are still an issue).
This PR tries to dump a ton more information in these scenarios.
The weird sleep and "docker exec" to send SIGQUIT should be removed once the source of the deadlock is resolved, since it's very very hacky, but should work to at least grab some inf...
While reviewing the upcoming version documentation, I noticed that the CLI installed through other installation methods, except homebrew, was outdated.
This prevented me (I use Linux and the curl method) from progressing through the following sections in the quickstart, such as this one failing due to the missing functions command.
I bumped the docs to point to 0.9.7, which seems to be the latest release, also reference...
Moved .gitattributes to root of SDK for visibility. Removed its generation from codegen because at the time it was added, it was supposed to be run by users. With Zenith however, that's handled for you.
It's the deadlock that keeps on giving :tada:
- Bumped up some log levels from
tracetodebugto hopefully provide some more useful info - Fix the really annoying
level=error msg="session call failed" ... error="wait: handleConn: %!w()". We should only wrap withfmt.Errorfif we actually got an error.
What is the issue?
This link is broken, gets redirected to https://docs.dagger.io/zenith/, which just shows the root documentation.
I have also tried searching for zenith in the website and nothing shows up at all. It is actually pretty hard to find out what zenith is, it's very confusing seeing so many issues with a zenith label and having no clear way of reading about it.
What is the issue?
This issue is only on main; the current release, v0.9.7, is not affected.
If you run a pipeline with a vertex that is used multiple times in the same session, the log output will be duplicated, possibly with each extra use (i.e. cache hit).
Dagger version
main
Steps to reproduce
Once #6456 is merged, run a function that calls another function twice; you should see duplicate logs in its codegen vertex.
Log output
main:
. We were using it for pretty much everything.
Since ...
Resolves https://github.com/dagger/dagger/pull/6405#discussion_r1466186701.
This has been replaced with the dagql cachemap during migration.
Luckily, nothing was using the old cachemap impl, so it just needs to be removed!
As discussed this morning :tada:
We can have a dedicated starting engine step, which will connect to the engine, start a session, and immediately disconnect.
If the engine isn't already started, this starts it! In the future, we can use honeycomb and more quickly identify issues with too many cache volumes, etc.
This is only for next release to help users transition. Should be removed at the latest on the official modules release.
When using one of the removed commands:
- dagger download
- dagger shell
- dagger up
User is presented with an error message referencing the new one, under dagger call.
What is the issue?
with_exec's stdin parameter enables writing content to the command's standard input before it closes. However, if you switch to another user, it breaks without any notification, preventing the command from executing.
Dagger version
dagger v0.9.7 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
This works:
import anyio
import dagger
from dagger import dag
async def main():
async with dagger.connection():
out ...
Previously, 0o600 was to narrow to allow non-root users to use withExec with stdin. The command silently exited without being executed.
Fixes #6510
What happened? What did you expect to happen?
No response
This is the current output I'm getting when doing a dagger functions
This is different from https://github.com/dagger/dagger/issues/3577, which is about figuring out a DX for doing this in the SDKs.
Python’s query builder is from a third-party library, and supports everything from GraphQL. The one in Go is a custom solution, built entirely for our chainable API. Because of this and the issue above, it doesn’t support sibling selection. You can only select one field from an object.
However, dropping down to the query builder lever can unblock certain use ...
Following #6359, if the last argument in dagger call is an object type, print the object’s fields instead of returning an error.
As a prerequisite, we need:
Because of core chaining in dagger call --help:
The inconsistency in documenting the API is really noticeable. Since we want to list a short description next to commands and flags in the CLI, I suggest we apply a convention of writing the most concise short description in the first line, a blank line, and a more elaborate description.
Prior art
Many languages use this simple convention for docstrings (for example, [Python](https:/...
Background
With https://github.com/dagger/dagger/issues/6359, If the last argument in dagger call is a Container, Directory, or File, the sync field is selected automatically, while the returned ID is ignored (not printed to screen). You can, however, select sync explicitly, in which case the ID is printed.
Motivation
For consistency, we want to just do the forced evaluation, without printing the returned ID to the user because there’s no meaning in this context. Ho...
Prior to this PR, attempting to run a module that takes a CacheVolume in its constructor (or likely also any function) would fail with this:
Error: unsupported object type "CacheVolume" for flag: mod-cache
The flag value is just the cache volume name. Can't think of an immediate reason for it to be any more complicated than that.
- [ ] test
We should avoid calling Parallel in a sub-test after creating a client, since it can block for a completely indeterminate amount of time, and in that time, we can end up with a huge number of just unused clients.
Not only is this (really only a) little wasteful, it makes stack traces and dumps in the case of test timeout very hard to decipher. Are we waiting for a client because it got deadlocked? Or because it was open since the beginning of the test run.
We do this in two ways:
- M...
Adds a new dev module for the Typescript SDK.
Adds the reference node module.
Fixes tsconfig updator relative path to point to the correct one.
Fixes DEV-3308
Fixes DEV-3345
Related to DEV-3352
I think the command has to come after the -m flag. When it comes before dagger can't find the module... most other places (for instance in the bottom tip) the command is after the module flag.
This is a tiny update, but it cost me at least 10 minutes before I found another example with them flipped and then mine started working locally. Hope it saves someone else a few minutes!
Diff:
Lots of interesting potential fixes for some of the recent buildkit instability from deadlocks:
There's a few scarier changes in there, but nothing I'm overly worried about.
cc @sipsma
Bumps follow-redirects from 1.15.3 to 1.15.5.
Commits
b1677ce Release version 1.15.5 of the npm package.
d8914f7 Preserve fragment in responseUrl.
6585820 Release version 1.15.4 of the npm package.
7a6567e Disallow bracketed hostnames.
05629af Prefer native URL instead of deprecated url.parse.
1cba8e8 Prefer native URL instead of legacy url.resolve.
72bc2a4 Simplify _processResponse error handling.
3d42aec Add bracket tests.
bcbb096 Do...
Bumps h2 from 0.3.22 to 0.3.24.
Release notes
Sourced from h2's releases.
v0.3.24
Fixed
Limit error resets for misbehaving connections.
v0.3.23
What's Changed
cherry-pick fix: streams awaiting capacity lockout in hyperium/h2#734
Changelog
Sourced from h2's changelog.
0.3.24 (January 17, 2024)
Limit error resets for misbehaving connections.
0.3.23 (January 10, 2024)
Backport fix from 0.4.1 for stream capacity assignment.
Commits
7243ab5 Prepa...
Bumps com.jayway.jsonpath:json-path from 2.8.0 to 2.9.0.
Release notes
Sourced from com.jayway.jsonpath:json-path's releases.
json-path-2.9.0
What's Changed
Fix for CVE-2023-51074.
update dependencies by @SingingBush in json-path/JsonPath#965
JPMS: define Automatic-Module-Name as json.path by @SingingBush in json-path/JsonPath#966
Bump json-smart version from 2.4.10 to 2.5.0 by @shoothzj in json-path/JsonPath#945
Fixed rendering error on $..book[?(@...
Bumps aiohttp from 3.9.1 to 3.9.2.
Release notes
Sourced from aiohttp's releases.
3.9.2
Bug fixes
Fixed server-side websocket connection leak.
Related issues and pull requests on GitHub:
#7978.
Fixed web.FileResponse doing blocking I/O in the event loop.
Related issues and pull requests on GitHub:
#8012.
Fixed double compress when compression enabled and compressed file exists in server file responses.
Related issues and pull requests on GitHub:
...
Typescript introspector now check for top level comment in the main object file.
Add unit tests and integrations tests.
Fixes DEV-3344
I was trying to understand what all these do, and spent way too long on it. Just added some inline docs by cross-referencing how they work in buildkit and in dagger cloud.
There were a few uses of nolint where we didn't need them - it's often difficult to discern their intended purpose when cleaning them up later, so we should enforce them as soon as they aren't required.
What is the issue?
Mostly what the title says. The error message I get from putting the Context in the wrong place is cryptic.
Dagger version
dagger v0.9.7
Steps to reproduce
Create any Zenith module function and put the context.Context in any location but the first parameter.
Log output
Error: failed to automate vcs: failed to get vcs ignored paths: input: resolve: module: withSource: failed to get modified source directory for go module sdk codeg...
This implements a bare minimum subset of the polish described here and discussed separately: https://github.com/dagger/dagger/issues/6291#issuecomment-1911592394
Specifically, it's mainly just the stuff that's backwards incompatible, with the addition of dagger update since it was trivial to support and needed as a follow-up to https://github.com/dagger/dagger/pull/6386
syncis renamed todevelopdagger updatecan be used to set name+sdk of module- currently only allow...
The most important updates here are in anticipation of breaking changes in the next release. There are also some more opinionated cleanups, but for now just leaving the overall structure the same.
The big breaking changes to adapt for are:
dagger mod init/install/etc.moving to be right underdaggerdagger upreplaced by chainabledagger call ... updag.Host()being replaced withdag.CurrentModule().Source()
The more opinionated tweaks are:
- Don't use raw grap...
The new dag.CurrentModule() API replaces the need for the Host API and gives more controlled functionality that is specific to modules.
Fixes https://github.com/dagger/dagger/issues/6312
More details on the new API in this PR description (specifically CurrentModule API).
TODO:
- [ ] Update release notes with details on breaking change
https://github.com/dagger/dagger/pull/6520 added a new // nolint comment, and it seems like CI didn't rerun after #6531 was merged.
What is the issue?
Elixir SDK CLI downloader's :os.type() pattern matching expects {:windows, :nt} but is actually {:win32, :nt} as documented in Erlang.
Erlang/OTP 26 [erts-14.2.1] [source] [64-bit] [smp:24:24] [ds:24:24:10] [async-threads:1] [jit:ns]
Interactive Elixir (1.16.0) - pres...
Turns out this is still needed by legacy Dagger (dagger run, go run + auto-started dagger session, etc).
It's unfortunate to bring all this plumbing back but we obviously can't break that yet.
Kept everything as-is, including propagating parents, because #6505 prevents the cache-busting issue that we originally ripped all this out to avoid.
This reverts commit 3309a8e799e1f4d66506bdc5e540613ae4bab90a.
Refs V2 lite
Allows releasing modules individually in a monorepo with subpath tags, e.g. "github.com/foo/daggerverse/proxy" can be tagged with proxy/v1.0.0 and installed with dagger mod install github.com/foo/daggerverse/proxy@v1.0.0.
This does not affect non-monorepo module tags or repo-wide tags in monorepos.
This does not add any advanced version matching logic, but takes a step towards enabling that.
https://linear.app/dagger/issue/DEV-3338/simplest-possible-refs-v2-impl...
Since Subpath always starts with /, and its default value is /, we're currently always adding an extra / between the source path and the subpath. (Amusingly it looks a lot like v2 refs #6187.)
Our vulnerability scans started failing due to the CVE in v1.1.11, this updates to the latest release.
The recent updates accidentally left in dag.Select calls that referred to old APIs in the codepath for custom (i.e. 3rd party) SDKs. We didn't catch this because we didn't have any integ tests for this feature.
This fixes the bug and adds an integ test. It also required exposing Module.Runtime as a graphql field in order to write the test case, but that seems like it will only be beneficial in general to any other SDK authors trying to do something similar to this.
These are worth mentioning in the release notes I think since a decent chunk of users will be impacted (though not the majority). I kept the breaking change log itself short but updated the PR it links to with a Description that details the steps for updating if impacted: https://github.com/dagger/dagger/pull/6386
Addresses:
Pending https://github.com/dagger/dagger/pull/6262/, this commit updates the current Zenith quickstart to use the new dagger call syntax.
Fixes #6358
Not all of these are focused on the core API, most impactful is the wrapping on flags and commands. I’m submitting what I have now to be cut in next release but will continue in a separate PR for general --help improvements.
Putting individual improvements in separate commits.
Todo
- [x] Group commands in
daggerroot (modules, execution, cloud, additional) - [x] Group function commands in
dagger call - [x] Wrapping on flag usages
- [x] Wrapping on available...
This commit adds FAQ entries/a guide for Dagger telemetry.
Note: For zenith version docs, all the relevant information is placed in the FAQ since we don't yet have a "Guides" section for that version (will be added in #6504)
Fixes #6532 :tada:
We should explicitly check for weird contexts, instead of just charging ahead and panicking.
Also, while I was in the area, I threw in an explicit failure for foreign types (since we don't currently have anything for https://github.com/dagger/dagger/pull/6185). The code generated was completely invalid, so better to fail early with a good error message.
When we had an issue with https://github.com/dagger/dagger/pull/6488, the only thing saving us was github censoring it's own token in the logs.
We didn't pick up on this, because the printed token was base64 encoded.
Our new secret censoring mechanism https://github.com/dagger/dagger/pull/6034 should ideally handle this - we should try and filter our base64/hex/etc encoded versions of secrets (though for base64 this may be tricky(er), since it's not perfectly byte-aligned).
Also *sor...
What are you trying to do?
Currently, once a service starts, there's not a ton of interaction points for it. We can stop it... and that's about it.
One key thing I'd like is access to the stdout/stderr of a service. At the moment, these are exclusively streamed to the progrock output, but it would be nice to be able to output them somewhere else.
[!NOTE]
In addition to this, I'd really like to have a way to suppress the default progrock service output. These in combinati...
What are you trying to do?
Whenever the engine is provisioned within a container - default strategy by the SDK's - as highlighted in the operator's manual here (https://github.com/dagger/dagger/blob/main/core/docs/d7yxc-operator_manual.md#execution-requirements), it's imperative to set /var/lib/dagger as a volume so it doesn't form part of the overlayfs of the container. Otherwise, this will have a severe performance penalty when running pipelines.
We should raise a warning if we d...
Fixes: #6475
The issue mentioned only Directory, but I also added it to Container, not sure that was a good idea. Also, this is my first contribution so I might be missing a few things.
With regards to the sdk changelog, it seems like that is something I should do after creating the PR? go through every sdk and run it?
Also a question: in Directory WithFiles, I wasn't sure whether or not I should have re-used WithFile, some feedback on that would be great :)
This PR was auto-generated.
This is a big change but let me explain to catch up easier.
Codegen move out from the SDK
Previously, the dagger codegen was embedded in the SDK, this caused a problem in that it could not be run when the codegen generated a bad code. In this change, introduces a new Elixir module called dagger_codegen which's responsible for generating code and uses the escript to build a binary instead of the mix task.
The way to fetch introspection is now split out of the codegen. This way...
This removes our smuggling hack where we smuggle properties through existing ones - we no longer need to do this, since we can create a custom identifier that wraps the upstream ones. (Hope it's ok I took your TODOs @vito :laughing:)
This is hopefully part 1 of several to try and clean up our custom sources - I'd love to be able to remove most of the copy-pasta code from buildkit, to avoid future drift (as I noticed in https://github.com/dagger/dagger/pull/6376#issuecomment-1919427939).
Given a very simple go module:
package main
type Playground struct{}
func (m *Playground) Alpine() *Container {
return dag.Container().From("alpine:latest")
}
Using dagger call without a sub-selection works as expected:
❯ dagger call alpine
✔ dagger call alpine [2.19s]
┃ Container evaluated. Use "dagger call alpine --help" to see available sub-commands.
• Engine: e254c39a3421 (version de...
Bumps pytest-httpx from 0.28.0 to 0.29.0.
Release notes
Sourced from pytest-httpx's releases.
0.29.0 (2024-01-29)
Added
Add support for pytest==8.* (pytest==7.* is still supported for now). (many thanks to Yossi Rozantsev)
Changelog
Sourced from pytest-httpx's changelog.
[0.29.0] - 2024-01-29
Added
Add support for pytest==8.* (pytest==7.* is still supported for now). (many thanks to Yossi Rozantsev)
Commits
fcb442a Merge pull request ...
Bumps urllib3 from 2.1.0 to 2.2.0.
Release notes
Sourced from urllib3's releases.
2.2.0
🖥️ urllib3 now works in the browser
:tada: This release adds experimental support for using urllib3 in the browser with Pyodide! :tada:
Thanks to Joe Marshall (@joemarshall) for contributing this feature. This change was possible thanks to work done in urllib3 v2.0 to detach our API from http.client. Please report all bugs to the urllib3 issue tracker.
🚀 urllib3 is ...
Bumps com.spotify.fmt:fmt-maven-plugin from 2.21.1 to 2.22.1.
Release notes
Sourced from com.spotify.fmt:fmt-maven-plugin's releases.
2.22.1
There are no changes in this release and it was done purely for verifying problems with our release process.
Full Changelog: https://github.com/spotify/fmt-maven-plugin/compare/2.22.0...2.22.1
2.22.0
What's Changed
This upgrades google-java-format to 1.19.2 which adds support for formatting Java 21
Adds t...
Bumps org.mockito:mockito-core from 5.8.0 to 5.10.0.
Release notes
Sourced from org.mockito:mockito-core's releases.
v5.10.0
Changelog generated by Shipkit Changelog Gradle Plugin
5.10.0
2024-01-24 - 8 commit(s) by Andre Brait, dependabot[bot]
Bump org.shipkit:shipkit-auto-version from 1.2.2 to 2.0.2 (#3248)
Bump org.assertj:assertj-core from 3.25.1 to 3.25.2 (#3247)
Bump org.shipkit:shipkit-changelog fro...
Bumps github.com/google/uuid from 1.5.0 to 1.6.0.
Release notes
Sourced from github.com/google/uuid's releases.
v1.6.0
1.6.0 (2024-01-16)
Features
add Max UUID constant (#149) (c58770e)
Bug Fixes
fix typo in version 7 uuid documentation (#153) (016b199)
Monotonicity in UUIDv7 (#150) (a2b2b32)
Changelog
Sourced from github.com/google/uuid's changelog.
1.6.0 (2024-01-16)
Features
add Max UUID constant (#149) (c58770e)
Bug Fixes
fix typo in version ...
Bumps github.com/google/go-containerregistry from 0.15.2 to 0.19.0.
Release notes
Sourced from github.com/google/go-containerregistry's releases.
v0.19.0
What's Changed
Work around docker v25 tarballs by @jonjohnsonjr in google/go-containerregistry#1872
Full Changelog: https://github.com/google/go-containerregistry/compare/v0.18.0...v0.19.0
v0.18.0
What's Changed
fix: goreleaser config by @caarlos0 in google/go-containerregistry#1764
Al...
Bumps google.golang.org/protobuf from 1.31.0 to 1.32.0.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. ...
Bumps google.golang.org/grpc from 1.60.1 to 1.61.0.
Release notes
Sourced from google.golang.org/grpc's releases.
Release 1.61.0
New Features
resolver: provide method, AuthorityOverrider, to allow resolver.Builders to override the default authority for a ClientConn. (EXPERIMENTAL) (#6752)
Special Thanks: @Aditya-Sood
xds: add support for mTLS Credentials in xDS bootstrap (gRFC A65) (#6757)
Special Thanks: @atollena
server: add grpc.WaitForHandlers...
Bumps github.com/charmbracelet/bubbles from 0.17.1 to 0.18.0.
Release notes
Sourced from github.com/charmbracelet/bubbles's releases.
v0.18.0
Textarea, but faster
This release features several fixes and big performance improvements for the textarea bubble.
What's Changed
New
Optional File Permissions and File Size by @maaslalani in charmbracelet/bubbles#471
Add Paginator OnFirstPage method by @maaslalani in charmbracelet/bubbles#463
Improved
...
Finally basing main versions of, of the engine. Still need to integrate the releaser.
Problem
As discussed on Discord:
I find myself wishing that we did not honor OCI image entrypoints by default...
I would much rather know that, by default, From("foo").WithExec("bar") will always actually execute the binary "bar" in the image "foo", unless I specifically tell Dagger that I care what the image author put in the entrypoint (most of the time I don't).
Kind of like the way Kubernetes manifest ignores a bunch of fields in the docker image, and just makes you re-...
This started as a fix to a problem where syncing a module using
"include" in dagger.json was resulting in the dagger.json being reset to
an empty module. The root cause was that the include did not have
dagger.json itself in it, so when the module was loaded into the engine
it looked like an uninitialized module that needed to be initialized.
That bug in particular was a regression caused by the recent changes
around module loading and configuration.
This change fixes that bug, but...
While investigating something (hopefully) unrelated to this, I found that StartBindings wasn't handling error cases well. There is an attempt to try and call detach on failure, but it wasn't being used.
Because we use a channel to pull the binding results, if one of the services failed to start for some reason, we would exit early, and none of the started services would be in running, so when we called detach, none of the services would be stopped. This could easily result in dangli...
A super weird find (I think this was introduced recently?)
https://github.com/dagger/dagger.io/actions/runs/7756389308/job/21153589598?pr=3359#step:4:2365
24: exec go test ./cmd/ci/ -v -timeout=30m
24: [244.0s] 2024/02/02 13:12:31 http: panic serving 127.0.0.1:42432: context canceled
24: [244.0s] goroutine 863 [running]:
24: [244.0s] net/http.(*conn).serve.func1()
24: [244.0s] /usr/local/go/src/net/http/server.go:1868 +0xb9
24: [244.0s] panic({0xfcadc0?, 0x1b79170?})
24: [24...
Change how to detect os and architectue on Windows. For the architecture. For the architecture, it needs to strict with amd64 since :erlang.system_info(:system_architecture) returns :win32, which not helping us to determine os architecture on Windows.
Fixes: #6540
Change how to detect os and architectue on Windows. For the architecture. For the architecture, it needs to strict with amd64 since :erlang.system_info(:system_architecture) returns :win32, which not helping us to determine os architecture on Windows.
Fixes: #6540
Prior discussion on GH: https://github.com/dagger/dagger/pull/6390
Recent Discord discussion: #daggernauts message
Changes current in this PR:
Container.shellis renamed toContainer.terminal--argsrenamed to--cmd
So from the CLI you'd now do e.g.
dagger call my-devenv terminal --cmd neovim
We also discussed some alternatives to terminal in the zenith call a bit ago:
tty- `o...
Coverage for this was missing. I expected going into this that it would actually not work as expected yet based on user reports but I haven't been able to repro the behavior they saw yet. Will update if any bugs are found. But in the meantime obviously need to have coverage of this either way.
This commit fixes various formatting issues in the Dagger Cloud get started.
It seems in most cases we want --native to be the default. So this makes it the default and adds --random for the old behavior (choose random ports).
--pprof: useful for debugging dagger itself, but not for regular usage
--cpuprofile: same as above
--workdir: may be deprecated soon, hide it in the meantime
I also wanted to hide the dagger completion, but didn't find how. Will open a separate PR once I do.
Following dagql integration, the service start operation was not relying on a unique ID as digest. This led the Cloud not showing the service start as a step in Dagger Cloud. By appending the ".start" to the id, we isolate it
We now have back:
Pushing WIP in case anyone wants to play with it.
Feedback welcome here, but will be more active in Discord.
Running a build, piping to tail, running --help
Running a service
What is the issue?
I have found that the following does not do like I intended and it's not documented, as it is expected to be a relative path:
containerImage.Directory("/foo").WithoutDirectory("/foo/bar")
and instead this needs to be:
containerImage.Directory("/foo").WithoutDirectory("bar")
func (*dagger.Directory).WithoutDirectory(path string) *dagger.Directory
...
Purpose
This PR introduces tests for bun to ensure its compatibility with TypeScript/Node SDK and to prevent future breaking changes.
Key Changes
- Added a test suite for bun using TypeScript/Node SDK.
- Updated CI pipeline to include new tests
Goals
- Verify bun works as expected with TypeScript/Node SDK.
- Automate testing to catch breaking changes before they're merged and ensure bun works in the furure.
TODO
- Discuss what tests should be added
- add ...
What are you trying to do?
Add official support for bun in dagger.
Below I propose a initial list of potential tasks I fell would help users to use bun with dagger
- [ ] Add tests for bun #6590
- [ ] Update the documentation to show how bun is working with dagger
- [ ] Add at least one example showcasing bun compatibility with dagger
Why is this important to you?
Bun is a new JavaScript runtime promising to solve many of the issues found in the current Node ecosystem that ...
This adds CLI reference generation for the main docs. Previously we only had it for zenith docs.
Since there’s now two different front matters, I thought it’s better to decouple from being hardcoded anyway (--frontmatter), which also reduced the complexity over parsing the file name to get the right slug for it. This also allowed printing the result to stdout because the file name no longer matters (--output flag).
Fixed an issue where dagger completion was being excluded from usa...
Hm, I didn't catch this in https://github.com/dagger/dagger/pull/6499.
It looks like I fixed it for srv.Wait, not actually for handleConn :scream:
What is the issue?
Currently, codegen will query all fields for any function with no id field, env_variables (or envVariables in GraphQL). But now EnvVariable type has an id field, causing the codegen render code incorrectly.
Dagger version
dagger on main branch
Steps to reproduce
No response
Log output
No response
Re-structure foundation code (Client, QueryBuilder, EngineConn, etc.) to under Dagger.Core namespace. And fix all generated code to use that module.
This is a fun one. Let's suppose I'm running a dagger engine as engine:
// This works fine :tada:
tunnel.Stop(ctx)
engine.Stop(ctx)
If we swap the order, we block forever, yay!
// This blocks forever!
engine.Stop(ctx) // we never return
tunnel.Stop(ctx)
This is kinda tricky, but essentially, there is still an open connection for the tunnel open to the server, so the server's Stop/GracefulStop can get stuck. We get stuck trying to do a handshake...
There is a comment suggesting this? I'm not quite sure why it's not turned on, it definitely feels important.
This also clogs up every stack dump, with literally thousands of copies, since it never closes.
@sipsma is there a good reason to not do this? The stream connection can never outlive this Session call, so we should just be able to call this.
This changed in https://github.com/dagger/dagger/pull/6582
TODO:
- [ ] Run through the impacted guides manually to verify changes
What is the issue?
For security reasons many companies man-in-the-middle all SSL traffic to the internet with their own certificate. This causes a x509: certificate signed by unknown authority issue in two spots for dagger:
- Dagger engine. This is easy to solve by mounting the certificates in the container.
- Dagger modules. The modules appear to be loading a tar container
/usr/local/share/dagger/go-module-sdk-image.tarand building a go program when running any module command...
This commit upgrades to Docusaurus 3.1.1
[!WARNING]
Not currently implemented! This PR just contains a wip test.
This commit fixes an output error in the Zenith quickstart
Reverts #6597.
See https://github.com/dagger/dagger/pull/6597#issuecomment-1930527937. I don't have the bandwidth to investigate this properly, and the leaking threads (while annoying, at least doesn't break every test run).
If we merge this, I'll open an issue and pick it up later.
See https://github.com/dagger/dagger/pull/6603.
We need to make sure to close conn here, or closeCh blocks forever!
However, it looks like something goes wrong and TestModuleLotsOfFunctions times out: https://github.com/dagger/dagger/pull/6597#issuecomment-1930527937
Follow ups from https://github.com/dagger/dagger/pull/6533 around install (and managing dependencies generally):
- [ ] add support for
dagger updateto update existing deps- Currently this implicitly happens if you
dagger installan existing dep at a different version, but it would be better to have an explicit command for it. - We could then consider whether we want
dagger installto fail if dep at different version already exists or to continue supporting the implicit upgr...
- Currently this implicitly happens if you
(Follow ups from https://github.com/dagger/dagger/pull/6533 related to dagger config)
dagger config currently only prints the configuration of a module, needs to be expanded with subcommands for actually setting the values not settable elsewhere. Currently those values are just:
includeexclude
But we should keep in mind that list may grow over time.
Quoting @shykes from the previous PR around some possibilities here:
git configstyle. I don't remember what it is...
(Follow-up to https://github.com/dagger/dagger/pull/6533)
dagger develop currently only allows you to set the name/SDK of a module that does not already have one set.
It's possible to support changing the name/SDK too, but there's a few things to consider here:
- If you rename your module, you'd need to also update your code to use that name in the structs, but obviously much better would be if we did that automatically somehow
- more thoughts from @helderco [here](https://github...
What are you trying to do?
I'm writing a module that exposes a function with complex arguments which are not currently supported via the dagger call command. I would really like that function not to be callable or displayed in the dagger functions given that it's only intended to use via an SDK and not the CLI.
Why is this important to you?
To provide a clearer API to my module users.
How are you currently working around this?
No response
Merging https://github.com/dagger/dagger/pull/6537 after https://github.com/dagger/dagger/pull/6533 caused test failures from dagger mod init being renamed to dagger init.
See https://github.com/dagger/dagger/pull/6288#issuecomment-1931971234 - this fixes the borked provision job: https://github.com/dagger/dagger/actions/runs/7814283652/job/21315752098.
Previously, we would only connect once. However, when calling buildkit's client.Wait we might attempt multiple connections over and over. If we only have one connection, this isn't possible. Ideally, we should have some better error messages in buildkit, since this was annoying to debug.
The right call her...
As mentioned in #6591 I looked into running our current test suite inside the bun runtime. This is the result.
Currently unref is not working, but is already fixed and should be availaible soon #. This has nothing to do with our SDK. We just use unref inside the test.
All other tests seem to work just fine.
This approach is an alternative to #6590
These changed in https://github.com/dagger/dagger/pull/6533
Just making the bare minimum changes to keep docs aligned with reality here rather than documenting any of the new features yet.
Not adding to the v0.9.9 milestone since it's not technically a blocker, just should be merged soon after that's done.
The listed command in the previous examples didn't really help users:
$ dagger call container-echo --string-arg yo
Container evaluated. Use "dagger call container-echo --help" to see available sub-commands.
We should amend the default template command to actually print the result:
$ dagger call container-echo --string-arg yo stdout
yo
Release notes a little slim this time, but there's actually not a lot to pull in that's non-zenith related (which we don't changelog):
We're not using this option - the magic session manipulation is coming from direct access to SessionManager, using llb.Local, or passing the session ID directly into Export.
Noted this while working on #6601.
@kpenfound noticed this fun one while migrating to new the source fields:
❯ dagger init --sdk=go --name=playground --source .
Initialized module playground in .
❯ ls
dagger.gen.go dagger.json go.mod go.sum main.go querybuilder
❯ rm main.go
❯ dagger functions
Name Description
container-echo example usage: "dagger call container-echo --string-arg yo stdout"
grep-dir example usage: "dagger call grep-dir --directory-arg . --pattern GrepDir"
Eve...
otherwise it hangs the moment it tries to write to os.Stderr
Right now all our integ tests only use local refs because git modules are locked into github repos and we've been trying to avoid tests depending on modules in an external git repo. However, I think we should just bite the bullet on that at this point since missing that test coverage is too big a gap.
This is happening on main, but not on version 0.9.8
Repro:
git clone -b daggerize https://github.com/kpenfound/example-voting-app
cd example-voting-app
dagger functions
The module has 4 local module dependencies and 1 remote. Of the local dependencies, there are 2 Go modules (Seed, Worker), 1 Python module (Vote), and 1 Typescript module (Result).
The codegen is not including Result for some reason, and any call results in:
`dag.Result undefined (type *Client has n...
Follow-up from:
For example, in our root:
dagger init --sdk=python --source=dev
This will add .gitattributes and .gitignore with /sdk, when it's actually in dev/sdk.
\cc @sipsma
Think this happened when switch up to default to native.
The logic was accidentally setting native to true even when ports were manually specified which resulted in each port being applied twice. In the case where the same values of frontend and backend were specified (i.e. 5000:5000) this resulted in an error since you'd try to listen on the same port twice.
Should (re-) fix https://github.com/dagger/dagger/issues/6303
I have to constantly add "exclude": "sdk" to dagger.json after dagger init.
I don't exepct these files to be uploaded. They're not completely replaced in codegen. During local dev, some files can be created in there and they will stay after codegen in the container. It affects the Source dir cache.
Since "root" is no longer sent, exclude/include patterns only take meaning from "source" directory. Otherwise you need to repeat the subdir in the patterns if you want to target something at the root of that dir, for example:
{
"name": "python-sdk-dev",
"sdk": "python",
"source": "dev",
"exclude": [
"dev/sdk"
]
}
[dagger/dagger] Issue opened: #6630 `slice bounds out of range [1:0]` panic in shim secret scrubbing
Hit this while testing publish things in my fork: https://github.com/sipsma/dagger/actions/runs/7837271347/job/21386972933#step:4:2866
Stack:
62: [0.09s] panic: runtime error: slice bounds out of range [1:0] goroutine 1 [running, locked to thread]:
62: [0.09s] runtime/debug.Stack()
62: [0.09s] /usr/local/go/src/runtime/debug/stack.go:24 +0x5e
62: [0.09s] main.main.func1()
62: [0.09s] /app/cmd/shim/main.go:63 +0x38
62: [0.09s] panic({0x1105620?, 0xc000044c78?})
62: [0.09s] /u...
An unfortunate series of events can cause the TUI to rapidly consume all available memory. With whitespace. Oopsie.
- When you call
ModuleSource.resolveDependency(gitModSource), it returnsgitModSource, since there's no need to make a Git module source relative to anything else. - This meant the
resolveDependencycall recordedgitModSourceas anOutput: https://github.com/dagger/dagger/blob/5ee49b9e9a955432d688157893b299f8a6180b1d/tracing/graphql.go#L119 - The TUI uses this ...
This path changed the other day: https://github.com/dagger/dagger/commit/01268a5fe62067f7d5dddfb5f5d90ecf4909eac4
But it's only used in mage during engine bump PR, which only runs at release, so wouldn't have been caught til then. Noticed it because I was testing publish workflows in my fork.
This PR includes updates to the Cloud docs
- [ ] Clarify config and UX for local and CI
- [ ] Update cache instructions to include config for pushing the volumes to distributed caching
- [ ] Update reference and getting started for recent UI improvements
- [ ] Update all Cloud docs for new plans
Status
- Getting started guide: Ready for review
- Reference: In progress
We will also need to copy these docs into the Zenith/latest later. That will be in a separate PR.
What happened? What did you expect to happen?
I've been trying to add Hilt in my app but I run into this issue when building:
Execution failed for task ':app:hiltJavaCompilePreprod'.
java.lang.NullPointerException: Cannot invoke "dagger.spi.shaded.androidx.room.compiler.processing.XTypeElement.getAnnotation(com.squareup.javapoet.ClassName)" because the return value of "dagger.spi.shaded.androidx.room.compiler.processing.XProcessingEnv.findTypeElement(com.squareup.javapoet.TypeNam...
This PR was auto-generated.
See https://go.dev/doc/go1.22. Worth reading, but in particular:
- Previously, the variables declared by a "for" loop were created once and updated by each iteration. In Go 1.22, each iteration of the loop creates new variables, to avoid accidental sharing bugs. The transition support tooling described in the proposal continues to work in the same way it did in Go 1.21.
- "For" loops may now rang...
What is the issue?
There is a regression on dagger v0.9.9 with the dagger listen command when the flag --disable-host-read-write is specified. Prior to v0.9.8 this was working correctly. Since v0.9.9 it fails with:
Error: failed to get configured module: failed to get local root path: input: resolve: moduleSource: resolveContextPathFromCaller: failed to stat source root: failed to receive file bytes message: rpc error: code = Unimplemented desc = unknown service moby.filesync.v1....
Note
This is a new PR to replace 6633. Something got off in the commit history for that PR after a rebase. It's easier to start afresh in a new PR. Original PR: https://github.com/dagger/dagger/pull/6633
Overview
This PR includes updates to the Cloud docs
- [x] Clarify config and UX for local and CI
- [x] Update cache instructions to include config for pushing the volumes to distributed caching
- [ ] Update reference and getting started for recent UI improvements
- [ ] Update a...
What is the issue?
When dagger engine runs initially with a new version the TUI used to show that the new engine image is being downloaded. Now it looks like it's frozen.
Dagger version
v0.9.9
Steps to reproduce
remove the existing dagger engine (if already at 0.9.9) and run dagger call
Log output
No response
I'm surprised I can't do this flow for installing a bunch of modules and then seeing what functions I could run from CLI with dagger functions:
- dagger init
- dagger install
4 dagger functions # to see what I've got to play with...
throws error
Error: input: resolve: moduleSource: resolveFromCaller: asModule: initialize: module name and SDK must be set
Figure we need to make that flow work or provide another way to get list of functions available from installed modules since...
The source root subpath of git refs were being turned into absolute paths (as opposed to local refs which always stored the source root subpath as relative). This broke the resolve dependency logic and resulted in errors when installing modules from a git ref that had a relative local dep.
Bumps prettier from 2.8.7 to 3.2.5.
Release notes
Sourced from prettier's releases.
3.2.5
🔗 Changelog
3.2.4
Fix .eslintrc.json format #15947
🔗 Changelog
3.2.3
Format tsconfig.json file with jsonc parser #15927
🔗 Changelog
3.2.2
🔗 Changelog
3.2.1
🔗 Changelog
3.2.0
diff
🔗 Release note
3.1.1
🔗 Changelog
3.1.0
diff
🔗 Release note
3.0.3
🔗 Changelog
3.0.2
🔗 Changelog
3.0.1
🔗 Changelog
3.0.0
diff
🔗 Release note
3.0.0-alpha.6
What's Changed
Update .d.ts ...
cc @d3rp3tt3 @vikram-dagger
We don't need to run helm or engine-and-cli (the very long ones, test+testdev) on every single docs PR.
The SDK jobs still should run on every PR, since the linting jobs can also lint the contents of the docs/ directory I think?
This bumps midterm to fix a ton of rendering issues with TUI apps, primarily with how scrolling regions are handled.
Vim now mostly works, but only with TERM=tmux-256color. With TERM=xterm-256color for whatever reason it prints \r\n when it should be printing \n which totally butchers the UI. Easy to trigger with just deleting a line (dd). Something similar happens when selecting lines upward (e.g. GV{{{). Currently compiling neovim to fig...
I want to flag something in the new Go DX for optional arguments. I don't like encoding my default values in comments with +default, because they are no longer in my code. I can't use them if I need any value more trivial than a string. I can't use them in any way when calling functions intra-module. At this point I think we should remove +default and keep only +optional. It's not a one-way door: we can add it later. But if we keep it now, we will fragment how devs manage their default va...
Without this, the Go module SDK would only ever be able to build modules with the single go version that our CI had permitted - this made for a really confusing and frustrating experience when running a newer go version locally (e.g. being on a bleeding edge distro :smile).
I noticed this when using a go.work in my own daggerverse repo:
$ dagger call get-latest-release --repo="dagger/dagger" body
✘ ModuleSource.asModule: Module! 1.8s
✘ Module.withSource(
source: ✔ Modu...
What is the issue?
If I follow the section export-the-build-directory from the docs: https://docs.dagger.io/zenith/quickstart/853930/directories/#export-the-build-directory
I'm getting an error when trying to check the Dagger version:
$ ./dagger version
zsh: exec format error: ./dagger
cc @jedevc
Dagger version
dagger v0.9.9 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
To reproduce the issue, execute the following commands on an Apple Silic...
If I have a module with a source key set to a ./ci, when I run dagger develop, I expect that the generated .gitattributes file should be generated into ./ci, and not at the top-level where my dagger.json is.
Alternatively, if we do decide that the top-level is the right place to put it, then the file should contain the right paths. Today, it looks something like:
/dagger.gen.go linguist-generated
/querybuilder/** linguist-generated
Even though dagger.gen.go...
When I initialize a new module with dagger init and I mistyped the --sdk, I'm getting the following error.
$ dagger init --name=my-module --sdk=typescrip
Error: failed to generate code: input: resolve: moduleSource: withName: withSDK: withSourceSubpath: resolveFromCaller: failed to collect local module source deps: failed to collect local sdk: missing config file /Users/slumbering/workdir/dagger-zenith/trivy/typescrip/dagger.json
I'm wondering if we could improve this mes...
This PR was auto-generated.
To reproduce this, try initializing a dagger module in a directory that already contains a go.mod. For example:
$ git clone https://github.com/dagger/dagger.git
$ dagger init --sdk=go
✘ ModuleSource.asModule: Module! 2.0s
✘ Module.withSource(
source: ✔ ModuleSource.resolveFromCaller: ModuleSource! 0.0s
): Module! 2.0s
✘ Container.directory(path: "/src"): Directory! 1.4s
✔ rm /dagger/dagger.gen.go 0.4s
✘ exec /usr/local/bin/codegen --module-context...
I want to have a module with a directory structure like this:
dagger
├── dagger.gen.go
├── go.mod
├── go.sum
├── main.go
├── querybuilder
│ ├── marshal.go
│ └── querybuilder.go
└── util
├── engine.go
├── generated.go
└── util.go
3 directories, 9 files
Essentially, I want a custom util directory with some helpers. However, if these utils require accessing dagger types like Client or Container, then there's no way of expressing this.
The ty...
[dagger/dagger] Issue opened: #6662 Using embedded fields with go modules fails with unhelpful error
Take the following code:
type Playground struct {
// This breaks
*Directory
// This doesn't
// Directory *Directory
}
func New() Playground {
return Playground{Directory: dag.Directory()}
}
When attempting to evaluate anything on the Playground object, we get the following error:
Error: response from query: input: resolve: playground: failed to convert return value: unexpected result value type string for object "Playground"
[dagger/dagger] Issue opened: #6663 `test:race` job should enable race checker on the engine as well
At the moment, we're only checking for race conditions in the client - but ignoring race conditions in the engine.
This is useful, and it has caught a number of issues in the client, but there are also potentially race conditions in the engine! e.g. see https://github.com/vito/progrock/issues/12 (cc @vito)
Note: running with the race checker is likely going to have a *...
What I expect to work:
dagger init
dagger install github.com/shykes/daggerverse/hello
dagger -m hello functions
What I get:
Error: failed to get configured module: failed to get local root path: input: resolve: moduleSource: resolveContextPathFromCaller: cannot resolve non-local module source from caller
Additionally, when I run dagger -m hello functions, I get local files created mimicking the module's remote ref:
$ tree github.com
github.com
└── shykes
...
Fixes https://github.com/dagger/dagger/issues/6664
Based on my testing, DependencyByName would return the git URL from the config, and we'd assume this was a local path. Source.Kind check happens earlier in this function, so recursively calling the function with the un-short-named ref felt right. There may be a case I'm missing here.
What is the issue?
Created module for running remote commands via SSH https://daggerverse.dev/mod/github.com/samalba/dagger-modules/ssh@35ed3e343d7e6faa3eab44570ee7531914dd4e65
I initialized the module with:
dagger init --name ssh --sdk go --source .
The module code uses a struct named Ssh. It works fine as standalone. However when you install the module from another module, it's available via dag.SSH() (different capitalization), which then fails to compile, because it cann...
Problem
When running a service from the Dagger CLI, for example dagger call .... up, interrupting the call with Ctrl-C does not propagate the SIGINT signal to the service process itself. As a result, the program doesn't get a chance to clean up.
This may also apply to WithExec, I haven't checked.
What is the issue?
Trying to execute the following pipeline:
func main() {
defer dag.Close()
dag.Container().From("alpine").
WithExec([]string{"apk", "add", "bash"}).
WithNewFile("/entrypoint.sh", dagger.ContainerWithNewFileOpts{
Contents: `#!/bin/bash
sleep 10 &
echo "foo"`,
Permissions: 0755,
}).
WithEnvVariable("BUST", time.Now().String()).
WithEntrypoint([]string{"/entrypoint.sh"}).
...
What is the issue?
It seems that host ports are not binded properly to the host when multiple WithExposedPort are present (and at least one port is binded to the host with --port)
Dagger version
dagger v0.9.10
Steps to reproduce
Context
Given this example module:
func (m *MyMod) Package(
) *Service {
return dag.Container().
From("localstack/localstack:latest").
WithExposedPort(4566).
AsService()
}
I can run this command: `dagger cal...
Otherwise this will trigger every time there is push to main
Follow-up to:
Using platformVariants is extremely unwieldy to use: https://github.com/dagger/dagger/blob/fca9e788f6d605ef9d256beace4656c11d7f6fe5/docs/docs-graphql/schema.graphqls#L196-L201
The idea is that you can construct multiple Container objects, and then compose them to together on Publish/Export to push a multi-platform image.
However, this feels like a weird abstraction - quite often, in our own CI in this repo, we end up calling a single function multiple times with different arch...
Started noticing some horrible output like this in my terminal logs:
Now, with an update to this printing logic:
Hopefully the multi-line warning here is alright!
Should fix https://github.com/dagger/dagger/issues/6659 (cc @nipuna-perera).
This is a pretty common use case - we have a go.work at the root of a repo, and we want to create a dagger module for it with dagger init.
However, naively, this will actually create a dagger module that can't be called (because go.work doesn't include it). To resolve this, we need to add it to go.work.
Finally! This patch splits up the codegen for go modules to produce the main external struct defs into a separate sub-package. There are a couple of reasons for doing this:
- Tighter control over exposed structs and their internal private methods
- Ability to import the generated structs from a sub-package
Initially this might sound simple - and prior to the addition of interfaces, it was, however, these add a lot of confusion. Specifically, interface codegen is added alongside the main ...
What happened? What did you expect to happen?
Hi, I am just getting started with dagger. My project structure is like this
.
├── ci
│ ├── go.mod
│ ├── go.sum
│ └── main.go
├── service1
│ ├── Dockerfile
│ ├── go.mod
│ ├── go.sum
│ ├── internal
│ └── main.go
├── service2
│ ├── Dockerfile
│ ├── go.mod
│ ├── go.sum
│ ├── internal
│ └── main.go
The dagger program is written inside the ci folder. What I would like to do is "access the...
[dagger/dagger] Pull request opened: #6683 feat: go module default arg values must all be valid JSON
Reference: #p-modules-launch🚀 message
No more // +default=foo which is unclear, now we require // +default="foo".
This is a zenith breaking change! cc @vikram-dagger, I've updated the docs as well.
Chucking this onto the v0.9.11 milestone, sooner > later. We should do another announcement in #project-zenith when we do this.
This follows up from
https://github.com/dagger/dagger/pull/5530#discussion_r1321896711, bump a :dagger version in the install sdk section to the latest version when calling sdk:elixir:bump is called.
This change already bumps to the latest version by running ./hack/make sdk:elixir:bump 0.9.10.
As discussed with @TomChv in #6591.
Changes:
Our CI would test with
node:18-alpinenode:20-alpine
and not withnode:16-alpine, which is discontinued and reached EOL.
All other tasks, such as lint, bump, publish, build, utilize the LTS version of node, which is currently 20.
Updated the package.json to reflect we only test for node>=18.
Node 18 is maintained until 30 Apr 2025.
Thats when we should potentially look into upgrading again.
This P/R adds type hinting for Pycharm, as shown by the image below.
Implementation Details
Currently Pycharm type hinting does not work. The first issue is that it cannot detect the Client that async with dagger.Connection(config) yields.
 darwin/arm64 and having mounted directory using withMountedDirectory and expected that changes to that directory are reflected in host, but no changes are made to host directory.
If that's by design, then what's the difference between withMountedDirectory and withDirectory?
hey there! WithMountedDirectory works the same way as the RUN --mount instruction that you see in Dockerfiles.
It's not bind mounting the files in your machine to the build, what it does is mounting the files from your build context into your pipeline so your resulting container doesn't contain those files in the layered filesystem. If you want the files that you change in your pipeline in your host, you need to use the Export function. There's more info about that here: https:/...
hey there! WithMountedDirectory works the same way as the RUN --mount instruction that you see in Dockerfiles.
It's not bind mounting the files in your machine to the build, what it does is mounting the files from your build context into your pipeline so your resulting container doesn't contain those files in the layered filesystem. If you want the files that you change in your pipeline in your host, you need to use the Export function. There's more info about that here: https:/...
I see, thanks for the quick reply.
The only problem I see, also where we needed mounting, is getting test results for later use. The problem is that export to host will not be executed if test fails.
re: container exit, we have a cookbook for those cases here: https://docs.dagger.io/cookbook/#continue-using-container-after-command-execution-fails
What is the issue?
Found on the PR https://github.com/dagger/dagger/pull/6559 which is already rebased on main. When create a module with git repository SDK (not a builtin). The engine returns internal server error instead of error from the SDK
Dagger version
dagger 4b825dc642cb6eb9a060e54bf8d69288fbee4904 (registry.dagger.io/engine) darwin/arm64
Steps to reproduce
$ mkdir first-module
$ cd first-module
$ ~/src/github.com/dagger/dagger/hack/with-dev dagger init --sdk=...
In Zenith documentation, it need to change directory to my-module before initiate the module to create module to correct location.
As discussed in https://github.com/dagger/dagger/pull/6638#discussion_r1492496828, this change places the custom module in the root rather than a sub-directory.
@shykes i think we should work on jsr.io support to make dagger js sdk available for any js runtime like deno and others.
Please have a look. Thanks
Fixes https://github.com/dagger/dagger/issues/6669.
Previously, FormatOutputType and FormatInputType wouldn't use the same capitalization as formatName. The solution is to have these functions also format the underlying names, which means we get consistent caps!
fixes https://github.com/dagger/dagger/issues/6623
Most of the recent bugs from the last week ended up being simple things related to using git module refs, which was due to the fact that we didn't have integ test coverage of those.
We didn't have coverage previously because it's slightly less obvious than it seems due to the limitation around git modules only being allowed to be from github.com/. That essentially rules out authoring the tests in the repo itself (there's various shena...
Noticed a performance impact in a module when iterating over a list returned by a dependent module.
The calling module was requesting a field (state), which should be returned directly by the API server, but was actually calling out (exec /runtime) on a bunch of functions that return a simple string. So these were flagged as simple fields to prefetch, even though I didn't need them, but it's the act of executing the runtime that slowed things down unnecessarily.
By loading from ID inste...
Before:
TypeError: Expected collection type to be subscripted with 1 subtype, got 0:
TypeError: Expected collection type to be subscripted with 1 subtype, got 0:
After:
NotImplementedError: Scalar types are not supported yet. Define argument as a string and convert to the desired scalar type in the function body.
NotImplementedError: Enum types are not supported yet. Define argument as a string and convert to the desired enum type in...
This test is super annoyingly flaky :(
It seems like calling Close is racy, and sometimes we don't get the fully progress logs - to work around this for now, we can try and call service close explicitly, which should hopefully make this failure a bit more unlikely.
Yes, we should fix the underlying issue at some point - cc @grouville, I know you were also working on this.
Follow-up to #6678.
I was missing an important test case that reveals I was doing this entirely wrong.
The condition should check for the existence of go.work, not it's absence, and we should actually look in the root, which is found in a configuration option.
Fixes https://github.com/dagger/dagger/issues/6625.
We just need to switch from putting them into the SourceRootSubpath to putting them in SourceSubpath.
This PR was auto-generated.
Potential fix for #6155.
This is an implementation of @helderco's suggestion in https://github.com/dagger/dagger/issues/6155#issuecomment-1953199174.
I'll add some tests, and such, but thought I'd throw this together so people can try it.
- Rather than always marking ID vertices internal to avoid cluttering Cloud and the old TUI, we mark them internal just before sending downstream to either.
- Better panic handling in DagQL + the TUI, plus fixed a couple of panics
- Better errors out of DagQL in general
TODO:
- [ ] Update TUI to handle new
initandprimaryvertices specially - [ ] Just move meta fields to
progrock.Vertexso we don't have to deal with the time period where they haven't arrived (super annoying)
Hopefully fix https://github.com/dagger/dagger/pull/6636#issuecomment-1935917443.
This is a nice intermediate until we can bump to go 1.22: https://github.com/dagger/dagger/pull/6637 (blocked due to an upstream go/glibc issue).
See also discord conversation: #maintainers message.
Writing up a brain dump, so might be a bit messy.
Currently the go version used by the Go SDK is 1.21.3. However, a user module can set a custom go version (using go.mod/go.work) to a higher version, like 1.22.0.
Now, this can cause fun issues it seems? I'm not quite sure what happens, but essentially in https://github.com/dagger/dagger/blob/b2450fc1c61dfff5f04fe1679bc09b412c33a7e0/cmd/codegen/generator/go/generator.go#L292-L302
We can get a package returned that:
{...
As discussed with @vikram-dagger .
We split the last part of the quickstart into 2 pages, to introduce the concept of installing dependencies and calling them from the CLI, before writing code for your own functions. The goal is to make the learning curve smoother.
Unfinished content is marked with FIXME
All found while investigating https://github.com/dagger/dagger/issues/6706, all little minor things, but worth fixing while we're around, see commit messages for more details.
Just updating the repo to be our shiny new one under the dagger org so that others on the team can contribute to it as needed.
Problem
When calling a function that returns a core type, like Container or Directory, I can then call any function from that core type... except id.
This makes it unnecessarily difficult to stitch together calls in a shell script, for example:
dagger call deploy --build="$(dagger call build --src . id)"
One workaround is to call sync, but that's confusing if I'm trying to get the object's ID to pass it to another function call. id is exactly what I'm l...
Receiving a simple string value from a module is a pretty common use case, and most of the time there's no trailing linebreak, so if we print it verbatim the user will either have a broken prompt or see a funny little character if their shell is polite and adds a linebreak for them.
Rather than potentially encourage module authors to add a linebreak, we'll add it ourselves, but only if stdout is a TTY, since we want piping and redirects to always "tell to the truth."
Problem
Container.WithDefaultTerminalCommand allows configuring the command to be executed by Container.Terminal. But some execution options are not available:
| Option | Description | Available in withExec |
Available in withDefaultTerminalCmd |
|---|---|---|---|
experimentalPrivilegedNesting |
Allow the executed command to make API calls to the Dagger Engine running it | ✅ | ❌ |
insecureRootCapabilities |
Execute the command in a privileged linux container | ... |
Problem
The Dagger API does not support checking if a file exists. There is an SDK-specific workaround (maybe? not documented) which is to 1) call any function that requires the file to exist, like Sync or Contents, 2) check for error, and 3) check for the error message returned when the file doesn't exist. This possibly can be wrapped in a convenience type by the SDK (again hard to tell as it is not documented).
This makes for a bad DX.
Solution
Add a new core function ...
@vito noticed a while back that we were spending a lot of time loading the builtin Go SDK tarball. This fixes that bottleneck by avoiding use of local imports for built-in SDKs and instead using OCI store sources, which avoid the various problems with local sources (re-importing when used in parallel, need to always re-read tarball when importing containers, etc.).
Seeing some huge improvements when running subsets of tests, e.g. TestModuleGoInit takes 47s whereas it previously took 1m16...
Fixes https://github.com/dagger/dagger/issues/6662.
With the below case, the object would inherit it's implementation of MarshalJSON from Directory:
type Foo struct {
*Directory
}
We need to define our own MarshalJSON so we don't end up with this issue.
To do this, we just define another method next to our implementation of UnmarshalJSON, using the same trick of having an intermediate concrete struct (but we can handle module interfaces in a much simpler way, ...
See discussion in discord: #daggernauts message
https://github.com/dagger/dagger/pull/6680 made Client and Query reserved fields on all objects - but it's quite common to define Client on objects.
This patch is a little bit of a refactoring I've wanted to do for a while - it essentially allows binding clients to querybuilder.Selections, which means we can pretty much do away with Client+Query combinations, no...
There was an issue of serialization when the object has aliases in this state.
This PR fixes this and improve the alias testing with more cases.
Also fixes an issue with object state being serialized with non useful data.
Note:
- Correctly support array's result loading
Collecting unhelpful error messages here, please comment when you hit one 🙂
I noticed that on main when running go test -run=TestModule ... the engine ends up using over 6GB of RSS at times. By eye, it seems like it particularly spikes during TestModuleLotsOfFunctions (but did not fully confirm yet).
pprof is showing:
File: dagger-engine
Type: inuse_space
Time: Feb 22, 2024 at 10:18am (PST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 1811.45MB, 71.51% of 2533.09MB total
Dropped ...
Move dagger and querybuilder packages into internal package. See multiple points of confusion in discord:
- #daggernauts message (cc @shykes)
- #daggernauts message (cc @kpenfound)
Moving both of these packages into internal keeps the top-level that little bit cleaner, as well as hopefully removes this confusion - internal is for internal mechans...
The generated .gitignore did not include node_modules in the ignored files:
/sdk
This PR fixes it by including it in the module runtime:
/sdk
/node_modules/**
Somewhat related to https://github.com/dagger/dagger/issues/6112 but a bit more general
Passing a large number of flags and args when using dagger call can become way too tedious to type out by hand. One example would be support for filtering dirs as mentioned here. But really any time a function accepts more than a few flags and/or the arguments to the flag end up being verbose are a problem.
This leaves users ...
(We had an internal Linear issue for this but creating a public GH one)
You should be able to write test code for your module code and easily run those tests. Currently, you really just have to invoke the dagger CLI to "test" a module (that's what our integ tests do for the most part), which isn't nearly as expressive+simple as writing actual test code like you normally would in any language.
Various ideas on how to approach this:
- SDKs could add support for it via another Function a...
Modules can accept other modules as arguments to functions. Use cases:
- SDKs implemented as modules do this already by accepting
ModuleSourceas an arg - Support for running tests of modules could use this: https://github.com/dagger/dagger/issues/6724
- Support for re-executing modules in specialized hosts (i.e. run my module on a "gpu-as-a-service" platform)
- Combined with support for interfaces, you could pass a module as an implementation of an interface argument (if it matches...
We missed adding support for host sockets to CurrentModule when removing Host from module codegen. We should re-add the equivalent support, it should be pretty straightforward.
What are you trying to do?
I'd like to be able to set the title of my runs in dagger cloud. I execute multiple pipelines per commit, so it's a little hard to find what I'm looking for based on commit title.
Example:
I run a (sequential) pipeline that
- Builds everything
- Runs terraform for each environment
Right now each of the above is a separate dagger call. It's hard to find say, the terraform dev run when it all looks like this
 Foo() string {
return "bar"
}
Dagger version
dagger v0.9.11
Steps to reproduce
run dagger functions foo on the code given above
Log output
Error: function 'foo' returns non-object type STRING_KIND
Fixes https://github.com/dagger/dagger/issues/6640
The behavior of dagger listen is supposed to be that it tries to load a local module if it exists but ignores any error and just operates without the module if it can't load one. This just fixes error handling in the case where --disable-host-read-write is enabled.