Add M1 pipeline on Buildkite

[igor-makarov]

Following discussions in #669, @dcvz has volunteered a Buildkite agent running on an M1 Mac.

This PR adds the pipeline that runs tests on it (currently failing because of Typhoeus).

Things to figure out before merge:

• @dcvz - as the owner of the machine, make sure the pipeline is configured in a clean way that doesn't interfere with the other uses for the machine. The gems are installed into vendor/bundle to minimize interference.
• @dnkoutso are we fine with merging a PR that has failing builds, assuming there's another PR that's going to address it?
• I've emailed Buildkite support to enable the open source plan that their pricing page touts. Should we wait for that before merging?

[dcvz]

Looks good from my end @igor-makarov! Since this adds support for testing on the M1, is there any reason to not introduce these changes in the branch that aims to make this repo support M1?

It might make more sense than merging this into master and expecting that most branches will fail for now.. if its introduced along with #669 then this would get merged and from there on you would expect PR's to be green for M1.

[igor-makarov]

@dcvz The idea behind it is having small, granular PRs and separating concerns between them.

#669 is motivated by Apple Silicon - but isn't directly scoped to it, as the HTTP2 client replacement happens for all architectures.

Additionally, having the pipeline fail on M1 right now provides us with more certainty that #669 actually resolves the problem.

[endocrimes]

I'm not sure of the default settings, but we might want to make sure that these builds won't run on forked PRs. Buildkite's security model (mixed with us running these directly on the host), means we can't safely allow 3rd party jobs to run without at least some manual verification.

The issues mostly being:

• Buildkite exposing long lived access tokens to the job fairly trivially (mostly ok because we don't put any secrets in BK)
• Unconstrained execution on the host means that someone being malicious can run any arbitrary software, including taking over access to the mini

[dcvz]

@endocrimes thanks for the input! the BK settings are already not building 3rd party forks (recommended already by BK). I also found this issue on BuildKite for a feature to support this need, but no activity there 😢

@igor-makarov does this repo make use of a bot?

Apart from manually triggering builds for 3rd party PR's, one way would be to ask a bot via a comment from an org member to trigger a CI run on a particular fork. This would allow a maintainer to only trigger a build after review, where no malicious code has been detected.

although perhaps that's overkill for just getting an M1 testing environment... :(

EDIT:
I've also disabled local hooks & plugins on the agent. This should mean that the only scripts executed are those described in the .buildkite/pipeline.yml

[igor-makarov]

@dcvz There's no bot running on the M1 - I think the bot credentials are a secret kept in GH Actions only.
@endocrimes I've also checked that the M1 pipeline doesn't run on forked PRs. Frankly, I'd rather get our M1 testing from GH but they aren't providing a timeline for when they're gonna make it available.
Judging by their disappointing rollout of macOS 11, I'm not holding my breath.

[igor-makarov]

@dcvz @endocrimes I've tried running an M1 pipeline manually on a PR commit and it ran. I think in most PRs we won't need it and if we do, we'll be able to invoke it (albeit in a complicated way).

[igor-makarov]

@endocrimes @dcvz @jasl I ended up disabling M1 runs for now as they keep running on all PRs (and failing). We should enable it once #669 is merged as @dcvz suggested.

[igor-makarov]

Update: Buildkite have approved our free account.