feat: Release Please Implementation

[thejoeker12]

Hey! Consider using Release-please for your version control. This implementation may not work for you immediately but, adapt it with some AI knowledge and it should make your work a little easier when managing releases.

These links explain the frameworks it utilises:

https://semver.org/
https://www.conventionalcommits.org/en/v1.0.0/

Adopt release-please for versioning and releases

Replaces manual version bumping with release-please. One line in Directory.Build.props becomes the
single source of truth for the product version, and every other place the version appears is either
derived from it at build time or rewritten by release-please on release.

Single source of truth

Directory.Build.props now carries 2.5.0 with an x-release-please-version
annotation. Both SignalSentinel.Core.csproj and SignalSentinel.Scanner.csproj had their own
elements removed and now inherit it.

What release-please rewrites

release-please-config.json (release-type simple, bootstrap-sha pinned to d6b32ad) drives updates to:

• Directory.Build.props — inline annotation
• deploy/docker/Dockerfile.scanner — block annotation around a new ARG VERSION, since Dockerfiles
  have no inline comment syntax
• hooks/.pre-commit-hooks.yaml — the rev: in the usage example
• README.md — version badge, switched from the /badge/ shorthand to /static/v1?...&message=2.5.0 so
  the version is a discrete token the updater can find
• INSTALLATION_AND_USAGE.md — version header, date (x-release-please-date), and every pinned
  ghcr.io/...:2.5.0 reference
• docs/owasp-ast-mapping.md — the rule-map heading
• src/SignalSentinel.Scanner/DefaultRules.json — via the json updater at $.version

.release-please-manifest.json seeds the current version at 2.5.0.

The Dockerfile OCI label moves from a literal 2.5.0 to ${VERSION}, so CI builds passing --build-arg
VERSION= label correctly while local builds fall back to the annotated default.

Scanner --version

Program.cs now reads AssemblyInformationalVersionAttribute (split on + to drop the SourceLink commit
SHA) rather than Assembly.GetName().Version. The assembly version is a four-part numeric quad, so
MSBuild strips semver prerelease labels from it — a 2.6.0-rc.1 build would have reported itself as
plain 2.6.0. Falls back to the old path, then 0.0.0.

Package metadata

PackageReleaseNotes in the scanner csproj was ~120 lines of hand-maintained per-version changelog;
it now points at CHANGELOG.md, which release-please will generate. The Description also drops its
version-specific narrative so it doesn't go stale between releases.

DefaultRules.json churn

The astCodes arrays reformat from single-line to multi-line. This is cosmetic — release-please's
json updater rewrites the whole file with its own formatting, so doing it now keeps future release
commits to a one-line diff.

Repo settings needed before this works

Settings → Actions → General → "Allow GitHub Actions to create and approve pull requests" must be
enabled, or the release PR can't be opened. The workflow deliberately uses the default GITHUB_TOKEN
(no PAT, no App).

Known gap — release.yml is not wired up yet

release-please.yml invokes uses: ./.github/workflows/release.yml with version and tag inputs, but
release.yml is unchanged on this branch: it still only has on: push: tags: ['v*'], declares no
workflow_call trigger, and no inputs. As written the release job will fail workflow validation.
release.yml also derives its version from ${GITHUB_REF#refs/tags/v} in four places, which won't
resolve under workflow_call from a push to main, and its dotnet pack -p:Version= contradicts the new
"never set Version via -p:Version" comment in Directory.Build.props. Either that follow-up lands in
this PR or it needs to merge before the first release-please PR is merged.

Separately, neither commit since the bootstrap SHA (bcaa857, c3833d6) uses conventional-commit
syntax, so no release PR will open until the next feat:/fix: lands. That's expected, just worth
knowing so it doesn't read as a broken workflow.

Verifying

• dotnet build then sentinel-scan --version should print 2.5.0
• dotnet pack on both projects should produce 2.5.0 nupkgs with no in either csproj
• docker build -f deploy/docker/Dockerfile.scanner . then inspect org.opencontainers.image.version
• Dry-run the updaters against a bumped version to confirm all seven annotated files get

[DurganSA]

Thanks for this - solid design on the version single-source-of-truth and the \AssemblyInformationalVersionAttribute-based --version\ fix (that's a genuine improvement over what I'd written).

Since maintainer edits are enabled, I pushed a follow-up commit (7002897) that closes the release.yml workflow_call gap you flagged in the description, plus two related issues that would only have surfaced once release-please actually invoked it:

• release.yml: added a workflow_call trigger with version/tag inputs alongside the existing push: tags path, so a manual git tag vX.Y.Z && git push --tags still works as an emergency fallback.
• create-release: softprops/action-gh-release needs an explicit tag_name on the workflow_call path, since github.ref there is the branch that triggered release-please.yml (main), not the tag.
• publish-docker: docker/metadata-action's type=semver macros only resolve against an actual refs/tags/* ref, so they'd silently produce no version tags (just :latest) when invoked via workflow_call. Replaced with type=raw tags derived from the resolved VERSION output so it behaves identically on both entry points.
• release-please-config.json: added draft: true + force-tag-creation: true. By default release-please creates its own GitHub Release, which would collide with create-release's. With this, release-please creates the tag immediately and leaves the release as a draft with its conventional-commits changelog; create-release then updates that same draft (append_body: true, skips generate_release_notes on this path) to attach the NuGet artifacts and publish it, rather than creating a competing release.

Happy to discuss/adjust any of it - wanted to be upfront about exactly what changed and why rather than just push silently.