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).

[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 workflow files. This is a dependency update generated by Renovate Bot.

---

✅ Positive Observations

1. Consistent Updates: All occurrences of upload-artifact have been updated consistently across both workflow files:

   • .github/workflows/dotnet.yml: 3 occurrences (lines 109, 116, 123)
   • .github/workflows/speed-comparison.yml: 11 occurrences (lines 37, 84, 119, 164, 174, 184, 194, 204, 214, 224, 234)

2. Version Pinning: The main workflow uses explicit version pinning (v6.0.0) while the speed comparison workflow uses major version pinning (v6). Both approaches are valid, though pinning to specific versions is generally safer.

3. Automerge Enabled: This is appropriate for automated dependency updates in GitHub Actions.

---

⚠️ Potential Concerns & Recommendations

1. Breaking Changes in v6 ⚠️

The upload-artifact v6 action includes breaking changes that could affect this workflow:

• Artifact naming collision handling: In v6, if multiple jobs upload artifacts with the same name, they will overwrite each other by default (v5 would create separate artifacts or error).
• Artifact isolation: v6 changes how artifacts are scoped within workflow runs.

Risk Assessment:
Looking at .github/workflows/dotnet.yml, the artifact names use matrix variables to ensure uniqueness:

• TestingPlatformDiagnosticLogs with matrix.os suffix
• HangDump with matrix.os suffix
• NuGetPackages- with matrix.os suffix

✅ This is SAFE - the matrix variable ensures unique names across the matrix strategy.

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

• Line 39: test-builds-ubuntu - unique (single job)
• Lines 87, 122: Use matrix.class variable - unique per matrix job
• Lines 164-242: All have unique static names

✅ This is SAFE - all artifact names are unique.

2. Retention Days Default Change

• v6 may have different default retention periods
• Current workflow explicitly sets retention-days where needed (lines 171, 181, 191, etc. in speed-comparison.yml)
• ✅ No action needed - explicit retention periods are set

3. Missing Explicit Retention in dotnet.yml ℹ️

The three artifact uploads in .github/workflows/dotnet.yml (lines 109, 116, 123) do not specify retention-days.

Recommendation: Consider adding explicit retention periods for consistency - this ensures predictable cleanup regardless of GitHub's default settings.

4. Version Pinning Inconsistency ℹ️

• dotnet.yml uses v6.0.0 (patch-level pinning)
• speed-comparison.yml uses v6 (major version pinning)

Recommendation: For consistency, standardize on one approach. The current mixed approach is functional but could be unified.

---

🔍 Testing Recommendations

Since this changes infrastructure code, I recommend:

1. Monitor the first workflow run after merge to ensure:

   • All artifacts upload successfully
   • No naming collisions occur
   • Artifacts are downloadable
   • Retention periods work as expected

2. Check download-artifact compatibility: The workflow uses actions/download-artifact@v6 (lines 66, 141, 148), which should be compatible with uploads from v6.

---

📋 Checklist Compliance (per CLAUDE.md)

✅ No code changes - only GitHub Actions dependency update
✅ No source generator changes
✅ No public API changes
✅ No snapshot updates needed
✅ No dual-mode implementation concerns
✅ No performance impact
✅ No security concerns introduced

---

✅ Final Recommendation

APPROVE with minor suggestions

This PR is safe to merge. The v6 upgrade is straightforward and the workflow configurations are already compatible with the breaking changes in v6.

Optional improvements (non-blocking):

1. Add explicit retention-days to the three uploads in dotnet.yml
2. Standardize version pinning strategy (v6.0.0 vs v6)

These are minor consistency improvements and don't block the merge.

---

Review completed by: Claude Code
Review date: 2025-12-15

[claude]

PR Review: Upgrade actions/upload-artifact from v5 to v6

Summary

This is a Renovate-generated PR that updates the actions/upload-artifact action from v5 to v6 across GitHub workflow files.

Code Quality ✅

• Clean and focused: The changes are straightforward version bumps
• Consistent: All instances of the action have been updated uniformly
• Proper versioning: Mix of pinned versions (v6.0.0) and major version tags (v6) is appropriate for different use cases

Files Changed (2)

1. .github/workflows/dotnet.yml - 3 instances updated to v6.0.0
2. .github/workflows/speed-comparison.yml - 11 instances updated to v6

Potential Concerns ⚠️

1. Breaking Changes Not Verified

• The PR description doesn't include release notes detailing breaking changes
• Recommendation: Before merging, verify the v6 release notes for any breaking changes that might affect:
  • Artifact naming (special characters, uniqueness requirements)
  • Artifact merging behavior
  • Upload/download compatibility
  • Retention policy changes

2. Mixed Version Pinning Strategy

• dotnet.yml: Uses exact version v6.0.0 (more stable, requires manual updates)
• speed-comparison.yml: Uses major version v6 (auto-updates to latest v6.x)
• Note: This is intentional and acceptable, but be aware that v6 will automatically get patch updates

3. Testing Recommendations

Since these changes affect artifact uploads across critical workflows:

• ✅ Verify diagnostic logs upload correctly after merge
• ✅ Verify hang dumps are captured properly
• ✅ Verify NuGet packages artifact generation works
• ✅ Verify benchmark artifacts upload successfully
• ✅ Check that artifact download in dependent jobs still works (if any)

Performance Considerations ✅

• GitHub Actions dependencies typically have minimal performance impact
• No runtime performance changes expected

Security Considerations ✅

• Using official GitHub Actions from verified publisher
• Version pinning provides supply chain security
• No security concerns identified

Test Coverage ✅

• This is infrastructure code that will be tested by the CI/CD pipeline itself
• The workflows will fail if artifacts cannot be uploaded correctly

Alignment with TUnit Guidelines ✅

• No code changes to TUnit itself
• Infrastructure maintenance (acceptable)
• Follows principle of keeping dependencies up-to-date

Recommendation: ✅ APPROVE with minor verification

This is a routine dependency update that should be safe to merge. However, I recommend:

1. Quick verification: Check the v6 release notes for breaking changes (especially around artifact naming/merging)
2. Monitor first run: Watch the first workflow run after merge to ensure artifacts upload successfully
3. Rollback plan: If issues occur, the previous version pins are clearly documented in this PR for easy rollback

The automerge setting is appropriate for this type of change, assuming the release notes don't reveal unexpected breaking changes.

---

Review generated by Claude Code following TUnit development guidelines