chore: add support for separate module versioning to CI #426
+408
−95
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add check-version.sh script for checking and updating module versions - Update update-version.sh to handle module-specific tags - Add new check-version npm script This change allows tracking module versions separately using tags in the format release/module-name/v1.0.0 and adds tooling to verify README.md versions match the tags.
- Replace update-version.sh and check-version.sh with modules-version.sh - Add support for semantic versioning (patch, minor, major) - Add tag creation capability - Improve CLI interface with better help and options - Update package.json scripts for the new tool
- Replace old version check mechanism with new --check mode - Improve error messaging for version mismatches - Simplify CI configuration
- Differentiate between PR checks and main branch checks - For PRs: Verify version is incremented but doesn't need to match tags - For main: Verify versions match tags - Add helpful error messages with specific commands to fix issues - Handle modules without tags gracefully
- Make version check informational only for PRs - Add ability to skip check with [skip-version-check] in commit message - Remove complex logic in favor of simpler workflow - Ensure developers retain control over versioning
- Split version check into separate steps with clear purposes - Use GitHub context properly for checking PR vs main branch - Add step outputs for better workflow control - Improve messaging with emojis for better readability - Maintain ability to skip checks when needed
- Remove the ability to skip version checks via commit message - Simplify version check logic to only run on pull requests - Update messaging for clarity and maintain informational checks for changed modules
- Streamline the release process instructions for better clarity - Emphasize the importance of creating a PR and updating the README version - Remove outdated steps and consolidate information on automated publishing
matifali
changed the title
mafredri
approved these changes
Apr 14, 2025
There was a problem hiding this comment.
It's unclear to me why --set-version or --tag is needed. I think a --bump=patch combined with --dry-run to see changes might be preferable. (Less modes of operation would make this script more approachable).
Other than the size/complexity of the script, looks good. Left some suggestions but I leave it up to you.
…functionality - Replace --check with --dry-run for clearer functionality - Remove --set-version option to simplify script usage - Keep only --bump=patch|minor|major for version updates - Update CONTRIBUTING.md with clear examples of script usage - Update CI workflow and package.json to use new options
- Update versioning workflow to create tags first, then PRs - Use annotated tags with commit messages - Add --auto-pr option to create PRs by github-actions[bot] - Update CONTRIBUTING.md with new workflow examples - Update CI workflow and package.json accordingly
…are pushed - Create workflow to update README when module tag is pushed - The workflow creates a PR as github-actions[bot] - Simplify module-version.sh to just handle tag creation - Update CONTRIBUTING.md with the new workflow details - Update package.json scripts
- Add auto-approval step using hmarr/auto-approve-action - Enable auto-merge using GitHub CLI - Update CONTRIBUTING.md to reflect fully automated process
- Add support for EXACT_VERSION environment variable - Replace bump_version with get_version function - Use existing script in GitHub Action workflow - Minimize code duplication between script and workflow
- Add --version=X.Y.Z parameter to set exact versions - Update get_version to use CLI option, environment variable, or bump logic in priority order - Update GitHub Action to use the new parameter instead of environment variable - Update documentation with examples using the new parameter
- Remove EXACT_VERSION environment variable support - Simplify get_version function to only use command-line arguments - Maintain only two options: --version or --bump
- Update CONTRIBUTING.md to reflect new tag-first workflow - Clarify that contributors don't need to update README versions manually - Remove version check from CI workflow as it's no longer needed - Update documentation with numbered steps for clarity
- Create release.sh for maintainers to create tags - Create update-version.sh for README version updates - Update GitHub workflow to use the new scripts - Update CONTRIBUTING.md with new script examples - Add --list option to release.sh to show module versions - Update package.json scripts
- Simplify update-version.sh to focus on version updates only - Simplify release.sh to only handle tag creation and listing - Remove the old modules-version.sh script - Use update-version.sh --check in the GitHub workflow - Rename functions for better clarity - Remove any --bump functionality as it's not needed
- Simplify update-version.sh to use positional arguments only - Simplify release.sh to have minimal options - Update GitHub workflow to match new script interfaces - Keep only essential features like --list and --dry-run - Update CONTRIBUTING.md to reflect simplified commands
- Replace peter-evans/create-pull-request with gh CLI - Set github-actions[bot] as PR author - Request review from cdr-bot for approval - Enable auto-merge using the gh pr merge command - Extract PR number for proper API integration
- Change PR author to cdrci - Implement auto-approve using hmarr/auto-approve-action - Follow GitHub's recommended pattern for auto-approval - Separate PR creation and approval into distinct steps - Pass PR number between steps using GITHUB_OUTPUT
- Remove all superfluous comments from scripts - Simplify scripts to be more concise - Streamline GitHub Actions workflow syntax - Keep only essential code and explanations
- Add explanatory comments to update-version.sh - Add detailed section comments to release.sh - Add workflow-level comments to GitHub Actions file - Explain purpose of each major code section - Enhance readability for maintainers and reviewers
|
@mafredri I ended up redoing most of it. I feel confident this is better and more flexible than the original approach. |
mafredri
previously requested changes
Apr 15, 2025
CONTRIBUTING.md
Outdated
| ./release.sh module-name 1.2.3 | ||
|
|
||
| # Push the tag to the repository | ||
| git push origin release/module-name/v1.2.3 |
There was a problem hiding this comment.
One issue with this approach is that the tag will not include the updated README, it'll be updated after tagging meaning when you git checkout release/module-name/v1.2.3 the README will state v1.2.2.
It's perhaps a minor thing, but makes me question the release method.
There was a problem hiding this comment.
Nice observation. Do you have any suggestions on a better approach?
We would have to reverse the behavior where the user chooses a tag, commits that to README, and then pushes a tag that matches that.
That will have more responsibility on the maintainer and can resurface #229.
update-version.sh
Outdated
| } | ||
| ' "$file" > "$tmpfile" && mv "$tmpfile" "$file" | ||
There was a problem hiding this comment.
Perhaps undo the awk changes, they don't make things better or clearer.
|
I would suggest reviewing the PR without looking at the diff. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request introduces significant changes to the automation and versioning processes within the project. The main changes include the removal of version checks from the CI workflow, the addition of a new GitHub Action for automatically updating README versions, and updates to the release process documentation. Additionally, new scripts were added to handle version updates and releases.
Automation and Versioning Improvements:
.github/workflows/ci.yaml: Removed the manual version check and update steps from the CI workflow. These checks will now be handled by maintainers after merging..github/workflows/update-readme-version.yaml: Added a new GitHub Action to automatically update README versions when a new tag is pushed. This action creates and auto-merges a PR with the version update.Documentation Updates:
CONTRIBUTING.md: Updated the release process documentation to reflect the new automated workflow. Maintainers now create and push annotated tags to trigger the version update process.Script Additions and Modifications:
release.sh: Added a new script to create annotated tags for module releases and list all modules with their versions. This script is used by maintainers to manage releases.update-version.sh: Modified the script to support both updating the version in README files and checking if the version matches a specified value. This script is used by the new GitHub Action.Miscellaneous Changes:
package.json: Removed theupdate-versionscript entry as it is now handled by the new GitHub Action.