New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Homebrew 1.0.0 fallout #483
Commits on Sep 24, 2016
-
Add homebrew_analytics module for robust disabling
Originally, a raw call to the `git.config` state was used to disable Homebrew Analytics. However, this is fragile and recently broke with the Homebrew 1.0.0 release, which migrated the Homebrew repository location. Now that we have support for custom modules, add a `homebrew` execution module to allow running arbitrary Homebrew commands, and a `homebrew_analytics` module on top which allows robustly disabling Homebrew Analytics by using the builtin `brew analytics` command. The execution module is named `homebrew` because the built-in module [`mac_brew.py`] is not available (hidden behind the `pkg` __virtualname__), so its methods cannot be called.
aneeshusa committedSep 24, 2016 -
Be robust to upstream changes when building old revs
When running builds that are not from scratch, it is possible that upstream changes have caused old revisions on master to stop building. Because homu maintains the invariant that each merge to master is passing, and we are only building the old revision to create a baseline to test the new revision, it's safe to ignore failures in the old rev.
aneeshusa committedSep 24, 2016
Commits on Sep 26, 2016
-
Installing git via Homebrew now requires XCode 8. Additionally, this configures an OS X 10.11 image on Travis, which matches what we have deployment in production (the default is an OS X 10.9.5 image on Travis). With OS X 10.11, the previous launchctl.py module that we had backported has been superseded by a new mac_service.py module in 2016.3.0. Hence, backport the new mac_service.py module as well. saltfs-migration: Ensure that our OS X builders are all running OS X 10.11 and have XCode 8 installed.
aneeshusa committedSep 26, 2016 -
Invalidate Salt cache in-between runs
For some reason it seems Salt is not invalidating the `_modules` cache, causing build failures on upgrade builds (i.e. the second build on a not-from-scratch run). Invalidate the cache manually. Note that `nullglob` is set for safety, but we always expect `rm` to find cache files to invalidate. In case it does not find any files, the glob will expand to nothing, which is considered an error, causing failure via `errexit`. That is, not ignoring the result of rm is intentional. (`nullglob` is nicer than `failglob` because it is friendlier to loops over globs.)
aneeshusa committedSep 26, 2016 -
Homebrew recently changed their packaging of Salt and Python, using a virtualenvs for Salt. Because we were pinning an old version of Salt, but not the rest of Homebrew, this caused problems where pip was not being resolved properly. Update Salt to the latest version to fix this. As part of the update, also update some states to avoid deprecated parameters in favor of newer ones: - archive.extracted: archive_user -> user, group - cmd.run: user, group -> runas Note that due to saltstack/salt#36552, `archive.extracted` states still have the archive_user argument to ensure parent directories are made with the correct permissions. saltfs-migration: Upgrade Salt on all machines. Steps: - Stop all salt-master and salt-minion services. Because we're upgrading Salt by two major versions at once, there are no guarantees that the masters and minions with different versions will be able to communicate. - Use the install script to re-install Salt on each machine, the master first then the minion. - Restart the salt-master and salt-minion services; pay attention to the system logs in case of startup failure. - Do NOT run a highstate until all minions and masters have been updated to Salt 2016.3.0.
aneeshusa committedSep 26, 2016 -
Use existing config files when reinstalling Salt
The install_salt script may be called again to reinstall or update Salt. Because we are Salting our configuration files, force apt-get to use any existing configuration files and ignore updates in the Salt packages.
aneeshusa committedSep 26, 2016 -
Don't link Homebrew OpenSSL, use env vars
OpenSSL is a "keg-only crate", which Homebrew 1.0.0 won't link because ``` we may end up linking against the insecure, deprecated system OpenSSL while using the headers from Homebrew's openssl. ``` Instead, use the `OPENSSL_INCLUDE_DIR` and `OPENSSL_LIB_DIR` to explicitly pass the paths to the Homebrew OpenSSL. Note that these paths are currently hardcoded because they are unlikely to change. For some reason, Homebrew was reporting this error on its stderr but Salt was not picking it up as and failing the state - possibly because the exit status seems to have been 0. saltfs-migration: Run `brew unlink --dry-run openssl` on the Mac builders, then `brew unlink openssl` once confirming the output is as expected. This will unlink openssl on the existing builders.
aneeshusa committedSep 26, 2016 -
Unlink existing Salt in Homebrew before installing
If a different version of Salt is already installed via Homebrew, it will not allow installing a different version without previously unlinking the old one. Ideally there would be an atomic operation to do both of these in one command, but it appears Homebrew does not have one. Thus, users of this script should be careful to watch the output in case the script is interrupted and no Salt installation is left linked.
aneeshusa committedSep 26, 2016 -
Fix autoconf/autoconf213 installation via Homebrew
Use an idempotent cmd.run to tap `homebrew/versions` only if necessary. Homebrew 1.0.0 apparently tightened its return codes and will exit with a non-zero status if linking fails during installation; there is no way to install without linking or install and link --overwrite in one operation. This makes it difficult to install multiple versions that have conflicting links from the CLI, so add a custom script to handle ensuring that autoconf and autoconf213 are installed and linked properly, with autoconf's links over autoconf213's links, in an idempotent way and doing as little as possible.