fix: don't abort on failure for 'comp update' and 'comp refresh-upstream-commit'

[Dan Streetman (ddstreet)]

When using 'comp update -a' or '--without-lockfile comp refresh-upstream-commit -a', a failure of any single component will abort the entire process, instead of completing as many as possible and then reporting which components failed. This fixes that behavior to process all components that don't fail the update/refresh, and report any failing components.

[Copilot]

Copilot review overview

🟡 Changes recommended

A couple of newly introduced user-facing messages/help text are misleading in edge cases (e.g., “successful files were updated” when all components fail, and ambiguity with '--check-only').

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 2

Open (2)

• Qualify help text about writes in check-only mode · New
• Clarify lock file writes are skipped in check-only mode · New

What changed in this PR

This PR changes the azldev component update and azldev --without-lockfile component refresh-upstream-commit workflows so that, when running across many components (-a / include-all), a failure in one component no longer aborts the entire run. Instead, the commands preserve successful per-component outputs, then return an aggregated error listing the failing components (and skip orphan pruning on partial failure).

Changes:

• Stop cancelling parallel resolution on first component failure; continue resolving remaining components.
• Save successful lock/TOML outputs even when other components fail, then return an aggregate error.
• Add unit tests validating partial-success behavior; update user-facing text/docs to describe the new semantics.

File	Description
internal/​app/​azldev/​cmds/​component/​update.go	Writes successful lock updates before returning aggregate error; no longer cancels remaining work on first failure.
internal/​app/​azldev/​cmds/​component/​update_test.go	Adds coverage for continuing after per-component resolution errors and preserving successful lock writes.
internal/​app/​azldev/​cmds/​component/​refreshupstreamcommit.go	Mirrors update behavior for upstream-commit TOML generation (partial save + aggregate error).
internal/​app/​azldev/​cmds/​component/​refreshupstreamcommit_resolution_test.go	Adds tests ensuring refresh continues after component errors and saves successes.
docs/​user/​reference/​cli/​azldev_component_update.md	Updates CLI reference text to reflect partial-success behavior.
docs/​user/​how-to/​preview-without-lockfile.md	Documents partial-success refresh behavior when resolving multiple components.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

Several newly added/modified lines are likely to fail the repo’s enabled lll linter and a couple of updated aggregate error messages can be misleading in common “no files actually written” cases.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 2

Open (2)

• Wrap refresh help text lines to satisfy lll · New
• Wrap long fmt.Errorf line to satisfy lll · New

Resolved since last review (2)

• Clarify lock file writes are skipped in check-only mode
• Qualify help text about writes in check-only mode

[Copilot]

Copilot review overview

🔵 Needs a closer look

The new aggregate error messages can incorrectly claim files “were updated” even when no writes occurred (e.g., all non-failing components were already up-to-date).

Review effort: Lite
Findings: None

Resolved since last review (2)

• Wrap long fmt.Errorf line to satisfy lll
• Wrap refresh help text lines to satisfy lll

Previously missed (2)

In code that hasn't changed since last review

Avoid claiming upstream commit TOML files were updated unconditionally

internal/​app/​azldev/​cmds/​component/​refreshupstreamcommit.go:458

This message unconditionally states successful upstream commit TOML files were updated, but if the non-failing components were already current there may be nothing to write. Consider using wording that doesn’t claim disk updates definitely happened.

Avoid claiming lock files were updated when no writes occurred

internal/​app/​azldev/​cmds/​component/​update.go:647

The error message here unconditionally says successful lock files were updated, but this function doesn't know whether any writes actually occurred (e.g., the only non-failing components could already be up-to-date or unchanged). Consider wording this more defensively to avoid misleading users.