Implement BuildMark and VersionMark for automated Build Notes PDF generation

[Copilot]

Pull Request

Description

Adds BuildMark and VersionMark tools to automatically generate Build Notes PDF from Git history and GitHub issues, following the TemplateDotNetTool reference implementation. The generated buildnotes.md is now used as the release body instead of GitHub's auto-generated notes.

Tool Configuration:

• Added BuildMark v0.2.0 and VersionMark v0.1.0 to .config/dotnet-tools.json
• Created .versionmark.yaml with regex patterns to capture versions of build tools (dotnet, git, node, npm, sonarscanner, pandoc, weasyprint, sarifmark, sonarmark, reqstream, buildmark, versionmark)

Documentation Structure:

• Created docs/buildnotes/ with title.txt, introduction.md, and definition.yaml for Pandoc PDF generation

Build Workflow Integration:

• Added version capture steps to quality-checks, build (Windows/Linux), and codeql jobs
• Enhanced build-docs job to:
  • Download all version capture artifacts
  • Generate buildnotes.md using BuildMark (analyzes Git history and GitHub issues)
  • Display Build Notes Report for visibility during CI runs
  • Generate versions.md using VersionMark (consolidates tool versions from all jobs)
  • Generate Build Notes HTML (Pandoc) and PDF (WeasyPrint)
  • Upload buildnotes.md with documentation artifacts maintaining proper docs/ folder structure

Release Workflow Integration:

• Downloads buildnotes.md from documentation artifacts
• Moves buildnotes.md from artifacts/docs/ to root for release body
• Uses buildnotes.md as bodyFile in ncipollo/release-action
• Disabled generateReleaseNotes in favor of BuildMark-generated content

Artifact Structure:

• Documentation artifact maintains clean structure with all files in docs/ folder
• PDFs are located at docs/*.pdf
• Build notes markdown is located at docs/buildnotes.md
• This ensures the artifact is well-organized and files are easy to locate

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code quality improvement

Related Issues

Pre-Submission Checklist

Before submitting this pull request, ensure you have completed the following:

Build and Test

• Code builds successfully: dotnet build --configuration Release
• All tests pass: dotnet test --configuration Release
• Code produces zero warnings

Code Quality

• Code formatting is correct: dotnet format --verify-no-changes
• New code has appropriate XML documentation comments
• Static analyzer warnings have been addressed

Quality Checks

Please run the following checks before submitting:

• Spell checker passes: cspell "**/*.{md,cs}"
• Markdown linter passes: markdownlint "**/*.md"
• YAML linter passes: yamllint '**/*.{yml,yaml}'

Testing

• Added unit tests for new functionality
• Updated existing tests if behavior changed
• All tests follow the AAA (Arrange, Act, Assert) pattern
• Test coverage is maintained or improved

Documentation

• Updated README.md (if applicable)
• Updated ARCHITECTURE.md (if applicable)
• Added code examples for new features (if applicable)
• Updated requirements.yaml (if applicable)

Additional Notes

BuildMark requires GitHub API access and will function correctly in GitHub Actions environment. VersionMark successfully tested locally with capture and publish operations. CodeQL security scan passed with 0 alerts.

The generated Build Notes PDF will be included alongside existing documentation (Developer Guide, Requirements, Trace Matrix, Code Quality) in release artifacts. Build Notes are now displayed during CI runs for immediate visibility. The documentation artifact maintains proper structure with all files organized in the docs/ folder for consistency and ease of access.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.