fix(ci): sync WordPress.org assets via scoped svn (monorepo-safe)#3882
Merged
Conversation
…et-update action Follow-up to #3880. The deploy-wporg-assets workflow used 10up/action-wordpress-plugin-asset-update, which assumes a single-plugin repo: it rsyncs $GITHUB_WORKSPACE (our monorepo root) into the plugin's SVN trunk/ and then fails reverting trunk/vendor/composer ("Can't create directory ... trunk/ vendor/composer: No such file or directory"). A manual run confirmed it cannot work in this layout (nothing was deployed; its safety check aborts the trunk clobber anyway). Replace the action with a direct, assets-only svn commit: check out just the assets/ subtree, rsync the plugin's .wordpress-org into it, stage adds/deletes, set image mime-types, and commit. Scoping the working copy to assets/ is both monorepo-correct and safer — a commit here cannot touch trunk/ or tags/.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
jasonbahl
added a commit
that referenced
this pull request
Jun 4, 2026
Sync main (split PRs #3877/#3878/#3879 + asset-pipeline #3880/#3882/#3883) into the IDE rebuild branch. Conflicts were all IDE release-metadata + the plugin header; resolved as: - package.json / wpgraphql-ide.php Version / readme.txt Stable tag: 4.5.0 (the release-please manifest value; release-please bumps to 5.0.0 at release — the in-repo version tracks the last release per the plugin's CLAUDE.md). - CHANGELOG.md / readme.txt changelog: union — keep the 5.0.0 notes AND main's released 4.5.0 entry. - Requires at least: 6.1 (not the 7.0 the branch had staged). WordPress 7.0's i18n features (.l10n.php 6.5, JIT textdomain 6.7) degrade gracefully and no runtime gate gates on 7.0, so there's no reason to lock out current installs. Dropped the "raised floor to 7.0" breaking-change note and aligned CLAUDE.md + i18n docs to 6.1. - Tested up to: 7.0 (WordPress 7.0 is released).
jasonbahl
added a commit
to josephfusco/wp-graphql
that referenced
this pull request
Jun 4, 2026
Sync main (split PRs wp-graphql#3877/wp-graphql#3878/wp-graphql#3879 + asset pipeline wp-graphql#3880/wp-graphql#3882/wp-graphql#3883) onto the IDE rebuild branch, on top of Joe's floor/CI commits (floor 6.1, WP 7.0 CI coverage + tested-up-to). Conflicts (all IDE release metadata) resolved as: - Version / Stable tag / package.json: 4.5.0 (release-please manifest value; release-please bumps to 5.0.0 at release — in-repo version tracks last release per the plugin's CLAUDE.md). - CHANGELOG.md / readme.txt changelog: union — keep the 5.0.0 notes AND main's released 4.5.0 entry. Dropped the now-inaccurate "raised floor to 7.0" breaking-change note (Joe set the floor to 6.1) and the 7.0-floor framing in the i18n docs. - Requires at least: 6.1 / Tested up to: 7.0 — kept Joe's values.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Follow-up to #3880.
Problem
The
deploy-wporg-assetsworkflow added in #3880 used10up/action-wordpress-plugin-asset-update. A manual run failed:That action assumes a single-plugin repo: its
deploy.shrsyncs$GITHUB_WORKSPACE(our monorepo root) into the plugin's SVNtrunk/, then tries tosvn revert trunk/vendor/composer— which it just deleted, because the monorepo root has no top-levelvendor/. It also re-syncs trunk at all, which we don't want for an asset-only update.Nothing was deployed (the action's own "other files modified" check would abort the trunk clobber regardless), but the action simply can't work in this layout.
Fix
Replace the action with a direct, assets-only
svncommit:svn checkoutonly theassets/subtree for the plugin's.orgslug.rsync --deletethe plugin's.wordpress-org/into it.svn:mime-typeon images (so they render inline, not download).Because the working copy is scoped to
assets/, a commit here cannot touchtrunk/ortags/— strictly safer than the action. The detect job, triggers (auto-on-push + manual dispatch), and slug resolution from #3880 are unchanged.After merge
Run Actions → Deploy WordPress.org Assets → Run workflow →
component: allto backfill the brand refresh to all four.orgplugin pages.Validation
js-yaml).uses:of the 10up asset-update action (only explanatory comments reference it).