[CI] Install the latest version of packages in the brewfile

[Saad Najmi (Saadnajmi)]

Please select one of the following

• I am removing an existing difference between facebook/react-native and microsoft/react-native-macos 👍
• I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos 👍
• I am making a fix / change for the macOS implementation of react-native
• I am making a change required for Microsoft usage of react-native

Summary:

I noticed that the CI as written would:

1. Run brew bundle, and attempt to install the packages in .ado/brewfile
2. Notice that there was a new version available, and try to upgrade in place
3. Update the lock file in the CI job and continue on.

There's no point updating a lock file during a CI run, its point is to lock files. Furthermore, we don't actually care about the versions of the packages installed in our CI's brew file (in this case, just xcbeautify. Really, it's just a shorthand for brew install x; brew install y; ... which would have installed the latest version anyway. Let's just always install the latest version of things and ditch the lock file altogether.

Changelog:

[INTERNAL] [CHANGED] - Install the latest version of packages in the brewfile in CI

Test Plan:

CI should pass.

[Alicia Drummond (FalseLobster)]

Weirdly, it looks like the primary purpose of brewfile.lock.json isn't to lock specific versions, but rather serve as a debugging utility to evaluate how environment changes might break homebrew. I think it it's only read on failures or useful for doing a diff or something to facilitate error reporting. So we should probably have this in our azure artifacts as part of CI for brew bundle failures and I'm not sure it even makes sense in git. Although tbh, I'm not opposed to removing it from CI either, but I just wanted to share with you the reading I had already done:

See the docs here and discussion here.

[Tommy Nguyen (tido64)]

Not checking in Brewfile.lock.json sounds fine to me. We should probably keep the generation of it in case we need to debug.

[Saad Najmi (Saadnajmi)]

Alicia Drummond (@FalseLobster)Tommy Nguyen (@tido64) Interesting, thanks for the insight! I updated the PR to still generate the lock file, and also print it out during CI. This PR was inspired by seeing a one-off segmentation fault during one brew bundle step in an earlier job, so I see the point in adding more debug information.