Setting up CI with Google Cloud Build - Resolves #2

[mrchrisadams]

This PR here introduces the necessary docker containers to run the green check tests in google cloud build CI.

When we push changes on any brancg with changes inside the packages/greencheck directory, we:

• spin up mysql and redis
• spin up an ubuntu instance with the php deps as close to production as I could reasonably set up
• run the phpunit tests
• tear everything down again

I've had to update packages/greencheck/src/Sitecheck/Cache.php to use the redis hostname, as docker really, really likes you to use separate services, and when I tried to run them on the same docker image to simulate our server, it was a total pain to work with its networking.

So, we'll need to set some env variables or something to make the cache.php connect to the correct host, depending on whether we're in development, in CI or in production.

I'm almost certainly using docker wrong, and we can probably end up with smaller docker images to ship around, but at least here we can run tests in a CI server.

[mrchrisadams]

Alright.

We have tests that are run whenever we push a change to the repo for greencheck.

However, I now know why it was a bit of a pain to set up, and its worth making a note of.

Setting this up through the Github Market place

After going through both routes, I have this set up by going through the Google Cloud Build Marketplace listing.

This gives us the nice build bag, so you can see at a glance in a PR the build status.

However, it offers less control than setting up an automated build step through the Google Cloud Platform UI.

We have monorepo style layout for this repo, so by default, we now run the cloudbuild.yaml steps on each change.

This works okay, and we get our fail/pass badge this way for each push. This means that any push to this repo, even if we're working on other bits will trigger the greencheck tests too.

This might be the expected behaviour, but as we bring the rest of of the application under a testing harness, we'll need to bear this in mind.

Going through google's triggers instead

The alternative to going through the Github Marketplace, is going through the Google Cloud UI instead.

We can control the build to only run when we see changes in the greencheck directory, and run different kinds of build depending on what files we change.

I haven't set that up yet, but if we bring the API under CI as well, we'll need to either

• workout how to show build status in a PR, when we've set up a trigger through the google cloud build UI
• or, work out how to edit triggers created by the github Marketplace - right now, any cloud build triggers that are created by github aren't visible in the google UI, so we can't change them.

But apart from that, we have CI!

[arendjantetteroo]

Sweet. i think running both tests makes sense though. At least from an api perspective. In theory the greencheck should not break if you change something in the api, but the other way around is certainly possible.

[mrchrisadams]

@arendjantetteroo I think that now we have CI (I've granted you access to the project on), I'll keep it like that til we get a reply from Google.

As an aside, there's an interesting convo going on here about CI and green power now: https://twitter.com/mrchrisadams/status/1123263070669889536

[mrchrisadams]

@arendjantetteroo Until we have a convention, do you prefer this squash merged in, or rebased?

I have a preference to rebasing, as I've tried to keep the commits atomic and meaningful here, so the history makes sense, but it's not something I'm that dogmatic about, and I could probably tidy them up some more if need be.

[arendjantetteroo]

@mrchrisadams As long as the commits are pretty clean i don't really care if it's a merge, a squash or a rebase, so choose what you want : )

[mrchrisadams]

Thanks for the code review AJ. I've made these changes, and once we're passing green, I'll tidy up the commit history and merge it in 👍