search

Automattic / chatrix

Matrix client for WordPress
https://wordpress.org/plugins/chatrix
GNU General Public License v2.0
41 stars 0 forks source link

CI for chatrix WordPress plugin #19

Closed psrpinto closed 2 years ago

psrpinto commented 2 years ago

The chatrix WordPress plugin needs to be built, so that chatrix's assets are placed inside the plugin directory.

This could be done using GitHub actions, which could produce a chatrix-wordpress-plugin.zip.

The built plugin should also be deployed to makewp.a8cmatrix.com, but I think that should be done through Automattic/matrix-infrastrucutre, either through ansible (manually) or through a GitHub action on that repo.

In the future, the zip could be manually uploaded to wporg.

psrpinto commented 2 years ago

@akirk @ashfame Any thoughts on this? Any other ideas how this could be done?

I would like to not opt for the option of adding the chatrix assets committed into the plugin's directory, if possible.

ashfame commented 2 years ago

Can you describe what you hope to achieve with this task? I like integrating phpcs checks for every PR and we can have a zip archive be built for WordPress in Github actions but that would be sitting in the container so where would that zip file go? I am not sure what you are envisioning after this step.

Perhaps we upload it to makewp.a8cmatrix.com and in that sense, it always reflect main branch of this repo?

Github releases could be an option but I am not sure if its possible to do that programmatically and often with every merge to main branch. Would also require bumping up version with every PR and with multiple PRs it can be tricky. So, best done manually, moreover, releases would be managed more on WP.org plugins repo and not on Github.

psrpinto commented 2 years ago

Happy to provide some more context @ashfame.

The problem we need to solve is that chatrix's built assets (i.e. the ./target/ directory which is the result of running yarn build) are not present in the WordPress plugin's directory (./wordpress/chatrix/).

(The phpcs check on PRs is just a nice to have, and not really related to this issue, I just added it since it's CI-related and can probably be implemented easily through github actions. I removed it from the issue description to prevent confusion, we can tackle it in another ticket.)

What I was envisioning was indeed to use GitHub Actions, along with GitHub Releases. Whenever a new Release would be published (by us manually creating it in GitHub's UI), an Action would run which would create the artifacts for that Release, e.g. chatrix.zip and chatrix-wordpress-plugin.zip. I believe it is possible to achieve this with GitHub Actions.

In this scenario, no new release would be issued when a PR is merged, and I believe that is a good thing. I think we need to be able to decide when a new release is issued since, for example, a feature might be implemented across multiple PRs, and we only want a release to be issued when the feature is done.

Something else to consider is that this repo is not currently public, and the WordPress plugin must not be public either, as it contains hardcoded information for our use case. I'm not familiar with how WordPress.org/plugins works (I've never published a plugin), but this plugin must not (yet) be listed in there.

Concerning makewp.a8cmatrix.com, we can decide to have it pull the main branch whenever a PR is merged, but that should be done through GitHub Actions on the matrix-infrastructure repo, or by just setting a cron on the droplet which periodically pulls main.

ashfame commented 2 years ago

Thanks for explaining! Would adding just a yarn command to generate the zip files locally be a simpler solution?

(The phpcs check on PRs is just a nice to have, and not really related to this issue, I just added it since it's CI-related and can probably be implemented easily through github actions. I removed it from the issue description to prevent confusion, we can tackle it in another ticket.)

Gotcha!

What I was envisioning was indeed to use GitHub Actions, along with GitHub Releases. Whenever a new Release would be published (by us manually creating it in GitHub's UI), an Action would run which would create the artifacts for that Release, e.g. chatrix.zip and chatrix-wordpress-plugin.zip. I believe it is possible to achieve this with GitHub Actions.

Does this cover a need where we would want releases to be available on Github? I currently can't connect the need of doing this over just generating final builds locally.

In this scenario, no new release would be issued when a PR is merged, and I believe that is a good thing. I think we need to be able to decide when a new release is issued since, for example, a feature might be implemented across multiple PRs, and we only want a release to be issued when the feature is done.

Gotcha! I agree.

Something else to consider is that this repo is not currently public, and the WordPress plugin must not be public either, as it contains hardcoded information for our use case. I'm not familiar with how WordPress.org/plugins works (I've never published a plugin), but this plugin must not (yet) be listed in there.

Yep! We would also have to be mindful of rotating anything sensitive that's currently in this repo for the future point of time when we make the repo public. We should create a task to just track this, while everything is fresh in our head, otherwise easier to forget later on :)

Concerning makewp.a8cmatrix.com, we can decide to have it pull the main branch whenever a PR is merged, but that should be done through GitHub Actions on the matrix-infrastructure repo, or by just setting a cron on the droplet which periodically pulls main.

Sure! I see that's not in current scope of this issue as I originally thought.

psrpinto commented 2 years ago

Having a yarn command (or some sort of build script) makes sense. That way a build can both be produced locally, and in a GitHub Action.

Does this cover a need where we would want releases to be available on Github?

I see some advantages to having the release on GitHub, with the built artifacts attached:

  1. Someone who wants to deploy the plugin can just downloaded it, instead of needing to get the environment running locally.
  2. A history of previous versions would be available.

Admittedly not super essential reasons, but implementing this through GitHub actions should be fairly straightforward. Also, once this repo becomes public (which I think we should do at some point), releases will be essential, I think.

ashfame commented 2 years ago

Someone who wants to deploy the plugin can just downloaded it, instead of needing to get the environment running locally.

I am thinking if releases on Github would mirror WP.org plugins repo releases (something Github hosted WordPress plugins tend to do, if they are released on official WP.org plugins repo as well), this would be useful if someone can just get the WordPress plugin for the latest main branch and not just the releases, but we are only talking about releases here, right?

In that case, I think it's just easier to point them to https://downloads.wordpress.org/plugin/%pluginslug%.zip to download the latest version. It's also possible to download previous versions from plugin page on WP.org repo.

Admittedly not super essential reasons, but implementing this through GitHub actions should be fairly straightforward.

Sure! Just wanted to give you a heads up on what's already possible on WP.org plugins repository.

psrpinto commented 2 years ago

but we are only talking about releases here, right?

Correct.

I am thinking if releases on Github would mirror WP.org plugins repo releases (something Github hosted WordPress plugins tend to do, if they are released on official WP.org plugins repo as well)

The way I envision this, and how I imagine those plugins to be working, is that GitHub is the "single source of truth", and releases can be "pushed" to wporg, through some sort of tooling. I think that approach would make sense, specially considering that there are two "assets" in this repo: chatrix itself (which can be used without the wordpress plugin), and the wordpress plugin itself. So a Github release would contain both artifacts, chatrix.zip and chatrix-wordpress-plugin.zip.

Once that's done, if needed, we can figure out the tooling to get the release into wporg.

psrpinto commented 2 years ago

The first release has now been published, through GitHub Actions. Contains artifacts for both chatrix and the WordPress plugin.