Add Buildkite Release Builds

[jkmassel]

Adds Release Builds with Buildkite

[peril-woocommerce]

	Warnings
⚠️	This PR is assigned to a milestone which is closing in less than 4 days Please, make sure to get it merged by then or assign it to a later expiring milestone

Generated by 🚫 dangerJS

[wpmobilebot]

You can test the changes on this Pull Request by downloading an installable build, or scanning this QR code:

[mokagio]

Looking good so far. Submitting this as a comment before triggering a release build myself 😏

[mokagio]

The docs say:

So, I would have expected this to have to be indented:

Suggested change

	notify:
	- slack: "#build-and-ship"
	notify:
	- slack: "#build-and-ship"

But clearly YAML can handle it. Not only I see the notifications in that Slack channel, but I also see the parsing working fine if I try locally:

➜ ruby -e "require 'yaml';puts YAML.load_file('.buildkite/release-builds.yml')"
{"common_params"=>[["automattic/bash-cache#2.1.0"]], "steps"=>[{"label"=>"🛠 Release Build", "command"=>".buildkite/commands/release-build.sh", "plugins"=>["automattic/bash-cache#2.1.0"], "notify"=>[{"slack"=>"#build-and-ship"}]}]}

Of course, nothing guarantees that Buildkite uses the same parser as I did, but the fact that both work clearly points to the syntax being valid and my mental representation incorrect.

[jkmassel]

This is a good point – it might be worth putting a YAML linter in place sometime down the road. I ran yamllint locally, and it agrees with you, so I've fixed it in b36ba72.

Thanks!!

[mokagio]

This logic is trivial, but seems a good candidate for future extraction in the release toolkit.

[jkmassel]

I was thinking about this – there's no guarantee that every project uses the same nomenclature for denoting beta versions, but that said, the release toolkit is mostly used by a8c. There might be a middle ground of some kind? :)

[AliSoftware]

There are already a lot of assumptions hardcoded in the release-toolkit about this versioning scheme, and in fact, there are also helpers that do that exact check in the release toolkit as well: see this Helper method — which is used for example by this precheck action.

So exposing this as public API of the release-toolkit would definitively make sense. That would probably be a good candidate for when we get the time to address wordpress-mobile/release-toolkit#203… one day…

[mokagio]

The build I triggered from my Mac:

• Was incredibly fast compared to what I'm used to with WordPress 😅
• Failed at the Google Play API level, with the expected APK specifies a version code that has already been used error

I'd say this is good to go.