Workflows: Sync assets to plugin repo upon change in trunk #68052
Conversation
ockham
added
[Type] Enhancement
|
Should the entire assets dir be synced? It would have to be updated from trunk first. It seems like either the assets should be managed from this repo or not, it seems kind of strange to manage some assets, especially since we have an assets directory now. If we're only going to sync blueprints, then perhaps the directory structure should be rethought in this repo. |
|
After briefly reflecting on it myself, I do think the whole assets directory should be managed from this repo. Ultimately, the plugin itself is the most important asset and that's managed from here. |
|
Yeah, that's a fair point. This means we'll have to add the existing assets to the GH repo. We can do that as part of this PR. |
|
Flaky tests detected in 10aaba2. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12394362673
|
Yeah, that's correct. Now that you mention it, we can also change that behavior, to decouple it from plugin uploads. |
|
It makes sense to sync when the assets change, in my opinion. There's no reason for this to be coupled to a plugin release. |
I tend to agree, but loose opinion. |
Co-authored-by: sirreal <jonsurrell@git.wordpress.org>
Co-authored-by: Miguel Fonseca <150562+mcsf@users.noreply.github.com>
| svn st | awk '/^?/ {print $2}' | xargs -r svn add | ||
| svn st | awk '/^!/ {print $2}' | xargs -r svn rm | ||
| svn commit "assets" \ | ||
| -m "Sync assets for version $VERSION" \ |
There was a problem hiding this comment.
I think we can swap the version for the commit sha.
| name: Sync assets | ||
| runs-on: ubuntu-latest | ||
| environment: wp.org plugin | ||
| if: ${{ github.event.release.assets[0] }} |
There was a problem hiding this comment.
I think we want to filter to:
- run only on commits
- only to
trunkbranch - only when there are changes in
assets/
There was a problem hiding this comment.
I'll probably move the entire job to a whole new workflow file, with the trigger set accordingly 👍
Co-authored-by: Jon Surrell <sirreal@users.noreply.github.com>
|
I'm currently testing this on my personal fork, and will be pushing fixes based on that testing shortly. |
|
One thing to consider, if this is landed with the new assets I'd expect it to immediately run when it's merged. |
You're correct @sirreal 😄 That's what happened on my personal fork 👍 |
|
This should be ready for review. I've documented how I tested this in the PR description's Testing Instructions. |
ockham
changed the title
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
ockham
changed the title
|
Note that this since this new workflow uses SVN credentials, the workflow needs approval by a member of the |
|
Maybe best to add a section to the Release process > Synchronizing the Gutenberg plugin @ockham What do you think? |
Hmm, not 100% sure TBH, since those docs are very much focused on individual GB releases and the publishing of npm packages, which is somewhat coupled to the latter. However, the workflow that this PR introduces will be pretty much independent from those existing workflows, and will run any time a file in Maybe it's fine to document it there, but I'm a bit concerned about visibility (those docs are quite verbose already) -- will people go to look there if they change an asset? Come to think of it, we could maybe add a |
|
Thank you @sirreal! I'll merge this, and will file a follow-up to add a README (as mentioned here) (plus the necessary changes to exclude the README itself from being synced). BTW as you said, merging this PR will trigger the new workflow. There's a chance that it'll fail, as the assets we're including are identical to the ones that are already in svn, so the commit won't include any changes (and I'm not sure what svn does in a case like that). That shouldn't be a problem though -- any future changes to the assets will mean that they're actually different from the ones in svn, and will trigger the sync, as desired. |
|
Here's the workflow run. It doesn't seem to have committed anything to svn; it also didn't fail. Should be fine. |
Actually, it would be good to add and sync that README file to the plugin repo so it's clear everywhere that the assets directory is managed via this repository and direct changes to SVN will be overwritten. I asked if there's any downside to adding other files to the assets directory here. |
Fixes #67835.
What?
Sync the
assets/directory to the plugin svn repo whenever a file in that directory is changed as part of a commit totrunkWhy?
To sync the plugin repo's assets for the Gutenberg plugin with the latest changes from git.
How?
By checking out the
assets/directory from git, and using it to replace the contents of the assets in the Gutenberg plugin's svn directory.Testing Instructions
I have a test SVN repo that I had already set up to include the
assets/directory from the GB plugin repo, plus atest.txtfile in that directory.I tested this workflow by adding a commit to set the plugin repo URL to that test svn repo, and force-pushing the git branch to my personal Gutenberg fork's
trunk. The workflow run passed, you can see it here. (It removed thetest.txtfile, as it's not present in git).The commit message recorded in my test SVN repo is
Sync assets for commit 97de59b764c9017242d1da44a034015fc262fb80.