Conversation
Signed-off-by: Daniel Kampert <DanielKampert@kampis-elektroecke.de>
There was a problem hiding this comment.
Pull request overview
Updates the project’s release automation to publish an ESP-IDF component release from main/master and adds a changelog validation workflow.
Changes:
- Reworks the GitHub Actions release workflow to extract a version, update changelog/component metadata, commit changes, create a GitHub release, and upload to the ESP Component Registry.
- Removes CMake version variables previously used to represent the library version.
- Adds a CI workflow to validate
hardware/CHANGELOG.mdformatting and issue references.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| idf_component.yml | Changes the component version field used for registry publishing. |
| CMakeLists.txt | Removes hard-coded library version variables that the workflow previously updated. |
| .github/workflows/release.yaml | Replaces tag-based releases with a branch-based “component release” pipeline that edits files, creates a release, and uploads the component. |
| .github/workflows/changelog-check.yaml | Adds a workflow to enforce changelog format and references in hardware/CHANGELOG.md. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -1,4 +1,4 @@ | |||
| version: "0.0.2" | |||
| version: "0.0.1" | |||
There was a problem hiding this comment.
This PR is titled "Release 0.0.2" but idf_component.yml is set to 0.0.1, which is a version downgrade and will cause the registry upload to publish the wrong version. Update the component version to match the intended release version (0.0.2), or ensure the workflow is the single source of truth and avoid committing an incorrect static version.
| version: "0.0.1" | |
| version: "0.0.2" |
| # Get the merged branch name from the merge commit | ||
| COMMIT_MSG=$(git log -1 --pretty=%B) | ||
| echo "Commit message: $COMMIT_MSG" | ||
|
|
||
| # Extract branch name from merge commit message (e.g., "Merge branch '0.0.2_Dev'") | ||
| BRANCH_NAME=$(echo "$COMMIT_MSG" | sed -n "s/.*Merge.*branch '\([^']*\)'.*/\1/p") | ||
|
|
||
| if [ -z "$BRANCH_NAME" ]; then | ||
| # Try alternative merge message format | ||
| BRANCH_NAME=$(echo "$COMMIT_MSG" | sed -n "s/.*Merge.*branch \"\([^\"]*\)\".*/\1/p") | ||
| fi | ||
|
|
||
| if [ -z "$BRANCH_NAME" ]; then | ||
| # No merge commit found, try to get version from commit message directly | ||
| echo "::warning::No merge commit detected, trying to extract version from commit message" | ||
| VERSION=$(echo "$COMMIT_MSG" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+(_[A-Za-z0-9]+)?' | head -n 1) |
There was a problem hiding this comment.
Version extraction relies on parsing the last commit message for a very specific merge message format ("Merge branch '...'"). Common GitHub merges (e.g., "Merge pull request #123 from ...") and squash merges will not match, causing the workflow to hard-fail on valid merges to main/master. Use a more reliable source of truth for VERSION (e.g., read version: from idf_component.yml, parse a dedicated version file, or drive releases from tags again).
| if [ -z "$VERSION" ]; then | ||
| echo "::error::No version found in commit message or branch name" | ||
| exit 1 |
There was a problem hiding this comment.
Version extraction relies on parsing the last commit message for a very specific merge message format ("Merge branch '...'"). Common GitHub merges (e.g., "Merge pull request #123 from ...") and squash merges will not match, causing the workflow to hard-fail on valid merges to main/master. Use a more reliable source of truth for VERSION (e.g., read version: from idf_component.yml, parse a dedicated version file, or drive releases from tags again).
| # Add new Unreleased section at the top | ||
| sed -i '/^# CHANGELOG/a\\n## [Unreleased]' CHANGELOG.md |
There was a problem hiding this comment.
The workflow unconditionally inserts a new ## [Unreleased] section after # CHANGELOG on every run, which will create duplicated Unreleased sections if the workflow is re-run or if multiple releases occur without cleaning the file. Add a guard so insertion only happens when an Unreleased section is not already present at the top (or insert in a deterministic way, e.g., replace-in-place and then re-add only once).
| # Add new Unreleased section at the top | |
| sed -i '/^# CHANGELOG/a\\n## [Unreleased]' CHANGELOG.md | |
| # Add new Unreleased section at the top, if it does not already exist | |
| if ! grep -q '^## \[Unreleased\]' CHANGELOG.md; then | |
| sed -i '/^# CHANGELOG/a\\n## [Unreleased]' CHANGELOG.md | |
| fi |
| - name: Update CMakeLists.txt | ||
| run: | | ||
| # Update version in CMakeLists.txt (searches for any VERSION variable) | ||
| sed -i -E "s/set\([A-Z_]*VERSION[A-Z_]* [^)]*\)/set(\0 $VERSION)/g" CMakeLists.txt || true | ||
| sed -i -E "s/set\([A-Z_]*LIB_VERSION[A-Z_]* [^)]*\)/set(\0 $VERSION)/g" CMakeLists.txt || true | ||
|
|
There was a problem hiding this comment.
These sed replacements are not producing valid CMake syntax: the replacement wraps set( around \0, but \0 already includes set(...), resulting in set(set(... ) <version>). Also, || true will mask failures and can silently leave versions unmodified. Either remove this step (since the PR removes version vars from CMakeLists.txt), or replace it with a deterministic update targeting a known pattern (e.g., project(... VERSION x.y.z) or a specific set(MY_VERSION ...)) and fail the workflow if the update doesn’t apply.
| - name: Update CMakeLists.txt | |
| run: | | |
| # Update version in CMakeLists.txt (searches for any VERSION variable) | |
| sed -i -E "s/set\([A-Z_]*VERSION[A-Z_]* [^)]*\)/set(\0 $VERSION)/g" CMakeLists.txt || true | |
| sed -i -E "s/set\([A-Z_]*LIB_VERSION[A-Z_]* [^)]*\)/set(\0 $VERSION)/g" CMakeLists.txt || true |
| # Split version into components | ||
| IFS='.' read -r MAJOR MINOR BUILD <<< "${BASE_VERSION}" | ||
| # Replace [Unreleased] with [VERSION] - DATE | ||
| sed -i "s/^## \[Unreleased\]/## [$VERSION] - $(date +'%Y-%m-%d')/" CHANGELOG.md |
There was a problem hiding this comment.
The release workflow edits CHANGELOG.md at the repository root, but the new changelog validation workflow enforces formatting on hardware/CHANGELOG.md. This inconsistency makes it easy for CI and releases to get out of sync. Align both workflows to the same changelog path (either validate and update CHANGELOG.md, or validate and update hardware/CHANGELOG.md).
No description provided.