HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK to avoid unrelated failures
#29080
Homebrew attempts to check for outdated dependents or those with broken linkage. Such behavior might lead to failures when Homebrew updates them on old macOS images. For example, https://github.com/bitcoin/bitcoin/actions/runs/7199058794/job/19609891263 using the macOS image version 20231025.2.
This PR prevents such behavior.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | maflcko, ismaelsadeeq |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Homebrew attempts to check for outdated dependents or those with broken
linkage. Such behavior might lead to failures when Homebrew updates them
on old macOS images.
This change prevents such behavior.
HOMEBREW_NO_AUTO_UPDATE has been replaced with HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK, which does fix the issue. See https://github.com/bitcoin/bitcoin/actions/runs/7208749840/job/19638344437.
when Homebrew updates them on old macOS images.
Do we use old images?
What other side-effects could this cause due to not updating dependencies, and broken linage/other issues?
when Homebrew updates them on old macOS images.
Do we use old images?
The images are from GHA/Microsoft.
What other side-effects could this cause due to not updating dependencies, and broken linage/other issues?
This also speeds up the build by 5 Minutes.
Do we use old images?
The GHA chooses an image from a set of available images when setting up a new job.
It is not rare case when more than one images are available simultaneously. One of them is older than others.
It is not rare case when more than one images are available simultaneously. One of them is older than others.
What does “older” mean here? Aren’t we pinned to a specific version to avoid exactly this issue?
It is not rare case when more than one images are available simultaneously. One of them is older than others.
What does “older” mean here? Aren’t we pinned to a specific version to avoid exactly this issue?
For example,
0##[group]Operating System
1macOS
213.6
322G120
4##[endgroup]
5##[group]Runner Image
6Image: macos-13
7Version: 20231025.2
8Included Software: https://github.com/actions/runner-images/blob/macos-13/20231025.2/images/macos/macos-13-Readme.md
9Image Release: https://github.com/actions/runner-images/releases/tag/macos-13%2F20231025.2
10##[endgroup]
vs
0##[group]Operating System
1macOS
213.6.1
322G313
4##[endgroup]
5##[group]Runner Image
6Image: macos-13
7Version: 20231204.4
8Included Software: https://github.com/actions/runner-images/blob/macos-13/20231204.4/images/macos/macos-13-Readme.md
9Image Release: https://github.com/actions/runner-images/releases/tag/macos-13%2F20231204.4
10##[endgroup]
We pin only macos-13.
For example,. Image Release: https://github.com/actions/runner-images/releases/tag/macos-13%2F20231025.2 vs Image Release: https://github.com/actions/runner-images/releases/tag/macos-13%2F20231204.4
I still don’t really understand this fix, and assume it could lead to obscure breakage in the future, i.e a missing dep, or a dep trying to use an outdated sub dep. (it also just makes our CI further differ from nomal macOS / dev setups).
I don’t really understand how a new image being released, causes failures with the previous image, especially when, the image you’re linking to above (20231204), was never even released? See: https://github.com/actions/runner-images/pull/8960
The release was cancelled, the badge was updated incorrectly - we are working to update the status and eliminate the causes of this “event” itself.
It also doesn’t appear in https://github.com/actions/runner-images/tree/main/images/macos, so I don’t understand how anything could be using this image, or how it’s causing failures.
… so I don’t understand how anything could be using this image, or how it’s causing failures.
This PR does nothing about new 20231204 release, because the failure was caused by the older 20231025 one.
I think that the GHA image release process issues are irrelevant to this PR change.
I still don’t really understand this fix, and assume it could lead to obscure breakage in the future, i.e a missing dep, or a dep trying to use an outdated sub dep. (it also just makes our CI further differ from nomal macOS / dev setups).
Our dependencies are installed explicitly. ~We do not use any of other tools preinstalled via Homebrew. Why should we care about their dependencies?~
I still don’t really understand this fix
This fix makes Homebrew skip upgrading the aws-sam-cli package that we do not use.
We do not use any of other tools preinstalled via Homebrew.
Don’t we use at least git, curl and Python? If any those are probably less-prone to breakage.
Don’t we use at least git, curl and Python?
Right. Here is the brew list -1 command output for the image version 20231025.2:
0ant
1aom
2apr
3apr-util
4argon2
5aria2
6aspell
7autoconf
8aws-sam-cli
9azure-cli
10bazelisk
11berkeley-db
12bicep
13brotli
14c-ares
15ca-certificates
16cairo
17carthage
18cffi
19cmake
20composer
21curl
22fontconfig
23freetds
24freetype
25gcc
26gcc@11
27gcc@12
28gd
29gdbm
30geckodriver
31gettext
32gh
33giflib
34git
35git-lfs
36glib
37gmp
38gnu-tar
39gnupg
40gnutls
41gradle
42graphite2
43harfbuzz
44highway
45httpd
46icu4c
47imath
48isl
49jpeg-turbo
50jpeg-xl
51jq
52kotlin
53krb5
54libassuan
55libavif
56libevent
57libgcrypt
58libgpg-error
59libidn2
60libksba
61libmpc
62libnghttp2
63libpng
64libpq
65libsodium
66libssh2
67libtasn1
68libtiff
69libtool
70libunistring
71libusb
72libuv
73libvmaf
74libx11
75libxau
76libxcb
77libxdmcp
78libxext
79libxrender
80libyaml
81libzip
82little-cms2
83llvm@15
84lz4
85lzo
86m4
87maven
88mpdecimal
89mpfr
90nettle
91node@18
92npth
93oniguruma
94openblas
95openexr
96openjdk
97openldap
98openssl@1.1
99openssl@3
100p11-kit
101p7zip
102packer
103pcre2
104perl
105php
106pinentry
107pipx
108pixman
109pkg-config
110pycparser
111pygments
112python-argcomplete
113python-certifi
114python-cryptography
115python-packaging
116python-pytz
117python-setuptools
118python-typing-extensions
119python@3.10
120python@3.11
121python@3.12
122pyyaml
123r
124readline
125rtmpdump
126ruby@3.0
127rustup-init
128selenium-server
129six
130sqlite
131swiftformat
132swiftlint
133tcl-tk
134tidy-html5
135unbound
136unixodbc
137unxip
138webp
139wget
140xorgproto
141xz
142yq
143zstd
144firefox
145google-chrome
146julia
147microsoft-edge
148session-manager-plugin
As CI does not suffer from unrelated failures now, there is time to investigate underlying issue more thoroughly and suggest a more robust alternative solution.
aws-sam-cli as the first step. Which should solve the problem, have no other side-effects, and retain the speedup, given it’s related to upgrading it’s deps.
Fetching dependencies for aws-sam-cli: python-setuptools, python-attrs, python-dateutil, python-networkx, python-pbr, python-mpmath, python-sympy, python-urllib3, ca-certificates, cfn-lint, pygments, python-click, python-markupsafe, python-jinja, python-certifi, python-charset-normalizer, python-idna, python-requests, cookiecutter and python-cryptography) of something being upgraded (aws-sam-cli), also being upgraded, if (aws-sam-cli) is no-longer installed / being upgraded, I wouldn’t think it’s dependencies should be either?
This fix makes Homebrew skip upgrading the aws-sam-cli package that we do not use.
Ok the issue here also isn’t specifically related to aws-sam-cli, because upgrading any Python will fail, due to symlinks not being able to be written.
Looks like ultimately, we can’t avoid the failure by removing packages we don’t use.
The root cause, is that qt@5 has a dependency on python@3.11, and after we install qt@5, brew will try and upgrade python@3.11, which will then fails:
0==> Upgrading python@3.11
1 3.11.6 -> 3.11.6_1
2
3==> Pouring python@3.11--3.11.6_1.ventura.bottle.tar.gz
4Error: The `brew link` step did not complete successfully
5The formula built, but is not symlinked into /usr/local
6Could not symlink bin/2to3
7Target /usr/local/bin/2to3
8already exists. You may want to remove it:
9 rm '/usr/local/bin/2to3'
10To force the link and overwrite all conflicting files:
11 brew link --overwrite python@3.11
12To list all files that would be deleted:
13 brew link --overwrite --dry-run python@3.11
14Possible conflicting files are:
15/usr/local/bin/2to3 -> /Library/Frameworks/Python.framework/Versions/3.12/bin/2to3
16/usr/local/bin/2to3-3.11 -> /Library/Frameworks/Python.framework/Versions/3.11/bin/2to3-3.11
17/usr/local/bin/idle3 -> /Library/Frameworks/Python.framework/Versions/3.12/bin/idle3
18/usr/local/bin/idle3.11 -> /Library/Frameworks/Python.framework/Versions/3.11/bin/idle3.11
19/usr/local/bin/pydoc3 -> /Library/Frameworks/Python.framework/Versions/3.12/bin/pydoc3
20/usr/local/bin/pydoc3.11 -> /Library/Frameworks/Python.framework/Versions/3.11/bin/pydoc3.11
21/usr/local/bin/python3 -> /Library/Frameworks/Python.framework/Versions/3.12/bin/python3
22/usr/local/bin/python3-config -> /Library/Frameworks/Python.framework/Versions/3.12/bin/python3-config
23/usr/local/bin/python3.11 -> /Library/Frameworks/Python.framework/Versions/3.11/bin/python3.11
24/usr/local/bin/python3.11-config -> /Library/Frameworks/Python.framework/Versions/3.11/bin/python3.11-config