Action: Build process

[helen]

A lot of plugins now build into production-ready versions and are not necessarily executable in their development repo state. The next logical step (or rather, the step that should precede deploying to .org) is to run said build. IMO the built version should be committed to an orphaned stable branch so that a trackable copy of that is also available over time but is not hanging out as a subfolder.

My thought is to do the following for this Action:

• Check out / create stable in another directory (I’ve done this using Git’s worktree functionality but I don’t think it’s actually necessary to do this in the context of an Action)
• Run the build process, perhaps standardizing on npm run build but allowing the command to be customized. For instance, in another plugin I use npm run release when I want to build into another directory and remove all unnecessary files, whereas build builds files into the current directory and those built files are typically .gitignore-d.
• If the build process doesn’t directly build into the stable directory, empty the directory and then copy everything there.
• Commit everything to stable and push.

So then the way this would work in terms of a workflow would be that on pushing a tag to master, the build Action runs and then the Deploy one, which would then need to point to the directory stable is in to deploy from as opposed to the default repository workspace.

[tnorthcutt]

I like this 👏

Would it make sense for this to be two separate GitHub actions? I admittedly am not yet familiar with them, but it sounds like two different things. Plus, that way plugins which don't need a build step could just use the deploy action, but if necessary a plugin could use both.

I also like the idea of having a configurable but standard build command like npm run build.

[XedinUnknown]

IMO there's no need to re-invent the wheel. There is already a standard for where to put built code - it's called "dist", and it is an archive that can be attached to any release. For simply excluding files, you can use .gitattributes and Github will automatically create the dist for you by using git archive. For more complex builds, e.g. ones which include composer install etc, use the free Travis CI/CD service to perform the build steps and then deploy the result to Github - like this. This would mean a single source of truth for the distributable versions of your software.

If the action could then commit the contents of the archive to WP.org SVN, this would be all that's needed, really. Pretty pretty please!

[helen]

@XedinUnknown There's another set of WordPress plugin-focused Actions available if you're looking to make a ZIP archive. That's what's great about open source, somebody else's project goals may more closely match yours.

In this case, the goal is to simplify development workflows and keep everything within GitHub Actions, especially given the recent change of ownership of Travis that has me more than a little concerned about its future. There's also no goal here to produce ZIP archives, those should be served by WordPress.org as the "source of truth" for the installable version of your plugin. GitHub is not end-user friendly or discoverable.

I do think if people want to use a dist folder there's probably a case to be made for that being customizable or perhaps usable distinctly from the build aspect (see #1).

[tnorthcutt]

the recent change of ownership of Travis

[XedinUnknown]

@helen, perhaps I didn't formulate my thoughts correctly enough. What I meant has nothing to do with creating ZIPs, or using Travis: it is incidental that dist versions are distributed as ZIPs, and any other CI/CD service can be used instead of Travis, including git archive already native to Github, or a completely custom shell script on a proprietary DO droplet.

Instead, it has everything to do with the fact that there is already a standard for where distributable versions of the software are stored, and how they are... distributed. It's called dist. This is what Composer will download instead of cloning the repository if you use --prefer-dist. And it is stored as an archive attached to a Github release.

When a WordPress plugin is built, this is a distributable version. This built result should then be attached to a release, and this would enable various already existing tools (such as Composer) to access them, and install them. Since this distributable version already contains the built plugin, i.e. something ready to be installed into a WordPress environment, it only makes sense to deploy that to the WordPress.org SVN repository.

A plugin is first and foremost a package, and only then it is a WordPress plugin. Just like it is first and foremost PHP, and only then is WordPress. Therefore, it makes sense to use industry standards in order to ensure interoperability with existing standards-compliant tools. It will also enable developers to use whatever build process they want, including those already set up with Travis/Codeship/Circle/etc, and ship their plugins in the way they already do, e.g. Composer/WPackagist/Github/Pusher/etc.

WordPress has many crippling legacy rules that go against industry standards, and now need to be revised or are already being revised - and WPCS is an example of that. I would really appreciate it if this new emerging process would not need to complicate things and deliberately go against what already has been established by many more people who have given it much more consideration and testing.

Love <3

[helen]

@XedinUnknown Closing with Love <3 does not offset your condescension and in fact compounds it. Additionally, this is a repository in my work organization.

A plugin is first and foremost a package, and only then it is a WordPress plugin.

I think this makes it pretty clear that there are some fundamental disagreements here along with different goals and approaches.

This issue originated in connection with the Action to deploy to WordPress.org, however as stated I am open to making the case for various build processes (which obviously exist, you do not need to further explain them to me), probably the most important thing to do for those is to enumerate the goal and potential workflow - that is, solve for the problem, not the approach.

[XedinUnknown]

@helen, by closing with "Love <3" I only meant that the point I try to advocate is for the benefit of all. No condescension was implied.

I'm puzzled, however, by your statement about fundamental disagreements, and the differences in goals. But I'm sure these seeming differences will fade as soon as goals are formulated. I am confident that goals are pretty much the same, as we all want to write solid, flexible, robust software, and to do it in the most conceptually correct and simple way possible.

I explained about the different build processes because you seemed to focus your attention on Travis and the fact that it had a change of management, which appeared to be a significant detail used to make the point.

I'm just trying to be constructive. I have had the impression that WordPress aims to be inclusive. Creating procedures which limit developers who want to be flexible and standards-compliant is not very inclusive, IMHO. So, let us be constructive. I feel like I have described my goals here. Are these valid, in your opinion? And what are your goals, and goals of other participants and consumers of this project?

[helen]

Adding some references here from another project:

• A "release" type of action for a plugin that does not deploy to .org - this action copies the files necessary for actual production usage and commits them to an orphaned stable branch, which is where downloadable releases are tagged: https://github.com/10up/classifai/tree/develop/.github/action-release
• Workflow file that does a very basic npm install && npm run build prior to the "release": https://github.com/10up/classifai/blob/develop/.github/main.workflow

I don't yet know if this makes sense to release as a broader usage action, especially because it currently makes some branch structure assumptions. I personally prefer this method to keeping dist and/or built files in dev branches but everybody and every project is different, which would be a good argument for making multiple actions that can publish the build into different places, leaving the actual build commands to be separate steps in the workflow. So for instance, I could see a .org-released plugin being set up with two workflows - one to do build and publish into stable whenever you merge into master (technically whenever you push to master I guess) as seen in the ClassifAI plugin, and then the existing one that releases from a tag (which would be on stable) to .org.