Module helm - Update dependency dagger/dagger to v0.18.6 #79
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.
This PR contains the following updates:
v0.18.5
->v0.18.6
Release Notes
dagger/dagger (dagger/dagger)
v0.18.6
Compare Source
🔥 Breaking Changes
Cache URI-based secrets based on their plaintext value rather than the URI by @sipsma in https://github.com/dagger/dagger/pull/10311
Previously, the "cache key" for URI-based secrets (e.g.
env://FOO
,file:///some/path
, etc.) was the URI string. This meant that operations including the secret (e.g. as an environment variable in a Container) would be cached based on the URI value. If two secrets from different clients had the same URI but different plaintext values, cache for operations that include them would be shared.In many cases, even when URIs were the same, the plaintext of secrets could be meaningfully different, which made this behavior surprising and lead to unexpected results.
Now, URI-based secrets are cached based on secure hashes of their plaintext value. Two secrets that have the same URI but different plaintext values will be cached separately, and operations that include them will not share cache.
However, there are cases where users do want secrets with different plaintexts to share cache, e.g. secrets that rotate in plaintext value frequently but aren't meaningfully different and thus shouldn't bust the cache of operations that include them.
To continue supporting those use cases, there is a new optional
cacheKey
argument toSecret
that can be used to specify a custom cache key. If provided, the cache key will be used instead of the default plaintext-based cache key, allowing any secrets sharing that cache-key to be cached together.SDKs can provide this as an optional argument to the
Secret
constructor. Other example usages:dagger shell:
dagger shell -c "some-function --secret-arg $(secret env://FOO --cache-key my-cache-key)"
dagger call (supports a special syntax that sets the cache key via a query param in the URI):
dagger call some-function --secret-arg env://FOO?cacheKey=my-cache-key
Added
GitRepository.branches
API by @jedevc in https://github.com/dagger/dagger/pull/10250File
top-level field added to allow easier creation ofFile
objects by @jedevc in https://github.com/dagger/dagger/pull/10290Fixed
GitRepository.tags
patterns
arg is now respected for local git repositories by @jedevc in https://github.com/dagger/dagger/pull/10250dagger call
by @helderco in https://github.com/dagger/dagger/pull/10305Container.build
with a Dockerfile that isFROM scratch
by @sipsma in https://github.com/dagger/dagger/pull/10332What to do next?
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.