chore(deps): update actions/upload-artifact action to v6

[thomhurst]

This PR contains the following updates:

Package	Type	Update	Change
actions/upload-artifact	action	major	v5 -> v6
actions/upload-artifact	action	major	v5.0.0 -> v6.0.0

---

Release Notes

actions/upload-artifact (actions/upload-artifact)

v6

Compare Source

---

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 these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[claude]

PR Review: Update actions/upload-artifact to v6

Summary

This PR updates the actions/upload-artifact action from v5 to v6 across two workflow files. The changes are straightforward dependency updates managed by Renovate Bot.

✅ Code Quality & Best Practices

• Consistent updates: All 14 instances have been updated uniformly (v5 → v6 and v5.0.0 → v6.0.0)
• Proper versioning: Uses explicit version tags for reproducibility
• Good practice: Renovate Bot ensures systematic dependency management

🔍 Potential Issues & Concerns

1. Artifact Name Collisions (CRITICAL for matrix builds)

Location: .github/workflows/dotnet.yml:112-127

The workflow runs on a matrix with 3 OS environments (ubuntu-latest, windows-latest, macos-latest). Important v6 change: Artifacts with the same name now overwrite each other instead of failing.

Current artifact names:

• TestingPlatformDiagnosticLogs${{matrix.os}}
• HangDump${{matrix.os}}
• NuGetPackages-${{matrix.os}}

✅ Good news: Your artifact names already include ${{matrix.os}} suffix, so they're unique per OS and won't overwrite each other. This is the recommended pattern for v6.

2. Breaking Changes in v6

According to the upload-artifact v6 documentation, key changes include:

