10up
Add files for GH Actions deployment to WordPress.org
Description of the Change
Adds the following as a starting point for using GitHub Actions to deploy plugins to the WordPress.org repository, particularly helpful for people who use this repo as a template directly on GitHub:
.github/workflows/dotorg-deploy.yml.github/workflows/dotorg-asset-readme-update.yml.wordpress-org/README.md.distignore
The .wordpress-org directory contains a README.md for two reasons: one, you can't commit an empty directory in Git, and two, I don't want to potentially propagate the same imagery for a bunch of plugins if everything runs immediately, since that asset/readme update happens on pushes to master.
Alternate Designs
n/a - however, I would like a review on the contents on .distignore, if there's anything else that should typically be excluded from deployment to WordPress.org post-build.
Benefits
People using this repository for GitHub-based repositories (e.g. via template functionality in the web UI) who want to deploy to WordPress.org will be able to get up and running much more easily.
Possible Drawbacks
People who don't want to deploy to .org will need to delete extra things. It may also trigger a readme/asset update attempt on initial copy using the template functionality, although it should fail since the secrets won't have been set yet.
Verification Process
Can't really verify this in a sane way at the moment but these are mostly copied from functioning examples.
Checklist:
- [x] I have read the CONTRIBUTING document.
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my change.
- [ ] All new and existing tests passed.
Applicable Issues
Fixes #100
Changelog Entry
n/a, maybe this project needs a changelog
@helen looks like something is weirding out here, can you take a look at what's failing?
@timwright12 The failures were from a hiccup while we were changing our plan type, they can be ignored. That said, a funny thing with adding these is that they’ll trigger “failures” in the future on the specified events (new tags or pushes to master) because this repo itself is not actually trying to deploy anywhere, I’m guessing it’ll fail out with the secrets not being set. I haven’t really looked into whether there’s a way to indicate that these should be ignored without having to name them something funny and force people to rename them during scaffolding/copying.
@timwright12 these changes look good to me, though we may want to add a note to the project scaffold to note that they may want to remove the GitHub Actions if the plugin(s) included in the project aren't intended to be deployed to .org.
