Updated Builds

[mitchelsellers]

Summary by CodeRabbit

• Chores
  • Updated CI and release workflows to newer tooling versions and runtime targets.
  • Configured automated release-note generation with categorized changelog rules and excluded labels.
  • Adjusted version-management configuration to simplify PR parsing and versioning logic.
  • Removed an obsolete public utility to reduce surface area and cleanup the codebase.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Caution

Review failed

The pull request is closed.

Walkthrough

Updates CI and release tooling: adds changelog config, upgrades GitVersion actions to v4.2.0 and SDK versionSpec to 6.4.0 in workflows, switches Sonar token to an env var, removes GitVersion label-number-pattern, and deletes a public StartupExtensions class file.

Changes

Cohort / File(s)	Summary
Release notes configuration .github/release.yml	Adds changelog configuration: exclude labels question,wontfix,invalid and four categories (Exciting New Features, Squashed Bugs, Administrative, Other Changes).
CI workflows — GitVersion & SDK updates .github/workflows/ci-build.yml, .github/workflows/release-build.yml	Upgrades GitVersion actions from v3.1.1 to v4.2.0; updates versionSpec from 6.0.5 to 6.4.0; removes useConfigFile: true in release workflow.
CI workflows — SonarScanner token handling .github/workflows/ci-build.yml	Changes dotnet-sonarscanner begin step to pass the Sonar token via an environment variable instead of secrets.
GitVersion configuration GitVersion.yml	Removes label-number-pattern from the pull-request branch stanza; other branch rules unchanged.
Source removal src/AspNetCore.Utilities/DependencyResolution/StartupExtensions.cs	Deletes the public static StartupExtensions class (file contents removed).

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant Dev as Developer / PR
  participant GH as GitHub Actions
  participant GV as GitVersion (v4.2.0)
  participant Sonar as dotnet-sonarscanner
  Note over GH: CI / Release workflows (updated)
  Dev->>GH: push / open PR
  GH->>GV: Determine version (gitversion/[email protected])
  GV-->>GH: version metadata
  GH->>Sonar: begin analysis (SONAR_TOKEN from env)
  Sonar-->>GH: analysis started
  GH->>GH: build, test, publish, generate release notes (uses `.github/release.yml`)
  Note over GV: `label-number-pattern` no longer parsed

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Verify GitVersion v4.2.0 action inputs/outputs and removal of useConfigFile.
• Confirm versionSpec: 6.4.0 compatibility with build agents and projects.
• Check Sonar env token is set securely in runner environment and referenced correctly.
• Search for references to the removed StartupExtensions class and ensure no compilation/runtime impact.
• Review release notes categories/labels for intended mapping and exclusions.

Poem

🐰
I hopped through pipelines, nudged a version or two,
sorted notes into buckets and let an old class rue.
Sonar sniffed the meadow, GitVersion sang along,
tiny changes, tidy steps — a dev's gentle song. 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'Updated Builds' is vague and generic, failing to convey the specific nature of the changes which include workflow upgrades, configuration updates, and public API removals.	Use a more descriptive title that captures the main changes, such as 'Upgrade GitVersion actions and remove deprecated StartupExtensions class' or 'Update CI/CD workflows and clean up legacy utilities'.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3238a46 and 03ce29c.

📒 Files selected for processing (1)

• .github/release.yml (1 hunks)

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6e34320 and 0f5a3d4.

📒 Files selected for processing (4)

• .github/release.yml (1 hunks)
• .github/workflows/ci-build.yml (2 hunks)
• .github/workflows/release-build.yml (1 hunks)
• GitVersion.yml (0 hunks)

💤 Files with no reviewable changes (1)

• GitVersion.yml

🔇 Additional comments (4)

.github/workflows/ci-build.yml (1)

27-27: GitVersion upgrade is applied consistently across both jobs.

The upgrade from v3.1.1 to v4.2.0 with versionSpec updated to 6.4.0 is properly applied to both the build and code-quality jobs. GitVersion v4 introduced property name changes such as tag → label and tag-number-pattern → label-number-pattern, so verify that any configuration files have been updated accordingly.

Also applies to: 29-29, 33-33, 84-84, 86-86, 90-90

.github/release.yml (1)

1-22: Release notes changelog configuration is well-structured.

The changelog categories are logical and the exclusion of low-value labels (question, wontfix, invalid) is appropriate. The wildcard label in the final "Other Changes" category ensures comprehensive coverage of all contributions.

.github/workflows/release-build.yml (2)

26-26: GitVersion upgrade to v4.2.0 aligns with CI workflow changes.

The version specification upgrade (6.0.5 → 6.4.0) is consistent with the changes in ci-build.yml. GitVersion v4 introduced breaking changes including property name changes (tag → label, tag-number-pattern → label-number-pattern), so ensure the GitVersion.yml configuration file reflects these changes if applicable.

Also applies to: 28-28, 32-32

---

32-32: GitVersion v4.2.0 auto-detects configuration files by default—the removal of useConfigFile: true is correct and safe.

A GitVersion.yml configuration file exists in the repository root and will be automatically detected by GitVersion v4.2.0. The GitHub Actions task (v4.2.0) auto-detects the config file without requiring the useConfigFile: true parameter. In fact, setting useConfigFile: true in v4.x can introduce failure modes if the config file path is misconfigured. The upgrade and parameter removal are sound design decisions by GitTools and pose no risk to version detection.

Likely an incorrect or invalid review comment.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Sonar token handling is inconsistent between begin and end steps.

Line 98 uses env.SONAR_TOKEN for the scanner begin operation, but line 102 uses secrets.SONAR_TOKEN for the end operation. Since the environment variable is set from the GitHub secret on line 95, this inconsistency should be harmless in practice, but using the same source throughout is clearer. Standardize both steps to use env.SONAR_TOKEN for consistency.

Apply this diff to use the same token source in both steps:

-          .\.sonar\scanner\dotnet-sonarscanner end /d:sonar.login="${{ secrets.SONAR_TOKEN }}"
+          .\.sonar\scanner\dotnet-sonarscanner end /d:sonar.login="${{ env.SONAR_TOKEN }}"

Also applies to: 102-102

🤖 Prompt for AI Agents

.github/workflows/ci-build.yml around lines 98 and 102: the Sonar scanner steps
reference the token inconsistently (line 98 uses env.SONAR_TOKEN while line 102
uses secrets.SONAR_TOKEN); change the end step to use the same env.SONAR_TOKEN
variable as the begin step (standardize both steps to reference env.SONAR_TOKEN)
so both begin and end use the identical token source.

[sonarqubecloud]

Quality Gate failed

Failed conditions
8 Security Hotspots

See analysis details on SonarQube Cloud