• Artifacts with the same name now overwrite instead of error (doesn't affect this PR due to unique names)
• Updated runtime to Node.js 20
• Improved performance with artifact registry backend

3. Retention Days Compatibility

Location: .github/workflows/speed-comparison.yml

The workflow specifies retention-days: 90 for benchmark artifacts and retention-days: 1 for test builds. These should work fine with v6 (supports 1-90 days for free tier, up to 400 for enterprise).

🔒 Security

• ✅ Using official GitHub Actions from verified publisher
• ✅ Explicit version pinning (v6.0.0) provides supply chain security
• ✅ No credential exposure concerns

⚡ Performance

• ✅ v6 uses the new artifact registry backend with improved upload/download speeds
• ✅ Better compression and chunking strategies
• ✅ Should see performance improvements, especially for large artifacts

🧪 Test Coverage

Recommendation: While this is a dependency update, consider:

1. ✅ Automated testing: The workflows will naturally test themselves when they run
2. ⚠️ Monitor first runs: Watch the first few workflow runs after merge to ensure artifacts are uploaded/downloaded correctly
3. ✅ Artifact accessibility: Verify that artifacts are accessible and downloadable after the update

📋 Checklist Alignment with CLAUDE.md

• ✅ No source generator changes (N/A)
• ✅ No public API changes (N/A)
• ✅ No dual-mode implementation needed (N/A)
• ✅ No performance-critical code paths affected directly
• ✅ Follows modern practices (explicit versioning)

🎯 Final Verdict

LGTM ✅ - Recommend approval with monitoring

This is a well-structured dependency update. The changes are:

• ✅ Safe to merge
• ✅ Artifact naming already follows v6 best practices
• ✅ Should improve workflow performance
• ✅ No breaking changes for this codebase's usage patterns

Action items post-merge:

1. Monitor the first few workflow runs to ensure artifacts upload successfully
2. Verify artifact downloads work correctly (especially in the process-and-upload-benchmarks job)
3. Watch for any unexpected behavior in the artifact retention

---

Reviewed by: Claude Code Agent
Review Date: 2025-12-12
PR: #4071

[Copilot]

Pull request overview

This PR updates the actions/upload-artifact GitHub Action from v5 to v6 across workflow files. The update is automated by Renovate Bot and maintains existing version format conventions (major version tags for speed-comparison.yml, specific versions for dotnet.yml). All artifact uploads use unique names in matrix strategies, ensuring compatibility with v6's artifact merging behavior.

Key Changes:

• Updated all actions/upload-artifact references from v5.x to v6.x
• No configuration changes needed - existing artifact naming patterns are compatible with v6

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
.github/workflows/speed-comparison.yml	Updated 11 occurrences of actions/upload-artifact@v5 to @v6 for benchmark artifact uploads
.github/workflows/dotnet.yml	Updated 3 occurrences of actions/[email protected] to @v6.0.0 for diagnostic logs, hang dumps, and NuGet package artifacts

[claude]

Pull Request Review: Update actions/upload-artifact to v6

Summary

This PR updates the actions/upload-artifact GitHub Action from v5 to v6 across two workflow files. The changes are straightforward dependency updates with no functional code modifications.

Positive Observations

1. Consistency: All instances of upload-artifact have been updated uniformly - dotnet.yml has 3 instances updated (v5.0.0 to v6.0.0) and speed-comparison.yml has 11 instances updated (v5 to v6)

2. Proper Versioning: The main workflow uses the specific patch version (v6.0.0) while the speed comparison workflow uses the major version tag (v6), which is acceptable for both stability and auto-updates respectively.

3. Backward Compatibility: The existing workflow configurations remain unchanged - all parameters (name, path, retention-days, if: always()) are preserved, indicating good backward compatibility in the v6 action.

Considerations and Recommendations

1. Potential Breaking Changes

While the diff shows no parameter changes, upload-artifact v6 introduced some notable changes:

• Node.js 20 requirement: v6 runs on Node.js 20 (v5 used Node.js 16)
• Artifact naming: v6 may handle artifact names differently in matrix builds

Recommendation: The matrix builds in dotnet.yml use dynamic naming. Verify that artifacts from different OS matrices (ubuntu-latest, windows-latest, macos-latest) are uploaded correctly without conflicts.

2. Matrix Build Artifact Naming Concern

In .github/workflows/dotnet.yml (lines 108-127), artifacts are uploaded with OS-specific names. If v6 has stricter naming requirements or different handling of concurrent uploads from matrix jobs, this could cause issues.

Recommendation: After merging, verify in the workflow run that all 3 OS variants upload successfully and artifacts are accessible separately.

3. Version Pinning Strategy

The codebase uses two different versioning approaches:

• dotnet.yml: Pinned to exact version (v6.0.0)
• speed-comparison.yml: Major version tag (v6)

Observation: This is actually a good mixed strategy - production workflows use exact versions for stability, while scheduled/internal workflows use major versions for automatic patches.

Security Considerations

No security concerns identified:

• Using official GitHub Actions from actions/ organization
• No new permissions or tokens introduced
• No changes to artifact content or access patterns

Testing Recommendations

Before merging (or in first run after merge), verify:

1. Matrix job artifacts: Confirm all 3 OS variants upload successfully
2. Artifact availability: Verify artifacts can be downloaded (TestingPlatformDiagnosticLogs, HangDump, NuGetPackages for all 3 OS, plus all benchmark artifacts)
3. Retention policies: Confirm retention-days settings are respected (90 days for benchmarks, default for others)

Performance Considerations

No performance concerns:

• Artifact upload is not in the critical path
• Node.js 20 (v6) may actually be faster than Node.js 16 (v5)
• No changes to artifact sizes or compression

Code Quality

Excellent:

• Clean, focused change
• Automated by Renovate Bot (consistent updates)
• No unnecessary modifications

Final Verdict

LGTM with minor observation

This is a clean dependency update that follows best practices. The only consideration is to verify matrix job artifact uploads work correctly after deployment, which is a standard post-merge verification rather than a blocking issue.

Suggested merge strategy:

• Enable auto-merge (as configured in Renovate)
• Monitor the first workflow run after merge
• Check that all matrix artifacts are created successfully

---

Review conducted according to TUnit CLAUDE.md guidelines. No snapshot updates, dual-mode implementation, or public API changes required for this infrastructure change.

[claude]

Pull Request Review: actions/upload-artifact v5 → v6 Upgrade

✅ Overall Assessment

This is a safe and straightforward dependency update. The PR correctly upgrades actions/upload-artifact from v5 to v6 across all workflow files.

---

📋 Code Quality & Best Practices

Strengths:

• ✅ Consistent version updates across all usages (v5 → v6 and v5.0.0 → v6.0.0)
• ✅ No breaking changes in how the action is used (all parameters remain compatible)
• ✅ Artifact names use matrix variables (${{matrix.os}}, ${{matrix.class}}) to avoid name collisions—this is critical for v6

Code locations:

• .github/workflows/dotnet.yml: 3 artifact uploads (lines 108, 115, 122)
• .github/workflows/speed-comparison.yml: 11 artifact uploads (various lines)

---

🔍 Potential Issues & Considerations

1. Artifact Name Uniqueness (Critical for v6)

✅ PASS - The workflows correctly use unique artifact names:

• dotnet.yml: Names include ${{matrix.os}} (ubuntu-latest, windows-latest, macos-latest)
• speed-comparison.yml: Names include ${{matrix.class}} or are already unique

Why this matters: v6 enforces stricter artifact naming—duplicate names in the same workflow run will fail. Your current implementation already handles this correctly.

2. Migration Notes from v6 Release

Notable changes in v6 (already compatible with your usage):

• Improved performance and reliability
• Better handling of large files
• No changes required to your existing configurations

---

⚡ Performance Considerations

Positive impacts:

• v6 includes performance improvements for artifact uploads/downloads
• Better compression and faster upload speeds
• No performance regressions expected

Benchmark workflows: Your speed-comparison.yml will benefit from faster artifact handling, especially for:

• Build artifacts (line 36)
• Multiple benchmark results (lines 83-234)

---

🔒 Security Concerns

✅ No security issues identified

• Official GitHub action (verified source)
• Using specific version tags (v6.0.0) rather than floating tags
• No changes to permissions or secrets handling
• Automated by Renovate Bot with proper configuration

---

🧪 Test Coverage

Workflow validation:

• ✅ All artifact uploads retain if: always() conditions (ensures uploads even on failure)
• ✅ Retention policies preserved (retention-days: 1, retention-days: 90)
• ✅ Path patterns unchanged (no risk of missing files)

Recommendation: The PR will be validated by CI when it runs. Watch for:

1. Successful artifact uploads in the dotnet workflow (3 OS matrix)
2. Successful benchmark artifact handling in speed-comparison workflow

---

📝 Recommendations

1. ✅ Approve and merge - This is a low-risk maintenance update
2. ✅ Automerge enabled - Renovate Bot configuration looks good
3. ℹ️ Monitor first run - After merge, verify one workflow run completes successfully to confirm artifact uploads work as expected

---

🎯 Alignment with TUnit Standards

Checked against CLAUDE.md requirements:

• ✅ No source code changes (workflow-only)
• ✅ No impact on dual-mode implementation
• ✅ No snapshot testing required
• ✅ No public API changes
• ✅ Performance-positive change

---

✨ Final Verdict

APPROVED ✅

This is a well-structured dependency update with no code quality, security, or compatibility concerns. The upgrade to v6 should provide performance benefits without any breaking changes to your workflows.

Suggested action: Allow automerge to proceed, then monitor the next workflow run to confirm successful artifact operations.

---

Review generated by Claude Code following TUnit development guidelines

[claude]

PR Review: Update actions/upload-artifact to v6

Summary

This PR updates the actions/upload-artifact action from v5 to v6 across all workflow files. This is a dependency update managed by Renovate Bot.

---

✅ Positive Observations

1. Consistent Updates: All instances (14 total) across both workflow files have been updated uniformly
2. Low Risk Change: Artifact upload actions typically maintain backward compatibility in minor/major version bumps
3. Automated Testing: The PR will trigger the existing CI/CD workflows, which will validate the changes work correctly
4. Clean Diff: Changes are minimal and focused—only version number updates

---

🔍 Review Findings

Code Quality: ✅ Excellent

• Changes are straightforward and mechanical
• No logic changes, only dependency version updates
• Consistent formatting maintained

Potential Issues: ⚠️ Minor Considerations

1. Breaking Changes: Major version updates (v5 → v6) may include breaking changes. Key areas to verify:

   • Artifact naming conflicts (v6 may have stricter validation)
   • Upload/download compatibility (ensure download-artifact is also updated if used)
   • Retention policy changes
   • Size limits or compression changes

2. Mixed Version Usage: In .github/workflows/dotnet.yml, the original code used v5.0.0 (specific version), while .github/workflows/speed-comparison.yml used v5 (major version tag). Now all use specific versions (v6.0.0 and v6). This inconsistency is minor but worth noting.

Testing Considerations: 🧪

Since this affects artifact uploads, verify:

• Diagnostic logs are still uploaded correctly after test runs
• Hang dumps are captured properly
• NuGet packages artifacts are preserved
• Benchmark results and summary files are accessible
• All artifact downloads in dependent workflows still work

Performance: ✅ Neutral/Positive

• v6 may include performance improvements
• No performance regressions expected

Security: ✅ Good

• Updating to latest versions generally improves security posture
• No security concerns with this specific change

---

📋 Recommendations

1. Before Merging:

   • ✅ Let the CI/CD pipeline run completely to validate artifact uploads work
   • ⚠️ Check if any workflows use actions/download-artifact—they may also need updating for compatibility
   • ⚠️ Review the v6 changelog for any breaking changes

2. After Merging:

   • Monitor the first few workflow runs to ensure artifacts are uploaded/downloaded correctly
   • Check artifact retention policies are still respected

---

✅ Verdict: APPROVE with monitoring

This is a low-risk maintenance update that should be merged. The changes are clean, consistent, and align with best practices for keeping dependencies current.

Recommendation:

• ✅ Approve and merge (automerge is enabled, which is appropriate for this change)
• 📊 Monitor the next 1-2 CI runs to ensure artifacts are handled correctly
• 🔄 Consider updating actions/download-artifact in a follow-up if it's used

---

Review conducted following TUnit development guidelines. No conflicts with CLAUDE.md requirements detected (this is infrastructure-only change).