After branching, bumping, pushing, and pr-ing; return to whatever branch
was originally checked out.
In most cases, I'd imagine users to want to continue receiving tap
updates from master. However, after using bump-formula-pr, the tap in
which the formula was bumped is left on the working branch that was
doing the bumping and pull-request. After opening the PR, we should
return to whatever branch the user originally had checked out – most
likely master. (But git allows us to just say "previous branch" by using
`-`)
Without `--no-track`, some git setups may automatically set
`origin/master` as the tracked upstream for the newly created branch.
This upstream is what hub defaults as --head when opening PRs. By not
allowing git to set `origin/master` as upstream, hub can then use the
proper --head for the PR.
Since hub still needs to know what --head is intended to be, we can set
the branch's upstream when pushing: with the --set-upstream option.
Fixes#755
- ignore Cask's files in `readall` (for now, there's an intentional
syntax error that will need fixed)
- run Cask's tests if they exist
- don't check Cask's files in coverage reports (for now)
Loosen this a bit; we don't necessarily expect the end commit is the one
we're looking for, just that it has changed from the start commit (i.e.
some sort of update has occurred).
Addresses some false negatives on `master` branch merges that weren't
present on the PR commits.
When running on Travis CI, both the Linux and macOS build will send a
coverage report, causing them to be merged by Coveralls. This results
in inferior coverage due to the early stage of the Linux-specific tests
and is probably not what we want. Make sure we only send a report for
macOS (assuming we stick with a single macOS build in `.travis.yml`).
`any?` is not the opposite of `empty?`. Besides the case that
`[false, nil].any?` will return false, `any?`(O(n)) has much worse
performance than `empty?`(O(1)).
Rather than nudge people to run `--strict` and then ignore some of the
results sometimes (e.g. GitHub repository notability) instead add a
dedicated `--new-formula` option that implies this is a one-time
advisory check.
Make sure to call `brew tests` only once with `--coverage` to avoid
expensive multiple runs and to prevent later runs from overwriting
previously sent results to Coveralls. (The previous setup overwrote the
results from a regular run with results from the `--generic` run.)
The `--no-compat` variant without any other options specified seemed to
be the most appropriate for a coverage report.
Closes#546.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
* test-bot: start running generic tests.
Start running the test suite in the "generic" mode i.e. a base layer for
non-OS X platforms to be able to use to ensure we don't break the generic code
for the parts of the code we've got running.
Currently this just runs the integration tests as that's the only useful suite
that's entirely passing but eventually this will be changed to run the full test
suite in generic mode.
* test_integration_cmds: fix tests on Linux.
* global: add RUBY_TWO global variable.
* test-bot: use RUBY_TWO global variable.
* github: produce better curl error messages.
If we don't know why curl has failed then ensure that the error messages
that it produced are included as part of the user output.
Steven Peters