Pulls 'brew linkage' in to main brew repo as a dev-cmd, and has test-bot
use it to detect dylib breakage, which usually means a revision bump is
needed. Checks all dependents, not just those with a 'test do' block
defined, since we can do this without formula support.
Closes#107.
Signed-off-by: Andrew Janke <andrew@apjanke.net>
e70a3552d3 seems to have
exacerbated the problem where taps stick around and then `brew uses` gets executed
on a whole host of taps, which is currently breaking almost every PR for formulae
that would be used cross-tap, as well as causing lengthier CI builds.
Examples from the last week or so include sqlite, V8, protobuf, and so on. Whilst it
may be true that cross-tap formulae failing can show problems that need looking at,
a lot of the time the failures are unrelated to the build in question and just
leave contributors confused on what needs to be done, or why their PR is failing
for something that seems entirely unrelated.
You can see the taps failing to vanish locally by doing something like:
```
brew tap homebrew/fuse
brew tap homebrew/versions
cd $(brew --prefix) && git clean -ffdx --exclude=/Library/Taps/
brew tap
...
homebrew/core
homebrew/fuse
homebrew/versions
```
This is a very simple proposal to handle the problem, but there's no real reason
I couldn't write this functionality into untap itself and then we call that in
test-bot. Just didn't necessarily want to jump immediately to expanding the untap
command to solve what is more-or-less a CI problem.
Also enables sandbox for --interactive and --debug use of install
and test, using automatic retention.
Closes#66.
Signed-off-by: Andrew Janke <andrew@apjanke.net>
We're not sure this is working as it was intended to, and the primary
end product so far has been making every Ruby 1.8.7 build, which is the Ruby
we use on Mavericks for compatibility, take 5-15 minutes longer per build
than 2.x Rubies.
Cumulatively this is responsible for the vast majority of CI slowness over the
last couple months as Mavericks plays catch-up and everything else waits for it
to do so.
We may revisit this in future, but for now the harm is greater than the "risk".
This technically reverts 7b26c585c2.
The method `fix_encoding!` is private to `Homebrew::Step` but is also
required by the `Homebrew.sanitize_output_for_xml` method for truncating
overly long logs. Move `fix_encoding!` into the `Homebrew` module to
make it accessible from both this method and the `Homebrew::Step` class.
This amends commit 343091c828d1e572829b86253d79b326c1986bcd.
This reverts commit ceed6636d6986bb2b993ba4680ae484deb76ae29.
```
==> git clean -ffdx
HEAD is now at ceed663 test-bot: revise Step output transcoding and XML character filtering
Removing Library/Homebrew/test/.bundle/
Removing Library/Homebrew/test/fs_leak_log
Removing Library/Homebrew/test/vendor/
Error: invalid regular expression: /[^
-uD7FFuE000-uFFFDu{10000}-u{10FFFF}]/
```
Using Ruby 1.8.
This reverts commit 51e4e6490bda0d981afd1787a6392ab588b0601c. This did
not work as intended, as the `git` command is executed in the context of
the tap the current job operates on, never for Homebrew/homebrew itself.
If it's not a tap, we test formula on CoreTap. This can happen
if we run test on a fork, e.g. Linuxbrew or future Homebrew/brew.
ClosesHomebrew/homebrew#49844.
Signed-off-by: Xu Cheng <xucheng@me.com>
After formula updates its bottle block, remove itself from changed
formulae list. Therefore, if it's requested next time as dependency, it
will be installed from bottle just created.
ClosesHomebrew/homebrew#48121.
Signed-off-by: Xu Cheng <xucheng@me.com>
This feature is still quite useful, particularly because of the somewhat
buggy behaviour of `default_formula` which means when attempting to build
a bottle it'll attempt to force the installation of that formula.
That is particularly problematic for taps like homebrew/homebrew-fuse because
the `default_formula` in osxfuse conflicts with the osxfuse binary we install
via the Caskroom, which is actively breaking every CI build.
ClosesHomebrew/homebrew#48000.
Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>
