Implement GitHub Action build workflows

[kadamwhite]

This theme currently contains prebuilt assets: to use it on a deployed WordPress site, if any CSS has been changed then the npm run compile command must also be run, and the updated compiled CSS assets must be manually committed to the repository.

We generally recommend against committing compiled assets to a source code repository because if two different features end up writing changes to the same bundled file, that can cause an unnecessary merge conflict that slows down development. A theme doesn't work without its static assets, though, so the build process needs to happen somewhere.

In the Shiro theme, we use GitHub Actions to build the theme's assets.

• The main branch contains only source code files, and does not include compiled assets
  • When any PR is merged to main, an Action automatically builds assets and pushes them to release
• The develop branch likewise contains only source code files, and does not include compiled assets
  • When any branch is merged to develop for testing, a separate action builds that source code into the release-develop branch

Web applications can then install Shiro using a dev-release VCS composer reference, decoupling

This issue tracks implementing the same process for this Interconnection theme.

Proposed tactics

• Copy .github folder from Shiro theme
• Check the node-version of the release scripts and make sure it matches this project's .nvmrc
• Check the built_asset_paths of the release actions and make sure they include the right generated directories and files
• Check the build_script of the release actions and make sure they include the right npm command
• Remove the generated files from source control on main (git rm ...), test, and iterate until pushes to main build correctly (see status here in the Actions tab)

Probably easiest to work directly in main until things are set up properly, rather than PR'ing every single change. This repository is not yet used in a production environment so changes here will not break anything, and there are not yet any branch protection rules set up to prevent pushes directly to main.

If it's easier to include the PHP and JS linting when migrating the other GH actions over, let's bring them along, but we do expect they will fail at first since I believe this repo uses slightly different coding standards.

Acceptance Criteria

• [x] When main is updated, a GitHub Action builds that branch to release
• [x] When develop is updated, a GitHub Action builds that branch to release-develop
• [x] The contents of the release or release-develop branches can be downloaded as a zip and used as-is on a WordPress site with no further build necessary

[pamprn09]

@kadamwhite all those items are done. Do we have a ticket for this one? How can we mark this as done once is reviewed and approved?

[kadamwhite]

Note that this is done on issue 633 in the other repo, and then we can close out this ticket. Thanks!