Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): bump @adobe/css-tools from 4.0.1 to 4.4.0 in /sdk/rust/crates/dagger-sdk/examples/test-the-application/app #8

Conversation

dependabot[bot]
Copy link
Contributor

@dependabot dependabot bot commented on behalf of github Jun 11, 2024

Bumps @adobe/css-tools from 4.0.1 to 4.4.0.

Changelog

Sourced from @​adobe/css-tools's changelog.

4.4.0 / 2024-06-05

4.3.3 / 2024-01-24

  • Update export property #271

4.3.2 / 2023-11-28

  • Fix redos vulnerability with specific crafted css string - CVE-2023-48631
  • Fix Problem parsing with :is() and nested :nth-child() #211

4.3.1 / 2023-03-14

  • Fix redos vulnerability with specific crafted css string - CVE-2023-26364

4.3.0 / 2023-03-07

  • Update build tools
  • Update exports path and files

4.2.0 / 2023-02-21

4.1.0 / 2023-01-25

  • Support ESM Modules

4.0.2 / 2023-01-12

  • #71 : @​import does not work if url contains ';'
  • #77 : Regression in selector parsing: Attribute selectors not parsed correctly
Commits

Dependabot compatibility score

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 can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    You can disable automated security fix PRs for this repo from the Security Alerts page.

lukemarsden and others added 30 commits April 26, 2024 23:20
* 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]>
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]>
* 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]>
* 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]>
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]>
* 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]>
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]>
sipsma and others added 24 commits June 7, 2024 10:51
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]>
* 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]>
* 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]>
The tsx issue has been fixed so this isn't needed anymore. Worst case if
something else pops up this SDK would still be usable by it's git commit
ref, so may as well remove it now.

Signed-off-by: Erik Sipsma <[email protected]>
Bumps [@adobe/css-tools](https://github.com/adobe/css-tools) from 4.0.1 to 4.4.0.
- [Changelog](https://github.com/adobe/css-tools/blob/main/History.md)
- [Commits](https://github.com/adobe/css-tools/commits)

---
updated-dependencies:
- dependency-name: "@adobe/css-tools"
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>
@dependabot dependabot bot added dependencies Pull requests that update a dependency file javascript Pull requests that update Javascript code labels Jun 11, 2024
@dagger-ci dagger-ci closed this Jun 12, 2024
Copy link
Contributor Author

dependabot bot commented on behalf of github Jun 12, 2024

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

@dependabot dependabot bot deleted the dependabot/npm_and_yarn/sdk/rust/crates/dagger-sdk/examples/test-the-application/app/adobe/css-tools-4.4.0 branch June 12, 2024 10:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file javascript Pull requests that update Javascript code
Projects
None yet
Development

Successfully merging this pull request may close these issues.