feat: implement tag-based deployment with stadium release names (#356)#357
feat: implement tag-based deployment with stadium release names (#356)#357nanotaboada merged 4 commits intomasterfrom
Conversation
- Rename dotnet.yml to dotnet-ci.yml and remove container publishing - Create dotnet-cd.yml workflow triggered by version tags (v*.*.*-*) - Add CHANGELOG.md with A-Z stadium list and release template - Update README.md with release instructions and docker pull examples - Separate CI (build/test) from CD (publish packages on tags only)
WalkthroughAdds a tag-triggered CD workflow ( Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer (git tag)
participant GH as GitHub Actions
participant Runner as Actions Runner
participant DotNet as dotnet (restore/build/test)
participant Docker as Docker/Buildx
participant GHCR as GitHub Container Registry
participant Release as GitHub Release
Dev->>GH: push tag vX.Y.Z-STADIUM
GH->>Runner: trigger dotnet-cd.yml
Runner->>DotNet: restore → build (Release) → test
Runner->>Docker: build images (Buildx)
Docker->>GHCR: push images (tags: latest, semver, stadium)
Runner->>Runner: generate changelog (compare tags)
Runner->>Release: create GitHub Release with changelog and image pull commands
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferences |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @.github/workflows/dotnet-cd.yml:
- Around line 87-103: The changelog step (id: changelog) generates changelog.txt
but never sets a step output, so steps.changelog.outputs.changelog is empty;
after computing CHANGELOG (and/or writing changelog.txt) write the changelog to
$GITHUB_OUTPUT so it becomes a step output named "changelog" (use the multiline
form to preserve newlines), e.g. emit a heredoc to $GITHUB_OUTPUT that assigns
the "changelog" output from the CHANGELOG variable so subsequent steps can
reference steps.changelog.outputs.changelog.
In `@CHANGELOG.md`:
- Line 10: The opening claim "This project uses famous football stadiums (A-Z)
that hosted FIFA World Cup matches:" is inconsistent with the entry "Xiamen
Egret Stadium (famous fallback)"; either relax the header to allow non-World-Cup
exceptions (e.g., add "or notable/fallback stadiums") or replace the X entry
with a true World Cup stadium name; update the header text or change "Xiamen
Egret Stadium (famous fallback)" to a confirmed World Cup host (keeping the A–Z
scheme) so the document is consistent.
- Line 29: The tag for Parc des Princes is incorrect: replace the identifier
`parcdesprince` with `parcdesprinces` in the table row containing "| P | Parc
des Princes | France (1938, 1998) | `parcdesprince` |" so the tag correctly
reflects the stadium name; update the backticked tag token only, preserving the
rest of the table row and formatting.
- Add changelog multiline output to $GITHUB_OUTPUT for release body - Update CHANGELOG header to acknowledge non-World Cup fallback stadium - Correct Parc des Princes tag from parcdesprince to parcdesprinces - Restore missing GitHub Release step header in CD workflow
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/dotnet-cd.yml:
- Around line 28-44: The tag extraction step (variables TAG_NAME, SEMVER,
STADIUM in the "Extract version from tag" run block) must validate parsed values
and fail fast for malformed tags: after computing SEMVER and STADIUM, check that
SEMVER matches the expected semver pattern and STADIUM is non-empty; if either
check fails, emit a clear error message and exit non‑zero instead of writing
outputs, otherwise export tag_name, semver and stadium as before. Ensure the
validation occurs before any echo "semver=..." or "stadium=..." >>
$GITHUB_OUTPUT so invalid tags cannot produce bad Docker tags.
- Add validation for stadium names against official A-Z list from CHANGELOG.md - Validate semver format matches X.Y.Z pattern - Fail fast with helpful error messages before writing outputs - Prevent invalid tags like v1.0.0-aztec or v1.0.0-foobar from proceeding
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/dotnet-cd.yml:
- Around line 138-170: The release step using softprops/action-gh-release
currently sets both a custom body including ${{
steps.changelog.outputs.changelog }} and generate_release_notes: true, causing
duplicate changelog content; update the Create GitHub Release step
(softprops/action-gh-release) to either remove ${{
steps.changelog.outputs.changelog }} from the body when keeping
generate_release_notes: true, or set generate_release_notes: false if you want
to keep the custom body, and ensure the tag_name/name fields remain unchanged.
🧹 Nitpick comments (3)
.github/workflows/dotnet-cd.yml (3)
11-13: Consider adding .NET CLI environment flags for cleaner logs.Based on learnings, adding
DOTNET_NOLOGO: trueandDOTNET_SKIP_FIRST_TIME_EXPERIENCE: 1suppresses the .NET welcome message and logo output, resulting in cleaner CI logs.♻️ Suggested improvement
env: DOTNET_VERSION: 8.0.x PACKAGE_NAME: nanotaboada/dotnet-samples-aspnetcore-webapi + DOTNET_NOLOGO: true + DOTNET_SKIP_FIRST_TIME_EXPERIENCE: 1
46-61: Hardcoded stadium list creates maintenance burden.The
VALID_STADIUMSlist is duplicated fromCHANGELOG.md. If the source of truth inCHANGELOG.mdchanges, this workflow must be manually updated, risking drift.Consider extracting the list dynamically from
CHANGELOG.mdor documenting the synchronization requirement clearly. For now, this is acceptable if releases are infrequent.
23-26: Consider using the floatingv6tag instead of a specific patch version.
actions/checkout@v6.0.1is valid, but pinning to a specific patch version (v6.0.1) means you won't receive automatic security updates. The latest major version is v6, and best practice is to useactions/checkout@v6to ensure patches are applied automatically. Thefetch-depth: 0setting is correctly configured for full history access.
- Remove manual git log changelog from release body - Rely on generate_release_notes for auto-generated changelog - Keep custom Docker pull instructions in body - Avoid duplicate/conflicting changelog content
|



Summary by CodeRabbit
New Features
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.