Generate a built plugin for PRs, develop, and master branch

[pierlon]

Feature description

It would be nice if we could have a generated build for the develop and master branches, along with PRs. That would allow for easier testing of changes, and should enhance the QA process.

[schlessera]

As a side effect of #4761, I'm already building a release ZIP for each PR and commit.

Once that PR is merged, you'll have access to these artifacts for 90 days per commit.

I'm also looking into surfacing it via an updating comment on the corresponding PR right now.

[schlessera]

For the develop and master branches, where could we best surface the links? Just post them to #amp-plugin-git on Slack?

[pierlon]

The GitHub actions I've been working on stores the built plugin as an artifact and also in the repository's wiki, which Site Kit also does, for example.

That allows us to craft a URL to the plugin build with only the branch name or PR number given, and requires no call to the GitHub API. That cannot be said for the build artifact for the Action workflow, however. Multiple API calls will be needed, and with the request limit being 60 per minute, I don't see that as a viable option.

Storing the plugin build in the wiki would be an enhancement to your Action workflow, I suppose.

[schlessera]

Sounds good.

I don't know what state your workflow is in. Should we consolidate what we both have worked on right away, or should I just have my current version merged and you'll adapt as needed?

[pierlon]

The latter sounds like a better option. The only thing I see missing from yours is generating a production build of the plugin and deploying the built zips to the wiki. I can add both of those things if you create a separate PR with your action.

[schlessera]

My PR is all but ready, it just requires a token to be added as a secret (I don't have access to the repo settings).

I guess it can be merged pretty quickly, so no need for a separate PR, unless @westonruter sees a major issue with the approach.

[schlessera]

Hmm, given that the test site is not properly populated, a separate PR is probably better anyway. I'll split them up.

[westonruter]

Storing the plugin build in the wiki would be an enhancement to your Action workflow, I suppose.

This still makes me feel somewhat uncomfortable, storing ZIPs in the wiki. That just feels like abuse or at least a hack.

As an alternative to this, could we create a special “Pre-release” release where the ZIPs are uploaded to as assets? This would give them predictable filenames, for example if the tag is branches then the URL for a update/foo branch could perhaps be https://github.com/ampproject/amp-wp/releases/download/branches/update-foo.zip.

Granted, this is not ideal either because the release tag would be irrelevant.

Actually, if we're just jumping over hoops to find a place to store these ZIP files, why not just upload them to amp-wp.org? Or otherwise they could be uploaded to Google Cloud Storage?

[westonruter]

In other words, Git is not really meant for storing binary files. The size of the Wiki repo is just going to balloon as more and more ZIP objects are added to its history, each new push to a PR resulting in a Wiki commit adding another 1+ megabytes to the repo size.

[amedina]

I agree. I also feel the wiki path is hacky.

[pierlon]

It is a bit of a hack indeed. For Site Kit, they've automated removing the assets stored in the wiki once the PR has closed.

Actually, if we're just jumping over hoops to find a place to store these ZIP files, why not just upload them to amp-wp.org? Or otherwise they could be uploaded to Google Cloud Storage?

That sounds like a much better solution. If it is possible it would be more than welcome.