Open dingo-d opened 5 years ago
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:
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 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.
So, couldn't you make the GitHub action trigger on your 2nd to last step?
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.
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.