Skip to content

Prepare Sonar-gated publication and new-code coverage evidence - #31

Merged
andregoepel merged 2 commits into
mainfrom
feature/core-sonar-publication
Oct 24, 2026
Merged

andregoepel merged 2 commits into
mainfrom
feature/core-sonar-publication

Conversation

@andregoepel

@andregoepel andregoepel commented Oct 23, 2026 •

Copy link
Copy Markdown
Owner

Core's tag publisher currently bypasses Sonar. This PR prepares a separate fail-closed publication path, using the shared verifier from workflows PR #31 and official NuGet/login plus dotnet push. The templates stay outside .github/workflows with literal-false guards; the actual preparation ID and publication-verifier pin remain unregistered until review. Existing Actions, the legacy publisher, central baseline and NuGet settings are unchanged.

For #30, Result.Fail and Result.Fail now reject null errors instead of returning a failure inconsistent with their nullability contract. Two regression tests reproduce the prior bug. The analysis contract requires all eight tests.

Validation:

  • Core: eight tests and full local Sonar analysis passed on Windows and Linux; 100% coverage, zero findings; formatting and dependency audits passed.
  • Isolated new-code drill: 87.5% overall coverage passed while 0% new-code coverage failed (exit 1); covering the same one-line fixture recovered to 100% (exit 0), with its baseline unchanged. No probe code is included.
  • Both inactive publishing templates pass actionlint. Shared verifier: 1,086 offline tests passed per platform.

Read-only NuGet audit completed: one package owner, one exact-package Core policy still bound to legacy ci.yml without an environment restriction, and no API keys in that account. No settings changed; recheck before cutover.

Refs #29 and #30. Keep both open: hosted publishing rehearsal, separately approved cutover/bypass removal and exact merged-main new-code/readiness evidence are still required. See docs/nuget-quality-gate.md and docs/sonar-new-code.md. Do not merge automatically or activate publishing.

Hosted validation for 891252fee2239e7be695228c4d50439ba09a755f: CI passed, including 8/8 tests. Publishing was skipped for this PR event. The companion workflows PR #31 passed all hosted checks, including 1,086 tests on Windows and Ubuntu. Core has no separate E2E workflow; hosted publishing integration remains a later explicitly approved rehearsal. Central Sonar new-code/readiness evidence remains a post-merge acceptance step; the local Sonar results above do not replace it.

@andregoepel andregoepel left a comment

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the current preparation-only changes and companion verifier integration. One issue in the inactive publication template needs correction before it is used. Local Core tests passed (8/8).

@andregoepel andregoepel left a comment

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The publication outcome recorder must use Core's configured inventory size.

then error("Invalid attempt sequence") else . end) |
if ($push == "skipped" and ($e | length) != 0) or
($push != "skipped" and $login != "success") or
($push == "success" and (($e | length) != 24 or any($e[]; .status != "started" and .status != "cli-success")))

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Derive the successful outcome count from the Core inventory

Core configures one package, so the verified inventory contains two files (.nupkg and .snupkg). A fully successful push produces four event rows (started and cli-success for each), but this condition requires 24, inherited from the six-package publisher. Once this template is enabled, every successful Core publication therefore raises Inconsistent step outcomes after uploading both files, preventing outcomes.json from being preserved and marking the run failed despite the uploads. Derive both row-count limits from ($i.packages | length) * 2 and exercise the recorder with a successful single-package batch.

Copy link
Copy Markdown
Owner Author

Review of 891252fee2239e7be695228c4d50439ba09a755f found one actionable issue in the inactive publication template:

[P2] Derive the outcome event count from the configured package inventory. Core publishes one .nupkg and one .snupkg, producing four successful event rows. The recorder in scripts/sonar/publication/nuget-publish.yml:409 requires 24. Once enabled, a successful upload would therefore fail outcome recording with Inconsistent step outcomes, leaving the run failed and its outcomes.json unavailable. Replace the fixed row-count limits with ($i.packages | length) * 2 and validate the recorder with a successful single-package batch.

Inline finding.

Local Windows Release tests passed: Core 8/8 and the companion Workflows verifier 1,086/1,086. No actionable findings were identified in Workflows #31. Hosted publication integration remains unverified; the Core template is currently inactive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant