ci: Perform brew update before checkout

[akash1810]

What does this change?

The builds in #84 and #88 are failing with messages that suggest a git conflict:

Error: guardian/devtools/ssm: /usr/local/Homebrew/Library/Taps/guardian/homebrew-devtools/Formula/ssm.rb:4: syntax error, unexpected <<, expecting end
<<<<<<< HEAD
^~
/usr/local/Homebrew/Library/Taps/guardian/homebrew-devtools/Formula/ssm.rb:8: syntax error, unexpected ===, expecting end
=======
^~~
/usr/local/Homebrew/Library/Taps/guardian/homebrew-devtools/Formula/ssm.rb:12: syntax error, unexpected >>, expecting end
>>>>>>> c7fbe61 (Merge dac26abe...
^~
/usr/local/Homebrew/Library/Taps/guardian/homebrew-devtools/Formula/ssm.rb:12: syntax error, unexpected tIDENTIFIER, expecting ')'
...ec66d58337ac276f718186ac0c8a059)
...^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Indeed, this is confirmed via #92, which demonstrates that somewhere in the build homebrew is making changes to the checked out code in a way that causes git conflicts. This results in the above error message being witnessed when we attempt to install from the checked out code.

In this change, we split the CI steps up, changing the ordering.

Before

1. Checkout branch
2. Apply AWS CLI work-around
3. Update homebrew
4. Install from local file system

After

1. Apply AWS CLI work-around
2. Update homebrew
3. Checkout branch
4. Install from local file system

This should guarantee that homebrew does not mutate the checked out branch, and therefore make the build more deterministic, and stable.

How to test

Observe CI; it should pass.

How can we measure success?

The PRs #84 and #88 are unblocked.

[shtukas]

Amazing. Thank you!

[jonathonherbert]

Bit concerned that #84 was not failing when rebased from this branch, despite having an incorrect hash. The logs seem to indicate that it's pulling an older version of ssm-scala – the branch specifies 2.4.0, but in the CI output, we get:!

==> Fetching guardian/devtools/ssm
==> Downloading https://github.com/guardian/ssm-scala/releases/download/v2.3.0/ssm.tar.gz
==> Downloading from https://objects.githubusercontent.com/github-production-release-asset-2e65be/117272170/d3bf2580-9df5-11eb-8610-956d5a221677?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230404%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230404T081223Z&X-Amz-Expires=300&X-Amz-Signature=16c0300f073d3760a38070e2e66399c54b31973e5621c0057f0dd94ca5b96612&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=117272170&response-content-disposition=attachment%3B%20filename%3Dssm.tar.gz&response-content-type=application%2Foctet-stream
==> Installing guardian/devtools/ssm
🍺  /usr/local/Cellar/ssm/2.3.0: 3 files, 27.8MB, built in 7 seconds

Are we definitely testing what we think we're testing with this order of ops? Hold up, I think this is me misreading GH's interface and a rebase hasn't yet occurred, I'm rebasing myself to verify that the behaviour is as expected.

[shtukas]

Are we definitely testing what we think we're testing with this order of ops?

@jonathonherbert
The fetch only get the latest available version (not the version that is being released), which when the CI runs was 2.3.0.

[jonathonherbert]

Yep, my mistake, manually rebased and looks great! 🎉