Add commit to SVN action from 10up?

[dingo-d]

I think that we could utilise this one, maybe modify if needed:

https://10up.com/blog/2019/introducing-github-actions-for-wordpress-plugins/

Seems like it would help with any future release of the plugin.

[timelsass]

I've given this a bit of thought the past month, and it's a useful workflow, but I'm still 50/50 on the idea with some projects I work on too. I think it's of most benefit to projects that aren't complex, and also projects that don't have a build && test step. Currently I use a script in travis deploy like: https://www.npmjs.com/package/@boldgrid/wordpress-tag-sync

The issue with a github action is that it's just being done on tag. Then you also have all the other tedious steps. I guess there's nothing wrong with it, but it does leave room for error. Ideally I think everyone wants to get unit tests in, run passing builds on travis, and on build success && tag, just have travis deploy. With the github action, you have to rely more on yourself to check the build status before you do the commit.

I've experimented with a few different ways lately, but at the moment my preference has been using yarn version:

scripts: {
    "preversion": "bash build/cwd-dirty && git checkout dev && yarn build",
    "postversion": "git tag -d $npm_package_version && node build/update-version.js src/plugin-file.php $npm_package_version && git commit -am \"Updating Version $npm_package_version\" && git push origin dev && git checkout master && git pull origin master && git pull origin dev && git push origin master && git tag -a $npm_package_version -m \"Version $npm_package_version Release\" master && git push origin $npm_package_version",
}

walkthrough of above:

• I run yarn version It's interactive input which shows the old version and then I can easily type in the new one without looking in other places. You can pass the version number as a parameter, or use semver lingo to bump the versions like yarn version patch ect.
• The preversion hook is triggered in npm, the script above in bash just checks if the git working directory is dirty so nothing accidentally gets pushed.
• check out to dev in case I wasn't already there.
• run build
• during this time if that fails all those processes exit properly and the versions aren't incremented in files, and nothing is tagged.
• the npm version happens when preversion hook finishes, and package.json is incremented and git is tagged.
• In postversion I actually first delete the local tag that was created. This is because there's a bug in some npm versions which don't trigger the postversion hooks properly if you disable the git tagging in .npmrc or via cli configs. In postversion hook npm's $npm_pacakge_version variable is available which is the new version incremented to, so that's the tag to delete since it was just made.
• Once deleted the update-version.js script (just a simple find and replace) finds the version info I want to update in the main plugin file (or really whatever you want to do there).
• The rest is pretty self explanatory, just commit checkout to master, merge, tag, and push up everything.
• Travis is triggered for build. We know everything at this point should pass from our own local environment build, but I let travis build in alternate environments (if supported, ie 5.6, 7.0) just as last sanity checks.
• on build success, everythings good and it's a tag, so then the .zip script is ran to package it up.
• then run deployment to github releases so I have a named zip fresh for each release.
• finally once github deploy is done and uploaded, the last script runs the SVN deploy to .org repo.

The result of this is my deployments now are just one simple command, tell it what version it needs, and everything else just magics itself. I also have other builds that need to be ran when certain things are released, ie other repos using them as dependencies, so the extra control gives me the ability to use travis' API, trigger builds on other repos, and do all the same things for dependency repos and whatnot. Just thought I'd share that with you as it's been a lot of learning and experimentation for me over time.

[joyously]

So, couldn't you make the GitHub action trigger on your 2nd to last step?

[timelsass]

I could if the only part I needed was build and test on my local environment then deploy. That's never a safe assumption though. A lot of developers don't teardown their local environments whenever they get ready to do a release if you work in a team as well.

As an example, I did a release yesterday and locally everything was great, but I actually had a path in my webpack config which was relative from the themes directory, and when the webpack build would finish, it was using the parent theme's path for the dynamic imports. Whenever I loaded the sections that loaded the chunks it was always coming from that parent instead of the built result. Something easy to overlook if you're not paying attention. When the travis build failed, I could see that it's because the expected path to that parent didn't exist. If it didn't, then a release with a bug would have been released, and likely not caught until someone was in the specific area where the dynamic import actually tries to load the script.

It's important for me to run the tests on multiple versions of PHP, and WP, as well as some environment specific tests. It takes a long time to build and tear down those various environments especially when travis (or any ci really) just accepts a matrix and handles everything and leaves out (more or less lol) the human error parts.