deps: Bump the all-nuget group with 3 updates#115
Merged
Conversation
Bumps Aspire.Hosting.PostgreSQL from 13.4.0 to 13.4.2 Bumps Aspire.Hosting.RabbitMQ from 13.4.0 to 13.4.2 Bumps Aspire.Hosting.Redis from 13.4.0 to 13.4.2 --- updated-dependencies: - dependency-name: Aspire.Hosting.PostgreSQL dependency-version: 13.4.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: all-nuget - dependency-name: Aspire.Hosting.RabbitMQ dependency-version: 13.4.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: all-nuget - dependency-name: Aspire.Hosting.Redis dependency-version: 13.4.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: all-nuget ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Contributor
Test Results118 tests 118 ✅ 6s ⏱️ Results for commit cefdb7f. |
Contributor
🔍 PR Validation ResultsVersion: 📦 Detected NuGet Packages (17)
🚀 Detected Executables (2)
✅ Validation Steps
📊 ArtifactsDry-run artifacts have been uploaded and will be available for 7 days. This comment was automatically generated by the PR validation workflow. |
This file contains hidden or 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
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.
Updated Aspire.Hosting.PostgreSQL from 13.4.0 to 13.4.2.
Release notes
Sourced from Aspire.Hosting.PostgreSQL's releases.
13.4.2
What's New in Aspire 13.4.2
Patch release for Aspire 13.4 with a fix for Redis persistent container deadlock on startup when using TLS.
🐛 Fixes
WithLifetime(ContainerLifetime.Persistent)could deadlock on startup — Redis TLS startup arguments used the public/allocated host ports instead of the internal target ports. When the public port differed from the target port (or was not yet allocated) the container would listen on an unexpected port and become unreachable. The TLS and non-TLS startup arguments now bind to target ports, matching what Redis expects internally. Fixes #17822. (#17827, backported via #17850,@danegsta)🏷️ Housekeeping
Full Changelog: microsoft/aspire@v13.4.1...v13.4.2
Full commit: d7d0b6759ce4b936c76bc4775814d27db560dd6d
13.4.1
What's New in Aspire 13.4.1
Patch release for Aspire 13.4 with fixes for explicit-start resource lifecycle callbacks, Redis persistent container startup, proxyless endpoint allocation, and a duplicated
profilesblock in the empty C# AppHost template.🐛 Fixes
WithExplicitStart()were having their execution configuration callbacks (environment variables, arguments, certificates) evaluated at AppHost startup instead of at manual start. This meant user-interaction callbacks such asWithEnvironment(ctx => PromptForValueAsync(...))were called before the user triggered the resource. DCP registration is now deferred until the user manually starts the resource; persistent explicit-start resources still register immediately but patch the existing DCP record toStart = truerather than deleting and recreating it. Fixes #17813. (#17825, backported via #17826,@danegsta)WithLifetime(ContainerLifetime.Persistent)could deadlock on startup — Redis TLS startup arguments used the public/allocated host ports instead of the internal target ports. When the public port differed from the target port (or was not yet allocated) the container would listen on an unexpected port and become unreachable. The TLS and non-TLS startup arguments now bind to target ports, matching what Redis expects internally. Fixes #17822. (#17827, backported via #17850,@danegsta)BuildContainerPortsruns, normal DCP dynamic port assignment takes over for any later resolution. (#17851, backported via #17859,@danegsta)profilesblock —aspire new aspire-emptyon 13.4 produced anaspire.config.jsonwith aprofilesblock that duplicated the content already present inapphost.run.json, causing redundant launch configuration. The embedded template now contains only the requiredappHost.pathbinding; profile configuration lives exclusively inapphost.run.json. Fixes #17660. (#17781, backported via #17820,@mitchdenny)🏷️ Housekeeping
@adamint)Full Changelog: microsoft/aspire@v13.4.0...v13.4.1
Full commit: cf985fa817dd5863e7f62eb74fa1725ab5069ed2
Commits viewable in compare view.
Updated Aspire.Hosting.RabbitMQ from 13.4.0 to 13.4.2.
Release notes
Sourced from Aspire.Hosting.RabbitMQ's releases.
13.4.2
What's New in Aspire 13.4.2
Patch release for Aspire 13.4 with a fix for Redis persistent container deadlock on startup when using TLS.
🐛 Fixes
WithLifetime(ContainerLifetime.Persistent)could deadlock on startup — Redis TLS startup arguments used the public/allocated host ports instead of the internal target ports. When the public port differed from the target port (or was not yet allocated) the container would listen on an unexpected port and become unreachable. The TLS and non-TLS startup arguments now bind to target ports, matching what Redis expects internally. Fixes #17822. (#17827, backported via #17850,@danegsta)🏷️ Housekeeping
Full Changelog: microsoft/aspire@v13.4.1...v13.4.2
Full commit: d7d0b6759ce4b936c76bc4775814d27db560dd6d
13.4.1
What's New in Aspire 13.4.1
Patch release for Aspire 13.4 with fixes for explicit-start resource lifecycle callbacks, Redis persistent container startup, proxyless endpoint allocation, and a duplicated
profilesblock in the empty C# AppHost template.🐛 Fixes
WithExplicitStart()were having their execution configuration callbacks (environment variables, arguments, certificates) evaluated at AppHost startup instead of at manual start. This meant user-interaction callbacks such asWithEnvironment(ctx => PromptForValueAsync(...))were called before the user triggered the resource. DCP registration is now deferred until the user manually starts the resource; persistent explicit-start resources still register immediately but patch the existing DCP record toStart = truerather than deleting and recreating it. Fixes #17813. (#17825, backported via #17826,@danegsta)WithLifetime(ContainerLifetime.Persistent)could deadlock on startup — Redis TLS startup arguments used the public/allocated host ports instead of the internal target ports. When the public port differed from the target port (or was not yet allocated) the container would listen on an unexpected port and become unreachable. The TLS and non-TLS startup arguments now bind to target ports, matching what Redis expects internally. Fixes #17822. (#17827, backported via #17850,@danegsta)BuildContainerPortsruns, normal DCP dynamic port assignment takes over for any later resolution. (#17851, backported via #17859,@danegsta)profilesblock —aspire new aspire-emptyon 13.4 produced anaspire.config.jsonwith aprofilesblock that duplicated the content already present inapphost.run.json, causing redundant launch configuration. The embedded template now contains only the requiredappHost.pathbinding; profile configuration lives exclusively inapphost.run.json. Fixes #17660. (#17781, backported via #17820,@mitchdenny)🏷️ Housekeeping
@adamint)Full Changelog: microsoft/aspire@v13.4.0...v13.4.1
Full commit: cf985fa817dd5863e7f62eb74fa1725ab5069ed2
Commits viewable in compare view.
Updated Aspire.Hosting.Redis from 13.4.0 to 13.4.2.
Release notes
Sourced from Aspire.Hosting.Redis's releases.
13.4.2
What's New in Aspire 13.4.2
Patch release for Aspire 13.4 with a fix for Redis persistent container deadlock on startup when using TLS.
🐛 Fixes
WithLifetime(ContainerLifetime.Persistent)could deadlock on startup — Redis TLS startup arguments used the public/allocated host ports instead of the internal target ports. When the public port differed from the target port (or was not yet allocated) the container would listen on an unexpected port and become unreachable. The TLS and non-TLS startup arguments now bind to target ports, matching what Redis expects internally. Fixes #17822. (#17827, backported via #17850,@danegsta)🏷️ Housekeeping
Full Changelog: microsoft/aspire@v13.4.1...v13.4.2
Full commit: d7d0b6759ce4b936c76bc4775814d27db560dd6d
13.4.1
What's New in Aspire 13.4.1
Patch release for Aspire 13.4 with fixes for explicit-start resource lifecycle callbacks, Redis persistent container startup, proxyless endpoint allocation, and a duplicated
profilesblock in the empty C# AppHost template.🐛 Fixes
WithExplicitStart()were having their execution configuration callbacks (environment variables, arguments, certificates) evaluated at AppHost startup instead of at manual start. This meant user-interaction callbacks such asWithEnvironment(ctx => PromptForValueAsync(...))were called before the user triggered the resource. DCP registration is now deferred until the user manually starts the resource; persistent explicit-start resources still register immediately but patch the existing DCP record toStart = truerather than deleting and recreating it. Fixes #17813. (#17825, backported via #17826,@danegsta)WithLifetime(ContainerLifetime.Persistent)could deadlock on startup — Redis TLS startup arguments used the public/allocated host ports instead of the internal target ports. When the public port differed from the target port (or was not yet allocated) the container would listen on an unexpected port and become unreachable. The TLS and non-TLS startup arguments now bind to target ports, matching what Redis expects internally. Fixes #17822. (#17827, backported via #17850,@danegsta)BuildContainerPortsruns, normal DCP dynamic port assignment takes over for any later resolution. (#17851, backported via #17859,@danegsta)profilesblock —aspire new aspire-emptyon 13.4 produced anaspire.config.jsonwith aprofilesblock that duplicated the content already present inapphost.run.json, causing redundant launch configuration. The embedded template now contains only the requiredappHost.pathbinding; profile configuration lives exclusively inapphost.run.json. Fixes #17660. (#17781, backported via #17820,@mitchdenny)🏷️ Housekeeping
@adamint)Full Changelog: microsoft/aspire@v13.4.0...v13.4.1
Full commit: cf985fa817dd5863e7f62eb74fa1725ab5069ed2
Commits viewable in compare view.
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 rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@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