GitHub Actions: Add Release and Bump Version workflows#2923
GitHub Actions: Add Release and Bump Version workflows#2923
Conversation
vaurdan
added
the
Maintenance & Fixes
📝 WalkthroughWalkthroughA new issue template Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Warning Tool Failures:Tool Failure Count:Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Outside diff range and nitpick comments (17)
.github/workflows/e2e-tests.yml (1)
Line range hint
1-58: Consider enhancing workflow reusability with inputs and secrets.While making the workflow reusable is a good first step, consider adding configurable inputs and secrets to make it more flexible when called from other workflows. This could include:
- Input to specify WordPress version
- Input to control test timeouts
- Input to specify which test suites to run
- Secrets for any sensitive configuration
This would make the workflow more versatile for different scenarios while maintaining its standalone functionality for PRs.
bin/update-version.sh (3)
18-20: Add version format validation.Consider adding validation to ensure the version follows semantic versioning format (X.Y.Z).
VERSION=$1 + +# Validate version format +if ! echo "$VERSION" | grep -qE '^[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?(\+[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?$'; then + echo "Error: Version must follow semantic versioning format (X.Y.Z)" + exit 1 +fi git checkout -b update/wp-parsely-version-to-$VERSION
36-41: Add file existence checks and backup mechanism.Consider adding safety checks to ensure files exist and implementing a backup mechanism.
+# Create backups directory +BACKUP_DIR="version_update_backup_$(date +%Y%m%d_%H%M%S)" +mkdir -p "$BACKUP_DIR" + +# Function to safely update file +update_file() { + local file="$1" + local expression="$2" + + if [ ! -f "$file" ]; then + echo "Error: File $file not found" + exit 1 + } + + cp "$file" "$BACKUP_DIR/" + sed_inplace "$expression" "$file" +} + # Update version in files -sed_inplace "s/Stable tag: .* $/Stable tag: $VERSION /" README.md -sed_inplace "s/\"version\": \".*\"/\"version\": \"$VERSION\"/" package.json +update_file "README.md" "s/Stable tag: .* $/Stable tag: $VERSION /" +update_file "package.json" "s/\"version\": \".*\"/\"version\": \"$VERSION\"/" # ... apply to other files
43-45: Improve git operations handling.While using
--ignore-scriptswith npm is good for security, the git operations could be more robust.npm install --ignore-scripts # Update package-lock.json with the new version -git add README.md package.json package-lock.json tests/e2e/utils.ts wp-parsely.php && git commit -m "Update wp-parsely version number to $VERSION" +# Stage changes if files exist +files_to_add=("README.md" "package.json" "package-lock.json" "tests/e2e/utils.ts" "wp-parsely.php") +for file in "${files_to_add[@]}"; do + if [ -f "$file" ]; then + git add "$file" + else + echo "Warning: $file not found" + fi +done + +# Only commit if there are staged changes +if ! git diff --cached --quiet; then + git commit -m "Update wp-parsely version number to $VERSION" +else + echo "No changes to commit" + exit 1 +fi.github/workflows/integration-tests.yml (2)
Line range hint
39-49: Consider additional test combinations for newer PHP versionsThe matrix configuration for PHP 8.2 and 8.4 is good, but consider these suggestions:
- Add a test combination for PHP 8.2 with WordPress trunk
- Consider adding Xdebug as a fallback for PHP 8.4 since PCOV might not be compatible
Add this to the matrix include section:
- php: '8.2' + wp: 'trunk' + coverage: none + experimental: false
Line range hint
71-78: Simplify Composer dependency installation stepsThe current implementation has duplicate conditions for PHP version. Consider combining these steps into a single step with dynamic composer options.
Replace the two steps with:
- - name: Install Composer dependencies - if: ${{ matrix.php < 8.2 }} - uses: ramsey/composer-install@v3 - - - name: Install Composer dependencies for PHP >= 8.2 - if: ${{ matrix.php >= 8.2 }} - uses: ramsey/composer-install@v3 - with: - composer-options: --ignore-platform-reqs + - name: Install Composer dependencies + uses: ramsey/composer-install@v3 + with: + composer-options: ${{ matrix.php >= 8.2 && '--ignore-platform-reqs' || '' }}.github/ISSUE_TEMPLATE/release-template-new.md (3)
1-6: Consider clarifying version number format in titleThe title template could be more explicit about the version number format to ensure consistency.
-title: Release wp-parsely x.y.z +title: Release wp-parsely {major}.{minor}.{patch}
9-12: Enhance visibility of critical timing informationThe release timing requirements are crucial information that should be more prominent.
-This is an issue for tracking the next `wp-parsely` release. This ticket is to be opened the week before the actual release, so we have enough time to complete all the related tasks. -The actual release of the plugin should be done on Mondays so we can catch the Tuesday WordPress VIP release window. +# Important Timing Requirements + +1. **Planning**: Open this ticket one week before the intended release date +2. **Release Day**: Must be executed on **Mondays** to align with Tuesday WordPress VIP release window
66-69: Enhance platform release instructionsThe platform release steps could be more detailed to ensure consistency.
**4. Release to other platforms** -[ ] Update the `vip-go-mu-plugins` submodule to the latest version. -[ ] Release the plugin for WordPress VIP. -[ ] Release the plugin for WordPress.com. +[ ] WordPress VIP Release: + - [ ] Update the `vip-go-mu-plugins` submodule to version {x.y.z} + - [ ] Create VIP platform release PR + - [ ] Verify VIP automated tests pass + - [ ] Obtain VIP team approval + - [ ] Monitor VIP release deployment + +[ ] WordPress.com Release: + - [ ] Follow WordPress.com plugin update process (link to docs) + - [ ] Verify successful deployment + - [ ] Monitor WordPress.com error logs post-deployment🧰 Tools
🪛 Markdownlint
66-66: null
Emphasis used instead of a heading(MD036, no-emphasis-as-heading)
.github/workflows/bump-version.yml (4)
1-2: Enhance workflow run name for better visibilityConsider making the run name more descriptive to better identify the workflow's purpose at a glance.
-run-name: Bump wp-parsely version to ${{ github.event.inputs.new_version }} +run-name: 🔄 Bumping wp-parsely from ${{ needs.validate_version.outputs.current_version }} to ${{ github.event.inputs.new_version }}
45-46: Improve version extraction robustnessThe current grep command might be fragile if the file format changes. Consider using a more robust approach.
-CURRENT_VERSION=$(grep -E "^ \* Version:" wp-parsely.php | awk '{print $3}') +CURRENT_VERSION=$(grep -E "^\s*\*\s*Version:\s*([0-9]+\.[0-9]+\.[0-9]+)" wp-parsely.php | grep -oE "[0-9]+\.[0-9]+\.[0-9]+")
54-66: Refactor version comparison logic for better maintainabilityThe inline PHP script could be moved to a separate file for better maintainability and testing.
Consider creating a
bin/validate-version.phpfile with proper error handling and unit tests.
111-119: Enhance PR description and add validationThe PR creation could benefit from better structure and error handling.
-gh pr create \ +if ! gh pr create \ --title "Update version number and changelog for ${{ env.NEW_VERSION }} release" \ --body "This PR updates the plugin's version number and changelog in preparation for the ${{ env.NEW_VERSION }} release. + +## Changes +- Updates version from ${{ env.CURRENT_VERSION }} to ${{ env.NEW_VERSION }} +- Updates changelog - $PARSELY_RELEASE_LOG" \ +## Changelog +$PARSELY_RELEASE_LOG + +## Checklist +- [ ] Version numbers updated +- [ ] Changelog formatted correctly +" \ --base ${{ github.ref_name }} \ --head update/wp-parsely-version-to-${{ env.NEW_VERSION }} \ - --assignee ${{ github.actor }} + --assignee ${{ github.actor }}; then + echo "::error::Failed to create PR" + exit 1 +fibin/release.php (1)
56-69: Consider adding a code comment explaining the heredoc syntax.The use of heredoc syntax (
<<EOF) for GitHub Actions environment variables might not be immediately clear to all developers.Add a comment explaining the syntax:
} else { - // Save the changelog to a environment variable for GitHub Actions. + // Save the changelog to a GitHub Actions environment variable using heredoc syntax. + // The <<EOF syntax allows for multi-line environment variables in GitHub Actions. $github_env = getenv( 'GITHUB_ENV' );.github/workflows/release-plugin.yml (3)
1-22: Add input validation patterns for branch and version.Consider adding pattern validation to the inputs:
branch: description: 'Built branch to release' required: false default: 'trunk-built' + pattern: '^[a-zA-Z0-9_.-]+$' version: description: 'Version to release (eg. 3.16.0)' required: true + pattern: '^[0-9]+\.[0-9]+\.[0-9]+$'
66-80: Enhance version validation.Consider adding validation for additional files:
- package-lock.json version
- readme.txt stable tag
- name: Checks if the version matches the version in wp-parsely.php and package.json if: ${{ env.DRY_RUN == false }} run: | PHP_VERSION=$(grep -E "^ \* Version:" wp-parsely.php | awk '{print $3}') JSON_VERSION=$(jq -r '.version' package.json) + LOCK_VERSION=$(jq -r '.version' package-lock.json) + README_VERSION=$(grep -E "^Stable tag:" readme.txt | awk '{print $3}') if [[ "${{ env.VERSION }}" != "${PHP_VERSION}" ]]; then echo "Version '${{ env.VERSION }}' does not match the version in wp-parsely.php" echo "Did you mean '${PHP_VERSION}'?" exit 1 fi if [[ "${{ env.VERSION }}" != "${JSON_VERSION}" ]]; then echo "Version '${{ env.VERSION }}' does not match the version in package.json." echo "Did you mean '${JSON_VERSION}'?" exit 1 fi + if [[ "${{ env.VERSION }}" != "${LOCK_VERSION}" ]]; then + echo "Version '${{ env.VERSION }}' does not match the version in package-lock.json." + echo "Did you mean '${LOCK_VERSION}'?" + exit 1 + fi + if [[ "${{ env.VERSION }}" != "${README_VERSION}" ]]; then + echo "Version '${{ env.VERSION }}' does not match the stable tag in readme.txt." + echo "Did you mean '${README_VERSION}'?" + exit 1 + fi
154-172: Add validation for release notes existence.Consider validating that release notes were successfully extracted.
- name: Extract Changelog id: extract_changelog run: | set -e VERSION=${{ env.VERSION }} START_LINE=$(grep -n "## \[${VERSION}\]" CHANGELOG.md | cut -d: -f1) if [ -z "$START_LINE" ]; then echo "Version not found in CHANGELOG.md" >&2 exit 1 fi TAIL_LINE=$(tail -n +$((START_LINE + 1)) CHANGELOG.md | grep -n "^## " | head -n 1 | cut -d: -f1 || true) if [ -z "$TAIL_LINE" ]; then END_LINE=$(wc -l < CHANGELOG.md) else END_LINE=$((START_LINE + TAIL_LINE - 1)) fi sed -n "${START_LINE},${END_LINE}p" CHANGELOG.md | sed '$d' > release_notes.md + if [ ! -s release_notes.md ]; then + echo "Failed to extract release notes for version ${VERSION}" >&2 + exit 1 + fi cat release_notes.md shell: bash
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (7)
.github/ISSUE_TEMPLATE/release-template-new.md(1 hunks).github/workflows/bump-version.yml(2 hunks).github/workflows/e2e-tests.yml(1 hunks).github/workflows/integration-tests.yml(1 hunks).github/workflows/release-plugin.yml(1 hunks)bin/release.php(1 hunks)bin/update-version.sh(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
bin/release.php (1)
Pattern **/*.{html,php}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the HTML and PHP code to ensure it is well-structured and adheres to best practices.
- Ensure the code follows WordPress coding standards and is well-documented.
- Confirm the code is secure and free from vulnerabilities.
- Optimize the code for performance, removing any unnecessary elements.
- Validate comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Verify code compatibility with the latest version of WordPress, avoiding deprecated functions or features."
🪛 Markdownlint
.github/ISSUE_TEMPLATE/release-template-new.md
15-15: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
25-25: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
36-36: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
41-41: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
45-45: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
54-54: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
58-58: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
62-62: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
66-66: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
🪛 actionlint
.github/workflows/bump-version.yml
30-30: property "php" is not defined in object type {}
(expression)
44-44: shellcheck reported issue in this script: SC2086:info:5:44: Double quote to prevent globbing and word splitting
(shellcheck)
44-44: shellcheck reported issue in this script: SC2086:info:6:44: Double quote to prevent globbing and word splitting
(shellcheck)
53-53: shellcheck reported issue in this script: SC2016:info:1:8: Expressions don't expand in single quotes, use double quotes for that
(shellcheck)
76-76: property "php" is not defined in object type {}
(expression)
103-103: shellcheck reported issue in this script: SC2086:info:2:6: Double quote to prevent globbing and word splitting
(shellcheck)
103-103: shellcheck reported issue in this script: SC2129:style:4:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
103-103: shellcheck reported issue in this script: SC2086:info:4:36: Double quote to prevent globbing and word splitting
(shellcheck)
103-103: shellcheck reported issue in this script: SC2086:info:5:32: Double quote to prevent globbing and word splitting
(shellcheck)
103-103: shellcheck reported issue in this script: SC2086:info:6:15: Double quote to prevent globbing and word splitting
(shellcheck)
.github/workflows/release-plugin.yml
47-47: shellcheck reported issue in this script: SC2006:style:2:17: Use $(...) notation instead of legacy backticks ...
(shellcheck)
131-131: shellcheck reported issue in this script: SC2086:info:11:32: Double quote to prevent globbing and word splitting
(shellcheck)
131-131: shellcheck reported issue in this script: SC2086:info:12:32: Double quote to prevent globbing and word splitting
(shellcheck)
🔇 Additional comments (8)
.github/workflows/e2e-tests.yml (1)
9-9: LGTM! Good addition of workflow_call trigger.
Making the E2E tests workflow reusable aligns well with the PR's objective of streamlining the release process.
bin/update-version.sh (2)
3-16: LGTM! Good error handling and documentation.
The script includes proper error handling for missing arguments and clear documentation about its cross-platform nature. Setting LC_ALL=C ensures consistent behavior across different locales.
22-34: LGTM! Well-implemented cross-platform compatibility.
The sed_inplace function effectively handles the differences between BSD (MacOS) and GNU (Linux) sed implementations. Good use of local variables for parameter handling.
.github/workflows/integration-tests.yml (2)
10-10: LGTM: Good addition of workflow_call trigger
Adding the workflow_call trigger enables workflow reusability, which aligns well with the PR's objective of creating new release workflows.
10-10: Verify workflow integration with release workflows
Since this workflow is now callable, let's verify its integration with the new release workflows.
✅ Verification successful
Integration with release workflow verified successfully
The integration-tests workflow is properly integrated in the release-plugin.yml workflow:
- Called as a reusable workflow in the integration_tests job
- Properly sequenced after version validation
- Includes appropriate conditional execution based on skip_tests parameter
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the integration-tests workflow is properly called by the new release workflows
# Expected: Find references to integration-tests workflow in the new release workflows
echo "Checking for workflow calls in release workflows..."
rg -l "uses: ./.github/workflows/integration-tests.yml" .github/workflows/
Length of output: 226
Script:
#!/bin/bash
# Let's examine the actual usage in release-plugin.yml to verify the integration
echo "Checking the integration in release-plugin.yml..."
rg -A 5 -B 5 "uses: ./.github/workflows/integration-tests.yml" .github/workflows/release-plugin.yml
Length of output: 523
.github/workflows/release-plugin.yml (3)
24-32: LGTM! Well-structured configuration.
Good use of concurrency control and environment variables for improved maintainability.
98-109: LGTM! Well-structured test configuration.
Good job on reusing existing workflows and implementing proper job dependencies.
192-233: LGTM! Secure and well-structured deployment configuration.
Good job on:
- Secure credential handling
- Proper artifact management
- Conditional deployment based on dry-run
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (2)
.github/ISSUE_TEMPLATE/release-template-new.md (2)
1-6: Enhance version format specification in the titleConsider using a more explicit version format placeholder to ensure consistency:
-title: Release wp-parsely x.y.z +title: Release wp-parsely {major}.{minor}.{patch}
9-11: Specify exact lead time requirementsThe current wording "the week before" is somewhat vague. Consider being more specific about the minimum required lead time.
-This ticket is to be opened the week before the actual release +This ticket is to be opened at least 5 business days before the planned release date
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
.github/ISSUE_TEMPLATE/release-template-new.md(1 hunks)
🧰 Additional context used
🪛 Markdownlint
.github/ISSUE_TEMPLATE/release-template-new.md
15-15: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
25-25: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
36-36: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
41-41: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
45-45: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
54-54: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
58-58: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
62-62: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
66-66: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
acicovic
left a comment
acicovic
left a comment
There was a problem hiding this comment.
This is great! Left some comments and questions.
|
Side-note: There seems to be a double blank line in |
|
@acicovic addressed your feedback and replied to your comments 🙂 |
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Outside diff range and nitpick comments (8)
delete_runs.sh (2)
16-16: Remove commented out code.Remove the commented-out code as it contains a different repository name and serves no purpose.
1-17: Consider adding documentation and dry-run mode.The script performs destructive operations and would benefit from additional safety features.
Consider adding:
- A help message explaining usage
- A dry-run mode to preview deletions
- Documentation about required permissions
- Rate limiting for API calls
- Progress indication for large numbers of workflow runs
Would you like me to provide an enhanced version with these improvements?
🧰 Tools
🪛 Shellcheck
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
[error] 11-11: Arrays implicitly concatenate in [[ ]]. Use a loop (or explicit * instead of @).
(SC2199)
[warning] 11-11: Remove quotes from right-hand side of =~ to match as a regex rather than literally.
(SC2076)
.github/ISSUE_TEMPLATE/release-template-new.md (1)
57-60: Add branch merge verification stepAfter merging trunk back into develop, it's important to verify the merge was successful.
- [ ] [Create a PR](https://github.com/Parsely/wp-parsely/compare/develop...trunk?quick_pull=1&title=Merge+trunk+into+develop+after+the+wp-parsely+x.y.z+release&body=This+PR+merges+the+`trunk`+branch+into+the+`develop`+branch+after+the+release+of+wp-parsely+x.y.z.) that merges `trunk` into `develop`, named _Merge trunk into develop after the wp-parsely x.y.z release_. - [ ] Merge the PR into `develop`. +- [ ] Verify the successful merge by checking that: + - [ ] No merge conflicts were auto-resolved + - [ ] The branch protection rules were satisfied + - [ ] The CI checks passed🧰 Tools
🪛 Markdownlint
57-57: null
Emphasis used instead of a heading(MD036, no-emphasis-as-heading)
.github/workflows/release-plugin.yml (5)
7-12: Enhance input parameter descriptions for clarity.The descriptions could be more specific:
- "Built branch to release" could clarify that it expects a branch with compiled assets
- "Version to release" could mention that it must follow semver format (x.y.z)
69-80: Enhance version mismatch error messages.Consider adding more context to the error messages:
- Include both the expected and actual versions in the same line
- Add guidance on how to fix the mismatch
- echo "Version '${{ env.VERSION }}' does not match the version in wp-parsely.php" - echo "Did you mean '${PHP_VERSION}'?" + echo "Version mismatch in wp-parsely.php: Expected '${{ env.VERSION }}' but found '${PHP_VERSION}'" + echo "To fix: Run 'bin/update-version.sh ${{ env.VERSION }}' to update all version references"
97-108: Add warning when tests are skipped.Consider adding a step to log a prominent warning when tests are skipped to prevent accidental releases without testing.
- name: Warning - Tests Skipped if: ${{ github.event.inputs.skip_tests == 'true' }} run: | echo "::warning::Release proceeding without running tests. This should only be done in exceptional circumstances!"
144-145: Add tag verification step.Consider adding a verification step after pushing the tag to ensure it was created successfully.
git tag "${TAG_NAME}" git push origin "${TAG_NAME}" +# Verify the tag was created successfully +if ! git ls-remote --tags origin | grep -q "refs/tags/${TAG_NAME}$"; then + echo "::error::Failed to create tag ${TAG_NAME} on remote" + exit 1 +fi
208-218: Add post-deployment verification step.Consider adding a step to verify the deployment was successful by checking the WordPress.org repository.
- name: Verify WordPress.org Deployment if: ${{ !env.DRY_RUN }} run: | # Wait for WordPress.org to process the deployment sleep 30 # Verify the new version is available RESPONSE=$(curl -s "https://api.wordpress.org/plugins/info/1.0/wp-parsely.json") if ! echo "$RESPONSE" | grep -q "\"version\":\"${{ env.VERSION }}\""; then echo "::warning::Version ${{ env.VERSION }} not found on WordPress.org. This may be due to processing delay." fi
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (6)
.github/ISSUE_TEMPLATE/release-template-new.md(1 hunks).github/workflows/build-plugin.yml(0 hunks).github/workflows/bump-version.yml(2 hunks).github/workflows/release-plugin.yml(1 hunks)bin/update-version.sh(1 hunks)delete_runs.sh(1 hunks)
💤 Files with no reviewable changes (1)
- .github/workflows/build-plugin.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- bin/update-version.sh
🧰 Additional context used
🪛 Markdownlint
.github/ISSUE_TEMPLATE/release-template-new.md
14-14: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
24-24: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
35-35: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
40-40: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
44-44: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
53-53: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
57-57: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
61-61: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
65-65: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
🪛 actionlint
.github/workflows/bump-version.yml
44-44: shellcheck reported issue in this script: SC2086:info:5:44: Double quote to prevent globbing and word splitting
(shellcheck)
44-44: shellcheck reported issue in this script: SC2086:info:6:44: Double quote to prevent globbing and word splitting
(shellcheck)
53-53: shellcheck reported issue in this script: SC2016:info:1:8: Expressions don't expand in single quotes, use double quotes for that
(shellcheck)
97-97: shellcheck reported issue in this script: SC2181:style:3:6: Check exit code directly with e.g. 'if ! mycmd;', not indirectly with $?
(shellcheck)
107-107: shellcheck reported issue in this script: SC2086:info:2:6: Double quote to prevent globbing and word splitting
(shellcheck)
107-107: shellcheck reported issue in this script: SC2129:style:4:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
107-107: shellcheck reported issue in this script: SC2086:info:4:36: Double quote to prevent globbing and word splitting
(shellcheck)
107-107: shellcheck reported issue in this script: SC2086:info:5:32: Double quote to prevent globbing and word splitting
(shellcheck)
107-107: shellcheck reported issue in this script: SC2086:info:6:15: Double quote to prevent globbing and word splitting
(shellcheck)
.github/workflows/release-plugin.yml
47-47: shellcheck reported issue in this script: SC2006:style:2:17: Use $(...) notation instead of legacy backticks ...
(shellcheck)
130-130: shellcheck reported issue in this script: SC2086:info:11:32: Double quote to prevent globbing and word splitting
(shellcheck)
130-130: shellcheck reported issue in this script: SC2086:info:12:32: Double quote to prevent globbing and word splitting
(shellcheck)
🪛 Shellcheck
delete_runs.sh
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
[error] 11-11: Arrays implicitly concatenate in [[ ]]. Use a loop (or explicit * instead of @).
(SC2199)
[warning] 11-11: Remove quotes from right-hand side of =~ to match as a regex rather than literally.
(SC2076)
🔇 Additional comments (5)
.github/ISSUE_TEMPLATE/release-template-new.md (2)
1-11: LGTM: Well-structured template metadata and clear introduction
The metadata and introduction effectively communicate the purpose and timing requirements for the release process.
35-38: Verify GitHub Actions workflow links
Please ensure that the GitHub Actions workflow links are correct and accessible:
workflows/bump-version.ymlworkflows/build-plugin.ymlworkflows/release-plugin.yml
Also applies to: 45-47
✅ Verification successful
Let me verify the actual workflow URLs in the files to ensure they match what's referenced in the template.
GitHub Actions workflow links are valid and correctly referenced
All the GitHub Actions workflows mentioned in the release template are present in the repository and their URLs are correctly referenced:
- The "Bump wp-parsely version" workflow exists as
bump-version.yml - The "Release wp-parsely" workflow exists as
release-plugin.yml - The workflow names in the files match their references in the template
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the GitHub Actions workflow files exist and are accessible
echo "Checking workflow files..."
for workflow in "bump-version.yml" "build-plugin.yml" "release-plugin.yml"; do
if [ -f ".github/workflows/$workflow" ]; then
echo "✓ $workflow exists"
else
echo "✗ $workflow not found"
fi
done
Length of output: 626
Script:
#!/bin/bash
# Check the actual workflow URLs in the template file
echo "=== Checking workflow URLs in template ==="
grep -A 1 "Run the" .github/ISSUE_TEMPLATE/release-template-new.md
echo -e "\n=== Checking actual workflow URLs in files ==="
for file in .github/workflows/*.yml; do
echo "=== $file ==="
grep "name:" "$file" | head -n 1
done
Length of output: 3272
🧰 Tools
🪛 Markdownlint
35-35: null
Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
.github/workflows/bump-version.yml (1)
Line range hint 1-14: LGTM! Well-structured workflow configuration.
The workflow metadata, trigger configuration, and environment variable setup are properly implemented.
🧰 Tools
🪛 actionlint
44-44: shellcheck reported issue in this script: SC2086:info:5:44: Double quote to prevent globbing and word splitting
(shellcheck)
44-44: shellcheck reported issue in this script: SC2086:info:6:44: Double quote to prevent globbing and word splitting
(shellcheck)
53-53: shellcheck reported issue in this script: SC2016:info:1:8: Expressions don't expand in single quotes, use double quotes for that
(shellcheck)
97-97: shellcheck reported issue in this script: SC2181:style:3:6: Check exit code directly with e.g. 'if ! mycmd;', not indirectly with $?
(shellcheck)
107-107: shellcheck reported issue in this script: SC2086:info:2:6: Double quote to prevent globbing and word splitting
(shellcheck)
107-107: shellcheck reported issue in this script: SC2129:style:4:1: Consider using { cmd1; cmd2; } >> file instead of individual redirects
(shellcheck)
107-107: shellcheck reported issue in this script: SC2086:info:4:36: Double quote to prevent globbing and word splitting
(shellcheck)
107-107: shellcheck reported issue in this script: SC2086:info:5:32: Double quote to prevent globbing and word splitting
(shellcheck)
107-107: shellcheck reported issue in this script: SC2086:info:6:15: Double quote to prevent globbing and word splitting
(shellcheck)
.github/workflows/release-plugin.yml (2)
109-116: LGTM! Job dependencies and failure handling are well configured.
180-190: LGTM! Release creation is well configured with proper draft handling.
…ws' into add/release-bump-version-workflows
acicovic
left a comment
acicovic
left a comment
There was a problem hiding this comment.
Thank you so much for your answers.
This is excellent. Thank you for working on this!
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
.github/workflows/release-plugin.yml (2)
35-96: Consider adding version comparison validation.While the version validation is comprehensive, consider adding a check to ensure the new version is greater than the previous release version.
#!/bin/bash # Get the latest released version LATEST_VERSION=$(git tag --list | grep -E '^[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -n1) if [[ ! -z "$LATEST_VERSION" ]] && [[ "$(printf '%s\n' "$LATEST_VERSION" "${{ env.VERSION }}" | sort -V | head -n1)" != "${{ env.VERSION }}" ]]; then echo "New version ${{ env.VERSION }} must be greater than the latest version ${LATEST_VERSION}" exit 1 fi🧰 Tools
🪛 actionlint
47-47: shellcheck reported issue in this script: SC2006:style:2:17: Use $(...) notation instead of legacy backticks
...(shellcheck)
153-179: Consider improving changelog extraction error handling.While the changelog extraction is functional, consider adding these improvements:
- Add error handling for malformed changelog entries
- Validate markdown header hierarchy
- Ensure consistent newline handling
sed -n "${START_LINE},${END_LINE}p" CHANGELOG.md | sed '$d' > release_notes.md +# Validate markdown structure +if grep -q "^#[^#]" release_notes.md; then + echo "Error: Found H1 headers in changelog entry. Only H2 and H3 are allowed." + exit 1 +fi +# Ensure consistent newlines at end +echo "" >> release_notes.md
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/release-plugin.yml(1 hunks)
🧰 Additional context used
🪛 actionlint
.github/workflows/release-plugin.yml
47-47: shellcheck reported issue in this script: SC2006:style:2:17: Use $(...) notation instead of legacy backticks ...
(shellcheck)
130-130: shellcheck reported issue in this script: SC2086:info:11:32: Double quote to prevent globbing and word splitting
(shellcheck)
130-130: shellcheck reported issue in this script: SC2086:info:12:32: Double quote to prevent globbing and word splitting
(shellcheck)
🔇 Additional comments (6)
.github/workflows/release-plugin.yml (6)
1-27: LGTM! Well-structured workflow configuration.
The workflow configuration is clear and comprehensive with:
- Descriptive run-name that includes version and dry-run status
- Well-defined input parameters
- Proper concurrency handling to prevent parallel runs
28-32: LGTM! Good use of environment variables.
Environment variables are well-defined for commonly used values, improving maintainability.
97-108: LGTM! Well-structured test execution.
Good use of reusable workflows for tests with the ability to skip when needed.
109-116: LGTM! Well-structured job dependencies and outputs.
The job correctly depends on validation and tests, with proper failure handling and output definition.
180-190: LGTM! Well-structured release creation.
Good use of draft status to ensure release is complete before becoming public.
191-232: LGTM! Secure and complete deployment configuration.
The deployment is well-structured with:
- Proper secrets handling
- ZIP file generation and attachment
- Conditional dry-run support
… * Make the e2e and integration tests workflows reusable * Add release-plugin workflow * Add bump version workflow * Tweak binaries to work within Github Actions * Add new Release check-list. * Update release-template-new.md * Apply code review feedback * Remove unwanted file * Add missing period." (d0f9f68)
2 participants
Description
This PR adds two new workflows for the release process:
bin/release.phpscript.Motivation and context
How has this been tested?
Tested extensively on a different branch, directly on GitHub.
Summary by CodeRabbit
Release Notes
New Features
wp-parselyplugin.Improvements
Bug Fixes