[dotnet] [build] Fix remote linkage in SourceLink

[nvborisenko]

The link should use full 40-length commit hash.

Continuation of #17467

💥 What does this PR do?

Use full commit hash.

🔧 Implementation Notes

Exposed new parameter in build-info script.

🤖 AI assistance

• No substantial AI assistance used
• AI assisted (complete below)
  • Tool(s):
  • What was generated:
  • I reviewed all AI output and can explain the change

🔄 Types of changes

• Bug fix (backwards compatible)

[qodo-code-review]

Review Summary by Qodo

Fix SourceLink remote linkage with full commit hash

🐞 Bug fix

Walkthroughs

Description

• Use full 40-character commit hash for SourceLink remote linkage
• Add STABLE_GIT_REVISION_FULL parameter to build-info scripts
• Update sourcelink.bzl to reference full revision instead of short hash
• Ensure consistent commit hash format across bash and PowerShell scripts

Diagram

flowchart LR
  A["build-info scripts<br/>bash & PowerShell"] -- "Generate STABLE_GIT_REVISION_FULL<br/>with full commit hash" --> B["sourcelink.bzl"]
  B -- "Use full hash in<br/>SourceLink JSON" --> C["Remote repository links"]

Loading

File Changes

1. dotnet/private/sourcelink.bzl 🐞 Bug fix +3/-3

Use full commit hash in SourceLink JSON

• Changed input from ctx.version_file to ctx.info_file
• Updated grep pattern from STABLE_GIT_REVISION to STABLE_GIT_REVISION_FULL
• Now uses full 40-character commit hash instead of short hash for SourceLink JSON generation

dotnet/private/sourcelink.bzl

---

2. scripts/build-info.sh ✨ Enhancement +2/-0

Add full commit hash output to bash script

• Added full_revision variable capturing full commit hash via git rev-parse HEAD
• Added new output line echoing STABLE_GIT_REVISION_FULL with full hash and dirty flag
• Maintains existing STABLE_GIT_REVISION output for backward compatibility

scripts/build-info.sh

---

3. scripts/build-info.ps1 ✨ Enhancement +2/-0

Add full commit hash output to PowerShell script

• Added $full_revision variable capturing full commit hash via git rev-parse HEAD
• Added new output line echoing STABLE_GIT_REVISION_FULL with full hash and dirty flag
• Maintains existing STABLE_GIT_REVISION output for backward compatibility

scripts/build-info.ps1

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (2)

1. build-info.ps1 ignores git failures 📘 Rule violation ☼ Reliability

Description

The new git rev-parse HEAD call used to populate STABLE_GIT_REVISION_FULL does not check exit
status (e.g., $LASTEXITCODE) or validate output, so missing/failed git can silently emit empty
or incorrect build metadata. This can make build outputs (including SourceLink URLs) less
deterministic and harder to troubleshoot.

Code

scripts/build-info.ps1[2]

+$full_revision = (git rev-parse HEAD)

Evidence

PR Compliance ID 12 requires scripts/build steps to be hardened and not silently proceed on
failures. The cited additions that set full_revision via git rev-parse HEAD do not include any
exit-code or output validation, meaning the scripts can continue even when git is unavailable or
the command fails, and still emit an incorrect/empty revision value instead of failing
deterministically.

scripts/build-info.ps1[1-10]
scripts/build-info.sh[1-12]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`scripts/build-info.ps1` and `scripts/build-info.sh` run `git rev-parse HEAD` to compute `STABLE_GIT_REVISION_FULL` but do not fail fast or validate the command succeeded, so they may continue and emit invalid/empty revision values.

## Issue Context
This PR introduces `STABLE_GIT_REVISION_FULL`; if `git` is missing or `git rev-parse` fails, downstream consumers (including SourceLink URL generation) can receive incorrect and/or non-deterministic values, violating PR Compliance ID 12’s requirement to avoid hidden failures in scripts.

## Fix Focus Areas
- scripts/build-info.ps1[1-10]
- scripts/build-info.sh[1-12]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. sourcelink.bzl whitespace-fragile parsing 📘 Rule violation ☼ Reliability

Description

The SourceLink generator in dotnet/private/sourcelink.bzl parses the workspace status line with
whitespace-fragile logic (e.g., cut -d' ' -f2 / strict grep), which can mis-parse when
separators are multiple spaces/tabs or the expected key is missing/renamed, yielding an empty
commit. It then silently falls back to COMMIT=HEAD, producing mutable (moving-target) SourceLink
URLs and potentially incorrect released PDB source mapping in some environments.

Code

dotnet/private/sourcelink.bzl[16]

+COMMIT=$(grep "^STABLE_GIT_REVISION_FULL " "{status}" | cut -d' ' -f2 | tr -d '*')

Evidence

PR Compliance ID 12 requires hardening scripts to avoid fragile, non-deterministic behavior, and the
current pipeline violates this by relying on exact workspace-status formatting (grepping for an
exact STABLE_GIT_REVISION_FULL line and/or splitting on a single-space delimiter via `cut -d' '
-f2`). When that lookup or parse yields no commit (due to differing whitespace, missing/different
key, or differing status file contents), the implementation explicitly substitutes HEAD, so the
resulting SourceLink JSON can reference .../raw/HEAD/... rather than an immutable commit. Since
the workspace status command is wired to scripts/build-info.* (configured via .bazelrc) and now
emits STABLE_GIT_REVISION_FULL, any mismatch in availability/formatting triggers the fallback and
leads to incorrect SourceLink URLs.

dotnet/private/sourcelink.bzl[15-18]
dotnet/private/sourcelink.bzl[10-26]
.bazelrc[78-85]
scripts/build-info.sh[3-12]
scripts/build-info.ps1[1-10]
.bazelrc[123-125]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The SourceLink JSON generation in `dotnet/private/sourcelink.bzl` extracts the commit using whitespace- and format-fragile parsing (strict key match and/or `cut -d' ' -f2`), and when the expected `STABLE_GIT_REVISION_FULL` entry isn’t found or is mis-parsed it silently falls back to `COMMIT=HEAD`. This can publish SourceLink metadata pointing at a mutable `.../raw/HEAD/...` URL instead of an immutable commit, making released PDB source mapping incorrect.

## Issue Context
PR Compliance ID 12 calls for hardened scripts to reduce fragility and non-deterministic behavior. The workspace status command is configured via `.bazelrc` and `scripts/build-info.{sh,ps1}` emits `STABLE_GIT_REVISION_FULL ...`, but the current extraction requires an exact key/spacing and treats a miss as success by substituting `HEAD`, so minor differences in whitespace (multiple spaces/tabs), key naming (e.g., `GIT_REVISION_FULL`), or which status file contains the value can trigger the fallback.

## Fix Focus Areas
- dotnet/private/sourcelink.bzl[10-26]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[AutomatedTester]

LGTM