Dynamic plugin version from Github Actions#85
Dynamic plugin version from Github Actions#85DevinPower wants to merge 5 commits intolimbonaut:masterfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR automates the plugin version management by dynamically updating the version in plugin.cfg during the CI/CD release workflow, eliminating the need for manual version maintenance. The current hardcoded version (0.4.1) is replaced with a placeholder that gets substituted with the actual version tag during release builds. Additionally, the PR renames GITHUB_TOKEN to GH_TOKEN in one location due to GitHub secrets naming restrictions.
Changes:
- Replace hardcoded version in
plugin.cfgwith a<VERSION>placeholder that gets substituted during CI/CD - Update GitHub Actions workflow to extract version from git tags, strip the 'v' prefix, and inject it into plugin.cfg
- Modify artifact creation from
git archiveto manual file copying to support the version replacement workflow - Rename token reference from
secrets.GITHUB_TOKENtosecrets.GH_TOKENfor the changelog generator
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| plugin.cfg | Changes hardcoded version "0.4.1" to placeholder "" for dynamic replacement |
| .github/workflows/draft-release.yml | Adds version extraction logic, plugin.cfg update step, and changes artifact creation approach; partially renames token references |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| description="Yet another in-game console with a simple command interpreter." | ||
| author="Serhii Snitsaruk" | ||
| version="0.4.1" | ||
| version="<VERSION>" |
There was a problem hiding this comment.
The placeholder version="" will break local development and testing outside of the CI/CD pipeline. When developers or users work with the plugin directly from the repository without going through the release workflow, Godot will see "" as the version string, which is not meaningful. Consider maintaining a real version number in the source file and only replacing it during the release process, or document clearly that this plugin must be installed via releases only.
| version="<VERSION>" | |
| version="0.0.0-dev" |
| myToken: ${{ secrets.GH_TOKEN }} | ||
| base-ref: ${{ inputs.base-ref }} | ||
|
|
||
| - name: Draft Release | ||
| uses: ncipollo/release-action@v1 | ||
| with: | ||
| tag: ${{ github.ref }} | ||
| name: ${{ env.VERSION }} | ||
| name: ${{ env.VERSION_TAG }} | ||
| body: ${{ steps.changelog.outputs.changelog }} | ||
| token: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
The workflow uses two different tokens: secrets.GH_TOKEN on line 47 for the changelog generator and secrets.GITHUB_TOKEN on line 56 for creating the release. While GITHUB_TOKEN is automatically provided by GitHub Actions, the changelog generator (metcalfc/changelog-generator) may require a Personal Access Token with additional permissions. However, the PR description states that "secrets can no longer start with 'GITHUB_'" and mentions renaming GITHUB_TOKEN to GH_TOKEN as a breaking change. This suggests both should use GH_TOKEN. Please clarify: (1) Should both use the custom GH_TOKEN secret? (2) Can the built-in GITHUB_TOKEN be used for both actions? (3) Is the mixed usage intentional? Without this clarification, users following the PR description will configure only GH_TOKEN and may wonder why GITHUB_TOKEN is still referenced.
| cp -r *.gd *.cfg *.uid res/ temp/addons/limbo_console/ | ||
| mkdir out/ |
There was a problem hiding this comment.
The artifact creation logic changed from using 'git archive' to manually copying files. While this allows the version replacement to work, the manual copy approach (*.gd *.cfg *.uid res/) may not capture all necessary files and could miss files added in the future. The git archive approach was more maintainable as it automatically included all tracked files. Consider either: (1) using a more explicit list of what should be included, (2) using git ls-files to get all tracked files dynamically, or (3) documenting why this manual approach is preferred and ensuring it's kept in sync with the repository structure.
| cp -r *.gd *.cfg *.uid res/ temp/addons/limbo_console/ | |
| mkdir out/ | |
| # Copy all tracked files into the plugin directory, preserving structure. | |
| # This ensures the artifact stays in sync with the repository contents. | |
| while IFS= read -r -d '' file; do | |
| dir="temp/addons/limbo_console/$(dirname "$file")" | |
| mkdir -p "$dir" | |
| cp "$file" "$dir/" | |
| done < <(git ls-files -z) | |
| mkdir -p out/ |
| shell: bash | ||
| run: | | ||
| echo "VERSION=$( (git describe --tags --exact-match HEAD || git rev-parse --short HEAD) | sed 's/\(.*\)-\(.*\)/\1.\2/g' )" >> "$GITHUB_ENV" | ||
| VERSION_TAG="$( (git describe --tags --exact-match HEAD || git rev-parse --short HEAD) | sed 's/\(.*\)-\(.*\)/\1.\2/g' )" |
There was a problem hiding this comment.
The version extraction logic on line 26 has a fallback to git rev-parse --short HEAD when no tag is found, which produces a short commit hash. This hash will then be processed by the sed command that transforms hyphens to dots, which may not produce the expected result. For example, a short hash like 'abc-123' would become 'abc.123'. This might not be a valid or meaningful version string for the plugin. Consider handling the no-tag case more explicitly, or ensure that commit hashes don't contain hyphens.
| VERSION_TAG="$( (git describe --tags --exact-match HEAD || git rev-parse --short HEAD) | sed 's/\(.*\)-\(.*\)/\1.\2/g' )" | |
| if git describe --tags --exact-match HEAD >/dev/null 2>&1; then | |
| RAW_VERSION_TAG="$(git describe --tags --exact-match HEAD)" | |
| VERSION_TAG="$(echo "${RAW_VERSION_TAG}" | sed 's/\(.*\)-\(.*\)/\1.\2/g')" | |
| else | |
| VERSION_TAG="$(git rev-parse --short HEAD)" | |
| fi |
|
|
||
| - name: Update plugin version | ||
| shell: bash | ||
| run: sed -i "s|version=\"<VERSION>\"|version=\"${VERSION}\"|g" plugin.cfg |
There was a problem hiding this comment.
The sed command uses the -i flag for in-place editing, which behaves differently on macOS and Linux. On macOS, sed -i requires a backup extension argument (e.g., sed -i '' or sed -i.bak). While this workflow runs on ubuntu-latest, if anyone tries to run this command locally on macOS for testing, it will fail. Consider adding a comment noting this is Linux-specific, or use a more portable approach like: sed 's|...|...|g' plugin.cfg > plugin.cfg.tmp && mv plugin.cfg.tmp plugin.cfg
| run: sed -i "s|version=\"<VERSION>\"|version=\"${VERSION}\"|g" plugin.cfg | |
| run: | | |
| sed "s|version=\"<VERSION>\"|version=\"${VERSION}\"|g" plugin.cfg > plugin.cfg.tmp | |
| mv plugin.cfg.tmp plugin.cfg |
Version in plugin.cfg seems to have been updated manually in the past 2 years ago. Current version for 0.7.0 in-engine is reporting as 0.4.1. This will update version in CI/CD so it doesn't need to be maintained to match releases.
Please note that in setting up my repository, it looks like secrets can no longer start with 'GITHUB_'. As a result, I've renamed GITHUB_TOKEN to GH_TOKEN causing a breaking change.