chore(deps): bump the sdk-java group in /sdk/java with 2 updates #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
* docs: Uses version/arch placeholder in Argo Workflow snippet Signed-off-by: Vikram Vaswani <[email protected]> * Updated placeholder Signed-off-by: Vikram Vaswani <[email protected]> --------- Signed-off-by: Vikram Vaswani <[email protected]>
* docs: initial github container registry integration guide Signed-off-by: Luke Marsden <[email protected]> * docs: fix link to main.go Signed-off-by: Luke Marsden <[email protected]> * docs: hopefully convince linter this isn't a real go file Signed-off-by: Luke Marsden <[email protected]> * Update docs/current_docs/integrations/snippets/ghcr-workflow.yml Co-authored-by: vikram-dagger <[email protected]> Signed-off-by: lukemarsden <[email protected]> * Integrates examplein to GitHub Actions integ page Signed-off-by: Vikram Vaswani <[email protected]> * rename Signed-off-by: Luke Marsden <[email protected]> * bump tag Signed-off-by: Luke Marsden <[email protected]> --------- Signed-off-by: Luke Marsden <[email protected]> Signed-off-by: lukemarsden <[email protected]> Signed-off-by: Vikram Vaswani <[email protected]> Co-authored-by: vikram-dagger <[email protected]> Co-authored-by: Vikram Vaswani <[email protected]>
* docs: Adds PHP integration page Signed-off-by: Vikram Vaswani <[email protected]> * Code fixes Signed-off-by: Vikram Vaswani <[email protected]> * Lint fixes Signed-off-by: Vikram Vaswani <[email protected]> * Lint fixes Signed-off-by: Vikram Vaswani <[email protected]> * Lint fixes Signed-off-by: Vikram Vaswani <[email protected]> * Lint fixes Signed-off-by: Vikram Vaswani <[email protected]> * Update docs/current_docs/integrations/snippets/php/go/main.go Co-authored-by: Helder Correia <[email protected]> Signed-off-by: vikram-dagger <[email protected]> * Update docs/current_docs/integrations/snippets/php/go/main.go Co-authored-by: Helder Correia <[email protected]> Signed-off-by: vikram-dagger <[email protected]> * Updated code Signed-off-by: Vikram Vaswani <[email protected]> * Updated code Signed-off-by: Vikram Vaswani <[email protected]> * Updated code Signed-off-by: Vikram Vaswani <[email protected]> * Lint fix Signed-off-by: Vikram Vaswani <[email protected]> * Update docs/current_docs/integrations/snippets/php/python/main.py Co-authored-by: Helder Correia <[email protected]> Signed-off-by: vikram-dagger <[email protected]> * Updated code Signed-off-by: Vikram Vaswani <[email protected]> * Updated code Signed-off-by: Vikram Vaswani <[email protected]> * Lint fix Signed-off-by: Vikram Vaswani <[email protected]> * Updated code Signed-off-by: Vikram Vaswani <[email protected]> * Lint fix Signed-off-by: Vikram Vaswani <[email protected]> * Lint fixes Signed-off-by: Vikram Vaswani <[email protected]> * Lint fix Signed-off-by: Vikram Vaswani <[email protected]> * Lint fixes Signed-off-by: Vikram Vaswani <[email protected]> --------- Signed-off-by: Vikram Vaswani <[email protected]> Signed-off-by: vikram-dagger <[email protected]> Co-authored-by: Helder Correia <[email protected]>
Signed-off-by: Justin Chadwell <[email protected]>
Looks like this accidentally got removed (by me) during our modularization refactoring, and we got a weird `go.mod`. So, I'm bringing it back! Signed-off-by: Justin Chadwell <[email protected]>
Add OTLP instrumentation to the TypeScript SDK. Use `getTracer` exported from `@dagger.io/dagger/telemetry` to use the tracer. The initialization and cleanup is handled by the SDK during connection. Signed-off-by: Tom Chauveau <[email protected]> Co-authored-by: Helder Correia <[email protected]>
Signed-off-by: Alex Suraci <[email protected]>
* engine: consolidate IDs and re-use servers for nested execs This is an internal only refactor, though it fixes a few bugs while also simplifying quite a bit and setting us up for more simplifications soon. The biggest change is that nested execs connect back to the same server as the main client caller rather than being completely independent. * This is required for the fix to services used in modules (separate PR) to fully work * It also should fix the lack of docker auth in many of our integ tests, specifically those that use nested execs, which leads to dockerhub rate limiting Along the way it also does some consolidation of IDs, removing ModuleCallerDigest and just exclusively using ClientID. This requires that we tell module functions and other nested execs which ID to use, but that itself is setup for even more simplifications in follow-ups (we can remove the need for the current DaggerServer construct entirely, among other things). Signed-off-by: Erik Sipsma <[email protected]> * namespace services by server, not by client Previously it was possible to start a dependent service in one module API call, and then use it again in a later call, only to have it fail because it cannot resolve the service address, even though it's still running. This happened because each invocation has its own client ID, and client IDs were used to build service addresses. This change brings service addresses into alignment with the recent change to uniq them by service ID instead of client ID. The overall effect is that services are deduped within a Dagger invocation, even across module calls. So with this change, the service will just stay running and be re-used by a later call, thanks to the grace period. Signed-off-by: Alex Suraci <[email protected]> * fix routing of host services to correct client Signed-off-by: Erik Sipsma <[email protected]> * deregister secret tokens once client disconnects We previously never explicitly removed client ID -> secret token mappings because it theoretically opened more possibilities for malicious attempts to register a client ID with a different token. However, we need to deregister these now since Client IDs are a content hash of the function call/nested exec definition, which means the same client ID can connect and disconnect multiple times per server. The security implications of this also end up being extremely minimal. Registering a client ID with a different secret token was and still is possible *before* a client fully connects. It is possible to after a client disconnects now but this would only amount to a DOS since the "real" client would just be unable to connect. No information would be leaked. It also would have to be in the same server (i.e. a module or nested exec called by the main client directly or transitively). This issue can also be squashed by not leaking the buildkit sock to nested execs/modules, which is possible now by migrating functionality from our shim to our custom executor. There's no immediate plans to do this but the possibility is open whenever needed (or when we make that change for other reasons). Signed-off-by: Erik Sipsma <[email protected]> * add integ test coverage Signed-off-by: Erik Sipsma <[email protected]> --------- Signed-off-by: Erik Sipsma <[email protected]> Signed-off-by: Alex Suraci <[email protected]> Signed-off-by: Erik Sipsma <[email protected]> Co-authored-by: Alex Suraci <[email protected]>
Signed-off-by: Vikram Vaswani <[email protected]>
Signed-off-by: Vikram Vaswani <[email protected]>
* docs: Updates quickstart examples Signed-off-by: Vikram Vaswani <[email protected]> * Fixed capitalization according to new style guide Signed-off-by: Vikram Vaswani <[email protected]> * Updates examples Signed-off-by: Vikram Vaswani <[email protected]> * Copy fix Signed-off-by: Vikram Vaswani <[email protected]> * Added feedback Signed-off-by: Vikram Vaswani <[email protected]> --------- Signed-off-by: Vikram Vaswani <[email protected]>
* refactor(sdk/rust): Into -> From Signed-off-by: kjuulh <[email protected]> refactor(sdk/rust): Into -> From Signed-off-by: kjuulh <[email protected]> * chore: remove extra clone Signed-off-by: kjuulh <[email protected]> * chore: fix spacing Signed-off-by: kjuulh <[email protected]> * chore: revert allow warnigns Signed-off-by: kjuulh <[email protected]> --------- Signed-off-by: kjuulh <[email protected]>
…7038) * feat: use trait for Struct -> StructID instead of renaming objects Signed-off-by: kjuulh <[email protected]> * chore: include for into id as well Signed-off-by: kjuulh <[email protected]> * chore: remove extra linebreaks Signed-off-by: kjuulh <[email protected]> * chore: fix line breaks Signed-off-by: kjuulh <[email protected]> * refactor: remove direct dependency on ID Signed-off-by: kjuulh <[email protected]> * chore: remove unused tests Signed-off-by: kjuulh <[email protected]> --------- Signed-off-by: kjuulh <[email protected]>
Signed-off-by: guangwu <[email protected]>
Similar to Python SDK, uses introspection from `t.Dagger.instrospection` to generate schema file and mounting it to the container to generate code. Signed-off-by: Thanabodee Charoenpiriyakij <[email protected]>
This significantly improves initial directory upload speed, on my computer this goes from 4.8s to a much better 2.5s. *Ideally*, we could also avoid uploading the git directory. This is a bit of a pain *right now* though, so we don't do it! Signed-off-by: Justin Chadwell <[email protected]>
* Upgrade `ex_doc` to latest version. * Update documentation on the `Dagger` module. * Remove `getting_started.livemd`, it's quite out-of-date. Signed-off-by: Thanabodee Charoenpiriyakij <[email protected]>
This is a very bad default to recommend - essentially this "de-secrets" a value, and this could then be leaked accidentally: - Potentially into OTEL spans - Potentially into cache keys - Potentially into engine logs We should recommend using `WithSecretVariable` instead, which is much better - then rely on the shell to do the interpolation, which avoids all of these problems. The secret scrubber will then guarantee that we don't secrets leaked into logs. Signed-off-by: Justin Chadwell <[email protected]>
* fix gitlab before_script Fixes gitlab beore script by installing the Dagger CLI in a location that's availabe in the $PATH Signed-off-by: Marcos Nils <[email protected]>
* engine: remove ftp_proxy hack This removes the ftp_proxy hack we've had for a while for passing uncached metadata to containers (previously a lot, but recently trimmed down to just ServerID). Instead, we take advantage of the new custom executor added recently and use that to set the _DAGGER_SERVER_ID env var in containers. The plumbing passes the ServerID via job values, which get read by the solver's ResolveOp callback and used to tell the Executor for ExecOps which ServerID to set in the container. There's quite a bit more cleanup coming to everything involved here, but wanted to get this first step out since that hack, besides being annoying, was kind of dubious in nature and was a suspect in some strange behavior reported sometimes. Signed-off-by: Erik Sipsma <[email protected]> * engine: remove apparently unused opTrackingGateway I don't see that this is actually used or ends up modifying anything. Suspect it's vestigial from pre-OTEL days so removing it. Signed-off-by: Erik Sipsma <[email protected]> * engine: pass worker around instead of custom executor This fixes the problem in the previous commit where Dockerfiles with a syntax pragma hit the executor directly before a ServerID could be set. This wasn't the shortest fix, but it seems to be the best long term one. The end result is that the Worker provided to LLBSolvers is always scoped to the server, so we don't even need to be careful about ensuring the right executor is being used everywhere. It just will be now because it's the only executor available to buildkit internals we use. This required a few adjustments from the previous code: 1. The custom executor has been expanded to also be a custom worker. Fortunately, it almost entirely reuses functionality from upstream's base.Worker, so this doesn't another big chunk of code to maintain. 2. llbSolver is now created in each buildkit.Client and setup with a worker.Controller with the Worker scoped to the current ServerID. 3. Rather than passing the ServerID through job keys, we just pass the whole Worker and use that to resolve ops. 4. Some more general cleanup of worker initialization made possible by these changes. Signed-off-by: Erik Sipsma <[email protected]> * backfill integ test coverage for dockerfile w/ syntax pragma Signed-off-by: Erik Sipsma <[email protected]> * add comment pointing to original runc executor implementation Signed-off-by: Erik Sipsma <[email protected]> --------- Signed-off-by: Erik Sipsma <[email protected]>
* sdk(rust): use `load*FromID` in tests Use these newer methods instead of using `container` and `file` to load IDs, which is deprecated and *going to be removed soon*. Signed-off-by: Justin Chadwell <[email protected]> * sdk(go): use load*FromID in tests Signed-off-by: Justin Chadwell <[email protected]> * sdk(typescript): use load*FromID in tests Signed-off-by: Justin Chadwell <[email protected]> * chore: use load*FromID in tests Signed-off-by: Justin Chadwell <[email protected]> --------- Signed-off-by: Justin Chadwell <[email protected]>
Signed-off-by: Alex Suraci <[email protected]>
* ci: exclude .git dir in ci build Previously, we were using this to generate a work-tree hash, so that new builds would have a different version tag, which helped to solve some weird caching issues with nested execs. However! A problem with this was that we needed to upload *the entire* git directory every time we built - which is an expensive operation, my .git directory for dagger/dagger is 147MB. Instead of relying on git for this, we can use the ID of the input directory! Because of our use of blob sources, a different ID represents a different directory. Additionally, we prefix these new builds with a special "dev-" string to specifically indicate that these are dev builds, with no specific version passed in - these aren't commit hashes, and cannot be treated as such. Signed-off-by: Justin Chadwell <[email protected]> * ci: remove dependency on go sdk The only thing this was being used for here was the connect job - we can just use `--help` to get this info to sanity check it. Signed-off-by: Justin Chadwell <[email protected]> * ci: run linting over ci itself Signed-off-by: Justin Chadwell <[email protected]> --------- Signed-off-by: Justin Chadwell <[email protected]>
Signed-off-by: Justin Chadwell <[email protected]>
Signed-off-by: kpenfound <[email protected]>
With this typo, the yaml file was invalid and so the config failed to be applied. I *finally* found where you can check the validity of a dependabot config - see https://github.com/dagger/dagger/network/updates. Signed-off-by: Justin Chadwell <[email protected]>
* chore: run dagger develop on typescript runtime Signed-off-by: Justin Chadwell <[email protected]> * fix: top-level dagger.gen.go should have correct imports Previously it wasn't, we were missing `telemetry` and `querybuilder`. And `go mod tidy` wouldn't *always* seem to pick it up, which is a bit of a pain. Signed-off-by: Justin Chadwell <[email protected]> * fix: avoid overwriting go mod/sum files on module generation This is a bit of a mess - but essentially, what *was* happening was that we had some very strange issues with go.mod generation. When generating code, we had a couple of issues: - If we were generating on top of an existing go.{mod,sum}, we were essentially replacing its contents, and then relying on `go mod tidy` to give reasonable results - however, this meant that explicitly installed dependencies were getting lost, and that we were losing the pins in the sum file. - Additionally, if we were generating a new `dagger` subfolder in an existing monorepo, we were overriding the previous go.{mod,sum} with dagger's go.{mod,sum}, and then relying on `go mod tidy` to find all the user dependencies. The main issue with the above is that we were replacing contents of these important dependency files in weird ways that make go modules much more difficult to consume, especially in monorepos. To fix these issues, we heavily rework the logic - we explicitly find the correct go.mod file we want to work on, and then apply *the same* processing everywhere. This processing involves checking go versions, adding dependencies that aren't present, merging go.sum values, etc. However - in doing this, something becomes quite apparent - we were relying on some weird undefined behavior in the Go SDK. Generally the structure of the paths passed in was that `ModuleContextPath` was a parent to `OutputDir`, and we wouldn't modify anything outside `OutputDir`. But consider, if the output directory is `./dagger` (the default), then we may need to modify the top-level `./go.mod` (that isn't in `OutputDir`). We technically *were* doing this, but by using `go mod tidy` to get it to do this magically - but as mentioned above, we need to avoid this automatic behavior, and do some better merging ourselves. To resolve this, `OutputDir` becomes the top-level, while `ModulePath` becomes a relative sub-path in `OutputDir` that the module can be found at (in the above, that's `./dagger`). This is why this patch also needs to touch the Typescript runtime files, since we change the format of the arguments to use this new format (also the Typescript generation was confusing here, so picked up a couple of refactors as well along the way). Signed-off-by: Justin Chadwell <[email protected]> * tests: fix incorrect go.{mod,work} tests - The `go.mod` test was incorrect because prior to the commit before this one, we were actually generating a `go.mod` in the child. This was *hard* to notice, because essentially, there was a weird disparity between having a `go.mod` and having a `go.mod` *and* a `main.go` in the top-level (since `loadPackage` fails on the former, but succeeds on the latter). The test is modified to ensure we can catch this in the future, and the prior commit makes sure that this weird disparity is removed. - The `go.work` tests were incorrect because we shouldn't have been putting `go.mod`s in the children (the same `loadPackage` issue as above). Each of these test cases should only have *one* module, so we alter the tests to check for this. Signed-off-by: Justin Chadwell <[email protected]> * review comments Signed-off-by: Justin Chadwell <[email protected]> --------- Signed-off-by: Justin Chadwell <[email protected]>
* chore: fix some doc comments for daqgl to match Signed-off-by: Justin Chadwell <[email protected]> * chore: remove some unused parameters And also enable a linter to catch these in the future. `unparam` seems to be optimized more heavily to avoid false positives, and is significantly better at not bringing up weird interface cases that revive seems to love. Signed-off-by: Justin Chadwell <[email protected]> * fixups Signed-off-by: Justin Chadwell <[email protected]> --------- Signed-off-by: Justin Chadwell <[email protected]>
Signed-off-by: Justin Chadwell <[email protected]>
* docs: Fix broken anchors Signed-off-by: Vikram Vaswani <[email protected]> * Fix links Signed-off-by: Vikram Vaswani <[email protected]> --------- Signed-off-by: Vikram Vaswani <[email protected]>
* docs: Add link in quickstart to private registry recipe Signed-off-by: Vikram Vaswani <[email protected]> * Fix heading Signed-off-by: Vikram Vaswani <[email protected]> * Update text Signed-off-by: Vikram Vaswani <[email protected]> --------- Signed-off-by: Vikram Vaswani <[email protected]>
tsx pushed a release an hour ago that caused all Typescript modules to
break out of band with errors like:
```
Transforming JavaScript decorators to the configured target environment
("node21.3.0") is not supported yet
```
It broke out-of-band because our install of tsx was not pinned to any
version. I pinned it now to the previous patch release and things work
again.
Hopefully there's some better way of pinning this version since it's
currently just a direct `npm install` call and not in a lock file, but
this at least fixes the problem in the immediate term.
Signed-off-by: Erik Sipsma <[email protected]>
The `export` function does `chown` cause Windows crash due to it's unsupported. This commit fixed by skip `chown` operation when running in Windows. Fixes #7558 Signed-off-by: Thanabodee Charoenpiriyakij <[email protected]>
Signed-off-by: Sam Alba <[email protected]>
* use official otel log sdk, dedupe telemetry pkg * dagger.io/dagger/telemetry is now the canonical package for integrating Dagger with OpenTelemetry (engine, CLI, Go SDK) * add engine/telemetry for engine and CLI specific telemetry (labels, cloud, engine pub/sub, etc) Signed-off-by: Alex Suraci <[email protected]> * log dialing errors Signed-off-by: Alex Suraci <[email protected]> * session: ignore SIGPIPE, don't panic if either of these happen ther CLI-side span won't be finished and telemetry won't drain. The same fix was applied recently for stdout, but I observed SIGPIPE happening on write(2) - stderr. I suspect this could still happen for stdout. My guess is it happens when the parent process goes away without waiting for the process. I couldn't find where that's happening (if it is happening), so I think the safest bet is to just drop the signal, since we should be shutting down around then anyway with stdin also being closed; might as well do it cleanly. Also, I didn't see the panic(err) become an issue, but it happens in a goroutine, which AFAIK is un-recoverable and won't run defers. Better to just log to stderr. Signed-off-by: Alex Suraci <[email protected]> * ci: test custom: configurable -count for tests Signed-off-by: Alex Suraci <[email protected]> * sdk/go: heartbeatinga (TODO replace) committing for now since I lost it at one point and it's better than nothing but really this responsibility should move outside of the SDK, probably with an exporter, in both the CLI and the engine Signed-off-by: Alex Suraci <[email protected]> * i retire Signed-off-by: Alex Suraci <[email protected]> * TODO write commit message Signed-off-by: Alex Suraci <[email protected]> * lints Signed-off-by: Alex Suraci <[email protected]> * disable test otel integration Cloud can't handle this yet, bring back later with testctx for proper instrumentation, ideally also with proper parallelism Signed-off-by: Alex Suraci <[email protected]> * wip: enable otel for tests, see if it passes after all Signed-off-by: Alex Suraci <[email protected]> * tui: show spans IDs with --debug very helpful when troubleshooting otel issues Signed-off-by: Alex Suraci <[email protected]> * plain frontend: show span IDs with --debug Signed-off-by: Alex Suraci <[email protected]> * ci: support building engine and CLI with -race for hack/dev, set RACE=1 Signed-off-by: Alex Suraci <[email protected]> * pubsub: finish draining if parent spans complete this will prevent hangs in situations where a process exits abruptly without cleaninly finishing all the spans it starts, as seems to happen with go test -failfast, but in principle could happen just about anywhere. Signed-off-by: Alex Suraci <[email protected]> * pubsub: emit to no one when no clients Signed-off-by: Alex Suraci <[email protected]> * add test for multiple clients this passes reliably against hack/dev but seems to be flaky in dagger call. still investigating. Signed-off-by: Alex Suraci <[email protected]> * assertion against error output otherwise this can false pass because --debug prints the span that sets up the code Signed-off-by: Alex Suraci <[email protected]> * frontend: show hashes with verbose=1 Signed-off-by: Alex Suraci <[email protected]> * show client ID, helps with troubleshooting Signed-off-by: Alex Suraci <[email protected]> * fix data race with ctx var capture this one is spooky - theoretically this would put a 10 minute timeout on the connection Signed-off-by: Alex Suraci <[email protected]> * withDeadlineConn: fix data race Signed-off-by: Alex Suraci <[email protected]> * include stderr when session exits poorly Signed-off-by: Alex Suraci <[email protected]> * fix frontend not printing final frame root cause of TestModuleConstructors/return_error/go Signed-off-by: Alex Suraci <[email protected]> * fix data race in heartbeating Signed-off-by: Alex Suraci <[email protected]> * move span heartbeating to Cloud exporter Signed-off-by: Alex Suraci <[email protected]> * remove unused exporter Signed-off-by: Alex Suraci <[email protected]> * lint Signed-off-by: Alex Suraci <[email protected]> * test that logs only get printed once Signed-off-by: Alex Suraci <[email protected]> * fix comments and client names Signed-off-by: Alex Suraci <[email protected]> * drain logs too, refactor logging infra * otel logging now respects Close() which sends an 'eof' log record, indicated by stdio.eof=true. * engine pub/sub now drains until it sees stdio.eof=true for each stream. this fixes the integration test which needed to seep(1s). * refactor logging helpers to reduce duplication. * retire ioctx; redundant with otel logging. still used for dagql tests though, so moved to internal. * use an attr to indicate global logs, rather than a different library using library made little sense since you'd still want to know that info from the different call sites. using an attr is the same amount of effort without overloading a field. Signed-off-by: Alex Suraci <[email protected]> * disable gocritic.ifElseChain this one is silly. switch carries subtle implications, and breaks break. don't want to have to use labels to make this linter happy. Signed-off-by: Alex Suraci <[email protected]> * client stream test: work around log limitations Signed-off-by: Alex Suraci <[email protected]> * const-ify Signed-off-by: Alex Suraci <[email protected]> * lint Signed-off-by: Alex Suraci <[email protected]> * remove accidentally-committed file Signed-off-by: Alex Suraci <[email protected]> * sdk/go: use env carrier Signed-off-by: Alex Suraci <[email protected]> * auto-refresh Cloud exporter token OTel doesn't support injecting a transport, so we have to do this from the outside. :( open-telemetry/opentelemetry-go#2632 Signed-off-by: Alex Suraci <[email protected]> * remove early client ID setup this isn't really load-bearing and raises more questions than it answers Signed-off-by: Alex Suraci <[email protected]> * fix heartbeating this was broken in two ways that canceled each other out: * deadlocked on first heartbeat * never cleared out active spans, so it'd constantly make everything 'running' Signed-off-by: Alex Suraci <[email protected]> * send function logs + spans to API call * retire dagger.io/ui.mask - white whale defeated * simplify TS/Go/Python SDKs - don't need to do the mask/passthrough dance anymore Signed-off-by: Alex Suraci <[email protected]> * pubsub: abandon child spans on completion way simpler implementation Signed-off-by: Alex Suraci <[email protected]> * python lint Signed-off-by: Alex Suraci <[email protected]> * untie ClientMetadataMetaKey knot Signed-off-by: Alex Suraci <[email protected]> * simplify otel proxy setup (*http.Server).Shutdown handles most of what we needed before Signed-off-by: Alex Suraci <[email protected]> * remove dead code Signed-off-by: Alex Suraci <[email protected]> * tui: move digests to -vvv Signed-off-by: Alex Suraci <[email protected]> * hide exec /runtime when redirecting telemetry Signed-off-by: Alex Suraci <[email protected]> * propagate log level config to engine client * reduce telemetry logs down to debug * fix debug var being clobbered via double-flag-parsing * --debug etc get parsed twice: once before function flags are learned, and again after. so we just need to pass in the current value. unfortunately --verbosity gets clobbered but that doesn't matter yet. Signed-off-by: Alex Suraci <[email protected]> * frontend: don't print blank line on EOF Signed-off-by: Alex Suraci <[email protected]> * use http.Error, nix comment Signed-off-by: Alex Suraci <[email protected]> * add sanity check to avoid infinite loop Signed-off-by: Alex Suraci <[email protected]> * link to SIGPIPE docs Signed-off-by: Alex Suraci <[email protected]> * plain: handle EOF log record for primary logs Signed-off-by: Alex Suraci <[email protected]> * plain: don't render logs if --silent Signed-off-by: Alex Suraci <[email protected]> * session: trigger exit on stdout write fail Signed-off-by: Alex Suraci <[email protected]> * simplify pub/sub client tracking * spans don't inherit their parent span's ID anymore. I don't think we actually need this, since we always step recursively through the span ancestry to collect the set of relevant client IDs. better not to funge data if we don't need to. * clean up spanDone state, not needed with new child abandonment scheme * clean up all state for a trace when all clients go away. this way we also clean up spans that don't have an associated client. Signed-off-by: Alex Suraci <[email protected]> * ci: add spans to go lint Signed-off-by: Alex Suraci <[email protected]> * fix: plain finalRender should disable the context hold Signed-off-by: Justin Chadwell <[email protected]> --------- Signed-off-by: Alex Suraci <[email protected]> Signed-off-by: Justin Chadwell <[email protected]> Co-authored-by: Justin Chadwell <[email protected]>
* ts: use multiplatform index for bun image The image sha for bun was pointing to an amd64 image, which caused failures on other platforms. Now it points to the multiplatform manifest so the right platform gets chosen. Signed-off-by: Erik Sipsma <[email protected]> * tests: fill in missing Parallel calls Noticed there were a lot of module related integ tests with missing calls to Parallel where it seemed safe to do so. Given that the actual concurrency is limited, it seems at worst harmless and at best a performance improvement to run these in parallel. Signed-off-by: Erik Sipsma <[email protected]> * ts: fix missing awaits in typescript sdk tests There were a few calls to connect that were not being awaited, which caused the test to just exit with success instantly while callbacks still ran async in the background. Signed-off-by: Erik Sipsma <[email protected]> * ts: upgrade bun version to avoid segfaults While running typescript tests locally I was getting lots of really crazy errors that caused bun to hit SIGSEGV address-out-of-bounds, SIGABRTs, etc. Googling around led to GH issues that said these problems were fixed in later versions, so I bumped us up to 1.1.12 and have not hit any more of these. Signed-off-by: Erik Sipsma <[email protected]> * ts: correctly restore env vars after test run One of the typescript tests was overriding env vars and then deleting them afterwards, which could result in the original values disappearing. I can't tell if this was an actual problem in practice at the moment, but seems safer in the long run to do this in case we ever run these tests in a nested exec, in which case this would have broken them. Signed-off-by: Erik Sipsma <[email protected]> --------- Signed-off-by: Erik Sipsma <[email protected]>
adding missing change file from 7563 Signed-off-by: Marcos Lilljedahl <[email protected]>
* ci: add sdk publish tests Signed-off-by: Justin Chadwell <[email protected]> * ci: avoid installing git on wolfi It's already installed. Signed-off-by: Justin Chadwell <[email protected]> * ci: fix dry-run test publish jobs Signed-off-by: Justin Chadwell <[email protected]> * ci: install fuzzy go version Signed-off-by: Justin Chadwell <[email protected]> --------- Signed-off-by: Justin Chadwell <[email protected]>
Signed-off-by: Thanabodee Charoenpiriyakij <[email protected]>
Signed-off-by: Alex Suraci <[email protected]>
* docs: Remove numeric ids Signed-off-by: Vikram Vaswani <[email protected]> * Update integrations pages Signed-off-by: Vikram Vaswani <[email protected]> * Fix link Signed-off-by: Vikram Vaswani <[email protected]> * Update admin manual pages Signed-off-by: Vikram Vaswani <[email protected]> * Fix link Signed-off-by: Vikram Vaswani <[email protected]> * Update redirect rule Signed-off-by: Vikram Vaswani <[email protected]> * Update user manual pages Signed-off-by: Vikram Vaswani <[email protected]> * Updated user manual pages Signed-off-by: Vikram Vaswani <[email protected]> * Update user manual Signed-off-by: Vikram Vaswani <[email protected]> * Move Google Cloud Run guide to integrations section Signed-off-by: Vikram Vaswani <[email protected]> * Removed guides component Signed-off-by: Vikram Vaswani <[email protected]> * Update GCR integration page Signed-off-by: Vikram Vaswani <[email protected]> * fix: docs linter Signed-off-by: Justin Chadwell <[email protected]> --------- Signed-off-by: Vikram Vaswani <[email protected]> Signed-off-by: Justin Chadwell <[email protected]> Co-authored-by: Justin Chadwell <[email protected]>
This will allow users to workaround the lack of pinning of tsx in previous engine releases until our next release. Signed-off-by: Erik Sipsma <[email protected]>
* hack: add legacy label conversion for old clients This allows old clients like dagger v0.10.3 to still connect to and use dagger engine v0.11.0. While this *isn't* a strict requirement, it's nice to not break this if we don't have to, and based on a couple tests, it seems like this was the only blocker for that. This is needed so we can determine legacy client versions. Signed-off-by: Justin Chadwell <[email protected]> * fix: ensure client fails out when session call fails If the main session call that was supposed to register the server fails out, there can be no recovery! No number of retries will help, so we should cancel the context. Additionally, we can manipulate the error handling logic to ensure that when the context is cancelled for this reason, that we return a *relevant* error - we can just take the last error, this is good enough. Signed-off-by: Justin Chadwell <[email protected]> * feat: introduce minimum versioning requirements With this change, we finally introduce minimum version requirements, in two parts: - Clients can enforce constraints on the minimum required server version - Servers can enforce constraints on the minimum required client version Doing this is a bit challenging. Both sides need to know what the other side's version is - thankfully, we've been doing this for a *while*. - The client can get the server version through the Buildkit client.Info call (where we've been attaching this data since v0.9.0). - The server can get the client version info through old telemetry labels (after explicitly handling old-style telemetry labels), or through a newly introduced ClientMetadata field. With this new data, we can enforce version constraints! However, in the case of the server-side version constraints for the client, we hit a slightly weird case - the client got stuck in a retry loop when the Session failed to start. This isn't quite right behavior anyways (any error from the main Session call that starts a server wouldn't cause an immediate failure), it just appeared when we try and display version constraints. We can easily fix this going forwards - on older clients, we just get the failure logs, the retry will still occur, and we fail about 5 minutes. Signed-off-by: Justin Chadwell <[email protected]> * tests: add test for checking version compatibility Signed-off-by: Justin Chadwell <[email protected]> * docs: add backwards compatability notes to RELEASING Signed-off-by: Justin Chadwell <[email protected]> --------- Signed-off-by: Justin Chadwell <[email protected]>
* chore: add DAGGER_COMMIT option to install.sh This allows installing an arbitrary commit from main, to make it easier to install versions from main for testing. Signed-off-by: Justin Chadwell <[email protected]> * fix: ensure install.ps1 keeps working on windows Signed-off-by: Justin Chadwell <[email protected]> --------- Signed-off-by: Justin Chadwell <[email protected]>
* chore: update alpine base to 3.20 Signed-off-by: Justin Chadwell <[email protected]> * tests: don't require specific squid proxy version Signed-off-by: Justin Chadwell <[email protected]> * ci: bump go to 1.22.4 Also, we can remove the runc hack - go 1.22.4 includes a backported fix for the pthreads issue that upstream was encountering. Signed-off-by: Justin Chadwell <[email protected]> --------- Signed-off-by: Justin Chadwell <[email protected]>
While we are keeping this default so that we don't break existing users, setting this value is something that we want to move away from. The problem is that this setting limits how many operations can run in parallel. It is still possible for a single operation to max out all available cores. It is also known for a value of `2` to cause deadlocks, i.e. dagger/dagger#6894 For now, we just allow this to be disabled with either `--set engine.args=''` or by explicitly setting this value to an empty list. This started as dagger/dagger#7395 which turned out to be too big of a change. We since scaled back the initial ambition & are taking a smaller step towards eventually phasing this out. FWIW, all the Dagger Engines that we run inside the Dagger infra do not use the `--oci-max-parallelism` option. This also removes the option from tekton-dagger-task docs example. Signed-off-by: Gerhard Lazu <[email protected]>
This has been reported to happen intermittently by a few users. The error originates from gqlgen and suggests that something in the http request is unhandled; it basically tries to find a matching pattern for gql requests based on http method and some headers. It's unclear how this could happen only occasionally and I've never seen this myself yet, so I think our best bet is to log the parts of the request checked by gqlgen and wait for it to get hit again. Signed-off-by: Erik Sipsma <[email protected]>
Bumps [rustls](https://github.com/rustls/rustls) from 0.21.10 to 0.21.12. - [Release notes](https://github.com/rustls/rustls/releases) - [Changelog](https://github.com/rustls/rustls/blob/main/CHANGELOG.md) - [Commits](rustls/rustls@v/0.21.10...v/0.21.12) --- updated-dependencies: - dependency-name: rustls dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* close service logs too Signed-off-by: Alex Suraci <[email protected]> * telemetry: fix tunnel log draining and other missing closes I was still having to wait 5 minutes for OTEL logs to drain on some test runs that involved service tunneling. I believe there was a race condition where the tunnel code could end up writing logs after they were closed, which seems to create a leak and cause us to have to wait 5 minutes before a timeout is hit. I also saw a few other place otel logs were created and not closed, so added a close there too. Signed-off-by: Erik Sipsma <[email protected]> * unify on slog, focus draining on stdio use case * SpanLogger no longer writes to stdio streams, since it's unclear at each logging site who has responsibility to Close(); this way no one does. * switch last few holdouts to slog - for better or for worse, we should be consistent and iterate. We've started using slog for client-side logs, so we might as well adopt them server-side too. Signed-off-by: Alex Suraci <[email protected]> * propagate debug/no-color mode to server uses otel baggage, which I thankfully already went through the trouble of propagating, and hadn't used yet. neat! Signed-off-by: Alex Suraci <[email protected]> --------- Signed-off-by: Alex Suraci <[email protected]> Signed-off-by: Erik Sipsma <[email protected]> Co-authored-by: Erik Sipsma <[email protected]>
When an exec fails due to context canceled, we were dropping the cancelation error and just returning the exec error. I believe this got fat-fingered while updating the code from upstream to use fmt.Errorf instead of github.com/pkg/errors. It's not clear if this is really meaningful, but noticed it changed while attempting to debug occurances of "exit code 137" in our CI, which plausibly could be related to all of this. It's possible there's calling code that tries to handle cancelation with errors.Is, which this would have broken. This is purely hypothetical at this point though. Signed-off-by: Erik Sipsma <[email protected]>
There was a race condition where contexts get canceled after a job is sent to the netns worker but before the result got read. This caused runInNetNS to exit (due to canceled context) but the result chan to never be read from. It was crucially an unbuffered chan, which resulted in the worker never being able to exit and the whole container cleanup to block indefinitely. The fix here is just to make that chan buffered with a size of 1 so that the worker doesn't ever get blocked trying to write to it. There's a few other related changes of making some other chans buffered and explicitly closing them with a defer (to handle panic cases) which aren't needed to fix this issue but seemed worth tidying up now. Signed-off-by: Erik Sipsma <[email protected]>
* fix: ensure nested frontend builds get secret translation When doing a nested frontend build - i.e. when dockerfile.v0 calls gateway.v0 (triggered by a syntax directive), we need to ensure that the second frontend gets the same secret translation as each prior layer. To do this, we heavily refactor the filtering gateway and essentially have it pass itself into the frontend Solve - this propagates the filtering all the way down, so secrets can be correctly accessed. Signed-off-by: Justin Chadwell <[email protected]> * tests: add test for remote frontend Signed-off-by: Justin Chadwell <[email protected]> * chore: add changelog Signed-off-by: Justin Chadwell <[email protected]> --------- Signed-off-by: Justin Chadwell <[email protected]>
Bumps the sdk-java group in /sdk/java with 2 updates: [org.assertj:assertj-core](https://github.com/assertj/assertj) and [org.codehaus.mojo:exec-maven-plugin](https://github.com/mojohaus/exec-maven-plugin). Updates `org.assertj:assertj-core` from 3.25.0 to 3.26.0 - [Release notes](https://github.com/assertj/assertj/releases) - [Commits](assertj/assertj@assertj-build-3.25.0...assertj-build-3.26.0) Updates `org.codehaus.mojo:exec-maven-plugin` from 3.2.0 to 3.3.0 - [Release notes](https://github.com/mojohaus/exec-maven-plugin/releases) - [Commits](mojohaus/exec-maven-plugin@3.2.0...3.3.0) --- updated-dependencies: - dependency-name: org.assertj:assertj-core dependency-type: direct:development update-type: version-update:semver-minor dependency-group: sdk-java - dependency-name: org.codehaus.mojo:exec-maven-plugin dependency-type: direct:production update-type: version-update:semver-minor dependency-group: sdk-java ... Signed-off-by: dependabot[bot] <[email protected]>
|
The following labels could not be found: |
|
This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests. To ignore these dependencies, configure ignore rules in dependabot.yml |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bumps the sdk-java group in /sdk/java with 2 updates: org.assertj:assertj-core and org.codehaus.mojo:exec-maven-plugin.
Updates
org.assertj:assertj-corefrom 3.25.0 to 3.26.0Release notes
Sourced from org.assertj:assertj-core's releases.
... (truncated)
Commits
b7aae03[maven-release-plugin] prepare release assertj-build-3.26.0be4cf7cAddisUnmodifiabletoIteratorassertions (#3477)6e760dbchore(deps-dev): bump org.springframework:spring-core from 5.3.35 to 5.3.36 (...29d2bbechore(deps): bump byte-buddy.version from 1.14.15 to 1.14.16 (#3487)97b642aRebuild default date formats used to parse string as dates when the default t...9eeb352Refactor tests covering date string conversion9707d51chore(deps): bump kotlin.version from 1.9.24 to 2.0.0 (#3484)6bab517chore(deps-dev): bump org.hibernate.orm:hibernate-core from 6.5.1.Final to 6....5f70fecReduce Qodana verbosity in PRs99f2991FixInstantconversion withDateassertions (#3467)Updates
org.codehaus.mojo:exec-maven-pluginfrom 3.2.0 to 3.3.0Release notes
Sourced from org.codehaus.mojo:exec-maven-plugin's releases.
Commits
366da2f[maven-release-plugin] prepare release 3.3.0416c83aBump org.codehaus.mojo:mojo-parent from 80 to 82 (#429)8d3327fBump org.codehaus.plexus:plexus-utils from 4.0.0 to 4.0.1662ab09Bump asm.version from 9.6 to 9.7ec97f4dAdd "provided" classpathScope (runtime+provided)d18ed80Bump apache/maven-gh-actions-shared from 3 to 4f19bde1[maven-release-plugin] prepare for next development iterationDependabot 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 can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions