ci: Publish on Github on tagging #16
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds automated GitHub release creation when tags are pushed, triggered by the existing publish workflow. The release notes are extracted from the CHANGELOG.md file for the corresponding version.
Changes:
- Modified publish workflow permissions to enable release creation
- Added a new
create-releasejob that extracts version-specific changelog entries and creates GitHub releases - Refactored a test file to use explicit string literals instead of template literals (likely for linting consistency)
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
.github/workflows/publish.yml |
Added contents: write permission and new create-release job with changelog extraction logic |
backend/test/integrations/CodeAnalyzer.test.ts |
Converted multi-line template literal to single-line string with escape sequences for lint test manifest |
| subject-digest: ${{ steps.build.outputs.digest }} | ||
| push-to-registry: true | ||
|
|
||
| create-release: |
There was a problem hiding this comment.
The create-release job depends on build-and-publish with needs: build-and-publish, which means the release will only be created after the Docker build completes successfully. If the Docker build fails, no release will be created even though the tag was pushed.
Consider whether this is the desired behavior. If the goal is to create a GitHub release for every tag push regardless of Docker build status, the jobs should run in parallel without the dependency. Alternatively, if the current behavior is intentional, consider adding a comment explaining this design choice.
| create-release: | |
| create-release: | |
| # Intentionally depend on Docker image build/publish: only create a GitHub | |
| # release if the container image was successfully built and pushed. |
| run: | | ||
| VERSION="${{ steps.version.outputs.version }}" | ||
| # Extract the section for this version from CHANGELOG.md | ||
| awk "/^## \[${VERSION#v}\]/,/^## \[/" CHANGELOG.md | sed '$d' > release_notes.md |
There was a problem hiding this comment.
The awk pattern used to extract changelog entries has a potential issue. The pattern /^## \[${VERSION#v}\]/,/^## \[/ will match from the specified version to the NEXT section header starting with ## [, but using sed '$d' to remove the last line assumes the next section header is immediately on the next line. This won't work correctly if there are blank lines between changelog sections (which exist in the current CHANGELOG.md format).
Additionally, if this is the last version in the changelog (no version section after it), the awk range pattern may not work as expected and could include content all the way to the end of the file.
Consider using a more robust approach that explicitly handles the end of a section, or test with the actual CHANGELOG.md format which includes blank lines between sections.
| awk "/^## \[${VERSION#v}\]/,/^## \[/" CHANGELOG.md | sed '$d' > release_notes.md | |
| awk -v ver="${VERSION#v}" ' | |
| $0 ~ "^## \\[" ver "\\]" { in_section=1; print; next } | |
| in_section && /^## \[/ { exit } | |
| in_section { print } | |
| ' CHANGELOG.md > release_notes.md |
| body_path: release_notes.md | ||
| draft: false | ||
| prerelease: ${{ contains(steps.version.outputs.version, '-') }} | ||
| generate_release_notes: true |
There was a problem hiding this comment.
Setting both body_path with extracted changelog content AND generate_release_notes: true will combine both the extracted changelog and GitHub's auto-generated release notes. This may result in duplicate or confusing information in the release.
If the intention is to use the CHANGELOG.md content as the primary release notes, consider removing generate_release_notes: true. If auto-generated notes are preferred when changelog extraction fails, the logic should be adjusted to conditionally set this parameter based on whether changelog extraction succeeded.
| generate_release_notes: true |
| run: | | ||
| VERSION="${{ steps.version.outputs.version }}" | ||
| # Extract the section for this version from CHANGELOG.md | ||
| awk "/^## \[${VERSION#v}\]/,/^## \[/" CHANGELOG.md | sed '$d' > release_notes.md | ||
| if [ ! -s release_notes.md ]; then | ||
| echo "Release notes not found in CHANGELOG.md, using default message" | ||
| echo "## Changes" > release_notes.md | ||
| echo "" >> release_notes.md | ||
| echo "See [CHANGELOG.md](https://github.com/${{ github.repository }}/blob/main/CHANGELOG.md) for details." >> release_notes.md | ||
| fi | ||
| cat release_notes.md |
There was a problem hiding this comment.
The changelog extraction step displays the content with cat release_notes.md but doesn't validate that the extraction was successful before proceeding to create the release. If the awk command produces unexpected output or empty content (even passing the -s check due to whitespace), this could create a release with malformed or empty notes.
Consider adding validation to check that the extracted content contains expected sections (e.g., contains "### Added" or "### Changed" markers) before proceeding, or add a step that fails the workflow if extraction produces clearly invalid content.
No description provided.