Add error handling for package updates in workflow

[joperezr]

Description

Sometimes dotnet outdated tool can return an error exit code if one of the dependencies failed to be updated (could be for different reasons). This change makes it so that even if some dependencies are unable to be updated, the workflow will continue to run and update the rest of the dependencies.

cc: @eerhardt @radical

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
• Are you including unit tests for the changes and scenario tests if relevant?
  • No
• Did you add public API?
  • No
• Does the change make any security assumptions or guarantees?
  • No
• Does the change require an update in our Aspire docs?
  • No

[Copilot]

Pull Request Overview

This PR updates the dependency update workflow to handle errors gracefully when dotnet outdated fails to update one or more dependencies.

• Adds "continue-on-error: true" to the "Update packages" step.
• Adds a fallback echo message in case dotnet outdated fails.

Comments suppressed due to low confidence (1)

.github/workflows/update-dependencies.yml:34

• Consider logging more detailed information about the failure rather than a generic message, as this may help with troubleshooting dependency update issues.

run: dotnet outdated --no-restore -u ./Aspire.sln || echo "Some dependencies could not be updated, but continuing workflow."

[radical]

Sometimes dotnet outdated tool can return an error exit code if one of the dependencies failed to be updated (could be for different reasons). This change makes it so that even if some dependencies are unable to be updated, the workflow will continue to run and update the rest of the dependencies.

What kind of failures can these be? Do they need to be looked at by somebody? Can we add details of this error on the PR as a comment?

[joperezr]

What kind of failures can these be? Do they need to be looked at by somebody? Can we add details of this error on the PR as a comment?

Some projects dual-target for net8 and net9, and we have some special constraints forcing a specific major version for them, and dotnet outdated won't respect this and try to update anyway but that will result in a failure, causing it to roll back that upgrade for that project. We could also be subject in the future of issues where packages put dependency constraints and those would also result in a failure.

You do raise an interesting point which is that we do want to know when some updates fail, I'll see if I can add something to the PR description when this happens.