Add plugin size audit workflow PRESS10-98#130
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
crodriguezbrito
changed the title
crodriguezbrito
changed the title
| SIZE_DIFF: ${{ steps.compare_plugin_sizes.outputs.SIZE_DIFF }} | ||
| FAILED: ${{ steps.compare_plugin_sizes.outputs.FAILED }} | ||
| run: | | ||
| REPORT="final-report.md" |
Check failure
Code scanning / octoscan
Expression injection, "env.**" is potentially untrusted. Error
There was a problem hiding this comment.
While environment variables can change, inputs cannot. What about moving the MAX_SIZE_INCREASE_PERCENT and MAX_ZIP_SIZE_MB to workflow inputs instead of hard coding them as environment variables at the workflow level? The current values can be used as the defaults and the inputs can be made optional.
This would allow a given repo to adjust these thresholds if they desire while also closing these potentially insecure paths. Though it's not clear to me why this pattern is triggering an alert on this step but not others where env.* is also being used, this seems like a reasonable adjustment to prevent this.
desrosj
left a comment
desrosj
left a comment
There was a problem hiding this comment.
Thanks for this, @crodriguezbrito!
I left some initial feedback. For the sake of transparency, I haven't reviewed the commands that are actually performing comparisons. Just a high-level review of the GHA related code so far.
Also, is this in any way related to newfold-labs/wp-plugin-bluehost#342? That one seems to focus on the sizes of individual files rather than the size of the plugin as a whole. Not necessarily a blocker for this, but it would be nice to eventually have a reusable workflow for each. Then each plugin can have a single workflow with two jobs: one for file sizes, one for plugin package size.
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a reusable GitHub Actions workflow for auditing WordPress plugin size, comparing the current branch against the base branch and ensuring size increases stay within acceptable limits.
Key Changes:
- Adds automated plugin size auditing with configurable thresholds (10% size increase, 10 MB max zip size)
- Implements comparison logic between current and base branches for pull requests
- Posts size audit reports as PR comments with automatic updates
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Hello @desrosj I greatly appreciate your feedback. I have answered to all suggestions and made the necessary commits. Regarding your question: Following the comment in Jira, I have created this workflow specifically to measure the total size of the plugin. I believe both workflows are related, and it would be a great idea to add them as reusable workflows and then use them in combination. Please let me know if there is anything else to review. Thanks you for your time. |
… title to prevent conflcits with other workflows.
crodriguezbrito
changed the title
|
@crodriguezbrito - Can you look through the security issues and review the two unresolved comments from Jon? |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
This is the final PR Bugbot will review for you during this billing cycle
Your free Bugbot reviews will reset on December 23
Details
You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
…s to prevent execution from untrusted forks
|
@desrosj - Since you requested changes, you'll have to re-review this anyway. Do you mind making a pass at it? |
There was a problem hiding this comment.
This PR is being reviewed by Cursor Bugbot
Details
You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
|
|
||
| - name: NPM Install for Base Branch | ||
| if: github.event.pull_request.head.repo.full_name == github.repository && github.event_name == 'pull_request' | ||
| run: npm ci --ignore-scripts |
There was a problem hiding this comment.
Bug: Fork PRs skip base branch build causing incorrect comparison
The condition github.event.pull_request.head.repo.full_name == github.repository prevents npm install and build for the base branch when PRs come from forks. However, the base branch is always in the main repository (not the fork), so this check is misapplied. For fork PRs, the workflow will compare the PR branch (with built JavaScript) against the base branch (without built JavaScript), producing invalid size comparisons. The condition on these steps should match the other base branch steps which only check github.event_name == 'pull_request'.
Additional Locations (1)
| const existingComment = comments.data.find(comment => | ||
| comment.user.type === 'Bot' && | ||
| comment.body.includes('## Plugin Size Audit: Folder and Zip Report') | ||
| ); |
There was a problem hiding this comment.
Bug: Comment search misses existing comments on busy PRs
The listComments API call doesn't specify pagination parameters, so it only retrieves the first page (default 30 comments). If the PR has more than 30 comments and the bot's existing audit comment isn't among the most recent 30, the find search won't locate it. This causes duplicate comments to be created on subsequent workflow runs for PRs with active discussion.
desrosj
left a comment
desrosj
left a comment
There was a problem hiding this comment.
Sorry for the delay getting back to this! I have a few small suggestions here. But I think it should be good to give a try!
| env: | ||
| CURRENT_SIZE_BYTES: ${{ steps.plugin_size.outputs.total_size_bytes }} | ||
| BASE_SIZE_BYTES: ${{ steps.base_plugin_size.outputs.base_total_size_bytes }} | ||
| MAX_INCREASE_PERCENT: ${{ env.MAX_SIZE_INCREASE_PERCENT }} |
There was a problem hiding this comment.
| MAX_INCREASE_PERCENT: ${{ env.MAX_SIZE_INCREASE_PERCENT }} | |
| MAX_SIZE_INCREASE_PERCENT: ${{ env.MAX_SIZE_INCREASE_PERCENT }} |
To be consistent with the next step.
| echo "Size Difference (Bytes): $SIZE_DIFF" | ||
| echo "Percentage Increase: $PERCENT_INCREASE%" | ||
| if [ "$PERCENT_INCREASE" -gt "$MAX_INCREASE_PERCENT" ]; then | ||
| echo "::error::Plugin size increased by $PERCENT_INCREASE%, which exceeds the maximum allowed increase of $MAX_INCREASE_PERCENT%." |
There was a problem hiding this comment.
| echo "::error::Plugin size increased by $PERCENT_INCREASE%, which exceeds the maximum allowed increase of $MAX_INCREASE_PERCENT%." | |
| echo "::error::Plugin size increased by $PERCENT_INCREASE%, which exceeds the maximum allowed increase of $MAX_SIZE_INCREASE_PERCENT%." |
To match above change.
| SIZE_DIFF: ${{ steps.compare_plugin_sizes.outputs.SIZE_DIFF }} | ||
| FAILED: ${{ steps.compare_plugin_sizes.outputs.FAILED }} | ||
| run: | | ||
| REPORT="final-report.md" |
There was a problem hiding this comment.
While environment variables can change, inputs cannot. What about moving the MAX_SIZE_INCREASE_PERCENT and MAX_ZIP_SIZE_MB to workflow inputs instead of hard coding them as environment variables at the workflow level? The current values can be used as the defaults and the inputs can be made optional.
This would allow a given repo to adjust these thresholds if they desire while also closing these potentially insecure paths. Though it's not clear to me why this pattern is triggering an alert on this step but not others where env.* is also being used, this seems like a reasonable adjustment to prevent this.
3 participants
Proposed changes
This PR includes a new workflow designed to control file size growth by implementing two checks:
Production File Size Comparison: Compares the production file size between the base branch and the PR branch. The workflow will fail if the size increase exceeds 10%.
Plugin Zip Size Validation: Calculates the size of the generated plugin ZIP file. The workflow will fail if the size is greater than 10 MB.
Jira: PRESS10-98
Type of Change
Production
Development
Visual
Checklist
Further comments
Note
Adds a reusable GitHub Actions workflow to build the plugin, compute folder/zip sizes, compare with base on PRs, comment a report, and fail when thresholds are exceeded.
/.github/workflows/reusable-plugin-size-audit.yml:distvia.distinclude/.distignore.MAX_SIZE_INCREASE_PERCENTandMAX_ZIP_SIZE_MB.Written by Cursor Bugbot for commit 42a7882. This will update automatically on new commits. Configure here.