PHPLIB-606: Move CI checks from travis-ci to GitHub Actions

[alcaeus]

PHPLIB-606

Creating this PR against the current stable branch so we can take advantage of these checks already (evergreen currently only tests the master branch).

The change in DocumentationExamplesTest.php were necessary as drivers-evergreen-tools starts a sharded cluster backed by a single-member replica set. I'll take a look at either changing the orchestration file to start a three-member replica set or alternatively add support for defining a custom orchestration file.

[jmikola]

Are there any concerns with depending on third-party repositories for action recipes? I imagine if this was taken down our CI builds would break (among many others). Might there be security concerns we were using encrypted environment variables (e.g. Atlas testing) and an action dependency was compromised?

AFAIK, secrets are only tested with Evergreen so this may be a hypothetical question.

[alcaeus]

Are there any concerns with depending on third-party repositories for action recipes? I imagine if this was taken down our CI builds would break (among many others).

Yes, our CI builds would break in that case, but I'd expect a fork to spring up relatively soon considering how widely used these actions are.

Might there be security concerns we were using encrypted environment variables (e.g. Atlas testing) and an action dependency was compromised?

Good question, I haven't considered yet. Quoting from the secrets documentation:

To make a secret available to an action, you must set the secret as an input or environment variable in the workflow file. [...] You can use and read encrypted secrets in a workflow file if you have access to edit the file.

Reading this, any secrets defined in our org or repo would have to be passed on to third-party actions as input or environment variables (either using with or env keys). I'd assume that a compromised third-party action file would not gain access to secrets defined in our repository, but I concede I haven't tested this (yet).

That said, I haven't configured any secrets yet, so we're not running any AWS tests or anything. We can decide to do this at a later date, or we can leave testing with secrets to our evergreen pipeline.

[jmikola]

That said, I haven't configured any secrets yet, so we're not running any AWS tests or anything. We can decide to do this at a later date, or we can leave testing with secrets to our evergreen pipeline.

I'd say nothing to do here, but something to keep in mind if you have grander plans for moving drivers onto GitHub Actions down the line. Maybe you want to add a line about this in your scope doc, but I reckon it's potentially future work since you were only focused on a subset of tests for quick PR feedback.

[alcaeus]

Will do to make sure other engineers are aware, although I want this to be a subset for quick PR feedback in all drivers for the time being.

[alcaeus]

One more note: I haven't explored how we can test against upcoming driver versions (which requires compiling the extension ourselves rather than installing it via the setup-php action). This will most likely become relevant at some point in the future when we start working on features that require bumping to a development driver version.

[jmikola]

One more note: I haven't explored how we can test against upcoming driver versions (which requires compiling the extension ourselves rather than installing it via the setup-php action).

Would something like .travis/install-extension.sh not port over nicely to GitHub Actions? I think it's reasonable to make that follow-up work, although it shouldn't be urgent since such upcoming features would likely be developed internally and our PRs would be able to target Evergreen. Perhaps it'd be problematic if that meant GH Action builds would perpetually fail, though?

[alcaeus]

Would something like .travis/install-extension.sh not port over nicely to GitHub Actions?

Potentially - although I don't want to use this all the time as the cache layer speeds up builds when the selected PHP version has already been installed.

I think it's reasonable to make that follow-up work [...] Perhaps it'd be problematic if that meant GH Action builds would perpetually fail, though?

That's correct: it's follow-up work, but once we get PHPC-1684 done this will be required to keep the build stable. Either way, nothing to worry about for the time being.