Add actions to build PRs and develop, cleanup closed PRs.

[adamsilverstein]

Summary

This PR adds two GitHub Actions to automatically build (and later cleanup) versions of the plugin for testing. These build files can be used to set the version of Site Kit to any PR or develop for testing.

• For each PR that is opened or updated, the build-pr action builds a zip production (google-site-kit.zip) and development(google-site-kit-dev.zip) build version of the plugin.
• The zip files are moved to a folder based on the current GitHub Ref . In the case of pull requests this is refs/pull/[PR#]/merge
• The action also builds when PRs are merged to the develop branch, in this case the ref is refs/heads/develop.
• The zip files/ref folder is committed to the repository's wiki repository.
• These folders create predictable zip URLs to download the correct build for testing.
• When a pull request is closed the remove-pr action runs and the ref folder and zip files are deleted from the wiki repository.

Relevant technical choices

• The build process is cached so only the initial run needs to download npm and composer assets (unless they change)
• The build uses several npm/gulp commands to build the desired plugin zips. These could be combined into a single npm command. My goal in adding them this way is to add these actions without changing the plugin at all.
• For upload locations, I considered several other solutions including committing to a branch, adding PR comments, using releases or releases on a separate repository and using build artifacts. The wiki solution wound up being the best because no extra repository is required, the primary repository is not weighed down by constantly added zip files, and the built files are transparent to end users.

[adamsilverstein]

@felixarntz someone with repo ownership will need to add a personal access token as a repo secret under the key GITHUB_PERSONAL_ACCESS_TOKEN before the wiki deploys can work correctly.

Also I noticed the build failed, possible because of some recent changes in build commands? I'll take a look and get that fixed.

[adamsilverstein]

Fixed the build command, I had to adjust for the newer grunt build command which creates a unique zip filename when building.

Once the GITHUB_PERSONAL_ACCESS_TOKEN is added to site secrets, the built files will get added to the wiki repo.

[felixarntz]

Awesome work! Looking forward to seeing this in action.

I'll merge after we're done with the current release.

[felixarntz]

Not really scope of this PR, but the scripts in package.json are a bit inconsistent between how they work for production vs development. E.g. build:dev includes a call to build:static while build:production and build:test don't.

I'll open a small separate issue with this.

[aaemnnosttv]

This is great @adamsilverstein - I left a few comments, questions and suggestions for you but nothing blocking. Mostly that the code is a bit unclear in some places as to why something is done a certain way which could benefit from clarification via comments and/or better variable names.

I actually created a Docker container recently for running the plugin build in a reproducible way. I'm not sure if that could be used here (it only supports a production build and a specific branch but also supports using a local repo) but might be useful to see if anything can be borrowed there. https://github.com/aaemnnosttv/gskbuild

[adamsilverstein]

@aaemnnosttv Thanks for the review, I'll work on addressing your feedback

I actually created a Docker container recently for running the plugin build in a reproducible way. I'm not sure if that could be used here (it only supports a production build and a specific branch but also supports using a local repo) but might be useful to see if anything can be borrowed there. aaemnnosttv/gskbuild

Very cool! I have a separate tester plugin I am working on to leverage these zip builds, more on that soon!

[adamsilverstein]

@aaemnnosttv This is ready for re-review, I have addressed your feedback and cleaned things up a bit. Thanks especially for the bash script improvements.

We added the required secret and ZIPs are building now (for this pr only so far), you can clone the wiki repo to see them: git clone https://github.com/google/site-kit-wp.wiki.git

[adamsilverstein]

Thanks!

[googlebot]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[aaemnnosttv]

@googlebot I consent.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[aaemnnosttv]

@adamsilverstein I've made a few updates to the workflow to simplify things a bit which I think you will like!

• Completely defined in workflow files, no need for external bash scripts
• Using actions/checkout there is no need for an additional access token as an auth token is persisted in the repos local git config by default
• I split zip/build and deploy tasks into separate jobs to avoid potential conflicts with the working directory between repos using artifacts upload+download
• Using artifacts makes the zips available for download from the Actions backend for each run which are available for 90 days
  
• I set the git config name and email with environment variables instead of git commands which makes that portion of the script a bit cleaner and focused I think
  Should instead be something static and generic like googlebot rather than the GitHub actor since its done via automation?

Let me know what you think or if there's anything I might have missed.

[aaemnnosttv]

Requesting @tofumatt's eyes here since he is quite familiar with Actions as well 👍

[adamsilverstein]

@aaemnnosttv Thanks for the refactoring here!

I split zip/build and deploy tasks into separate jobs to avoid potential conflicts with the working directory between repos using artifacts upload+download

Nice.

Using artifacts makes the zips available for download from the Actions backend for each run which are available for 90 days

Did you figure out a way to determine or specify an artifact's URL via API or after creation? If we knew this we could use build artifacts instead of the wiki.

Completely defined in workflow files, no need for external bash scripts

Excellent, that is much cleaner and easier to understand as well!

there is no need for an additional access token

Great! I'll remove my token.

Should instead be something static and generic like googlebot rather than the GitHub actor since its done via automation?

the github actor feels clear enough to me.

[aaemnnosttv]

Did you figure out a way to determine or specify an artifact's URL via API or after creation? If we knew this we could use build artifacts instead of the wiki.

I thought about that but the fact that they expire is a bit of a dealbreaker - also, they're specific to the individual action run, so I don't think that there is an easy way to grab the latest like we are doing with the URL to the wiki. Also, build artifacts are put into a directory even if you upload an individual file - the artifact comes down as a zipped directory. That is, you wouldn't be able to link to an artifact of the installable zip, unless you used upload-artifact to target the unzipped release zip (does that make sense?). Because of this, both zips are archived together inside the destination directory, and then restored back into it 🙂

[tofumatt]

Seems good to me—I have a question about zips built from develop, but otherwise this seems great and puts us on the way to having automated releases… and eventually even automatic deploys to WP's plugin repo! 🎉

[tofumatt]

If we build the PR on any tags/and on master it would save us (usually @felixarntz) having to build the production ZIP by hand on a Mac. Having the CI generate our builds instead of us doing it manually is way nicer, so I filed #1196 to chat about that and extend this later 😄

[aaemnnosttv]

Good call!

[tofumatt]

That's a nice touch. I usually just specify the node version in the action, but I like that! 👍

[tofumatt]

This runs on pushes to develop, but doesn't remove the file. Will the upload overwrite this one based on the ref being the branch name (develop) over the commit hash?

If so that seems fine, but just wanna make sure this isn't going to spawn a lot of ZIP files 😅

[aaemnnosttv]

The generated zip files are renamed as google-site-kit.zip and google-site-kit-dev.zip so yes 😄

[adamsilverstein]

note: the github.ref in this case is refs/heads/develop (so that is where the zips wind up being stored)

[adamsilverstein]

Love how this works!

[adamsilverstein]

Excellent updates @aaemnnosttv - thank you! +1

[aaemnnosttv]

LGTM 👍

[felixarntz]

Awesome work @adamsilverstein and @aaemnnosttv!