summaryrefslogtreecommitdiff
path: root/spec/commands/exec_spec.rb
Commit message (Collapse)AuthorAgeFilesLines
* Get `bundle exec` respecting proc titlesfix_exec_proc_titleDavid Rodríguez2019-04-261-0/+11
|
* Merge #7128Bundlerbot2019-04-141-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7128: Backport to workaround from ruby core. r=deivid-rodriguez a=hsbt ### What was the end-user problem that led to this PR? The current master branch couldn't invoke with the ruby core repository. ### What was your diagnosis of the problem? 1. We need to add explicitly declare `rspec` in spec_helper.rb 2. Some examples were failed on ruby core repository. ### What is your fix for the problem, implemented in this PR? 1. simply added. 2. update the `ruby_repo` labels for skipping to run. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * Update ruby_repo filter with the latest ruby-core implementaion.SHIBATA Hiroshi2019-04-141-2/+2
| |
* | Merge #6730Bundlerbot2019-04-141-11/+11
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6730: Print errors to stderr by default, and remove configuration option r=greysteil a=greysteil ### What was the end-user problem that led to this PR? The problem was #6729 - Bundler unexpectedly outputs error and warning messages to STDOUT. ### What was your diagnosis of the problem? My diagnosis was that whilst very minorly breaking, this is essentially a bug fix, and should be considered for inclusion for Bundler 2.0 even if very few other breaking changes are. ### What is your fix for the problem, implemented in this PR? My fix was so switch output for warning and error messages to STDERR, and remove the configuration option (as is redundant once the setup is flipped - anyone wanting to redirect those message to STDOUT could do so in their shell). ### Why did you choose this fix out of the possible options? I chose this fix because I think the new behaviour is what everyone would expect, and we should get it out from behind its feature switch sooner rather than later. Alternatively, we might want to keep the Bundler 2.0 release "purer" by only dropping Ruby versions in it - that's totally fine too, but I figured we should have the code to discus #6729, rather than doing it in abstract. Co-authored-by: Grey Baker <greysteil@gmail.com> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * s/last_command.stdout/out/greysteil/print-errors-to-stderrDavid Rodríguez2019-04-121-1/+1
| |
| * s/last_command.stderr/err/David Rodríguez2019-04-121-10/+10
| |
* | Convert binstub conflict deprecation to a warningDavid Rodríguez2019-04-121-0/+29
|/ | | | | | | | | | | And test it. I don't think it makes sense as a deprecation, since nothing is changing, and there's no alternative. This is a potentially undesired situation caused by gems shipping executables conflicting with the executables of other gems. `bundle exec` is fine in general, this is just a potentially undesired situation that can be fixed by using project specific binstubs.
* Move on to bundler 3David Rodríguez2019-04-111-52/+4
| | | | | | * Drop bundler 1 stuff from tests. * Move all feature flags to bundler 3 (like they are in 2-0-stable) and get them tested.
* Move multiple global source removal to bundler 3David Rodríguez2019-04-081-0/+19
| | | | And fix specs.
* Merge #6963Bundlerbot2019-04-011-0/+77
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6963: Allow to `bundle exec` default gems r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that since `irb` and others were moved to default gems, users cannot directly use them in a bundler context, unless they add it to their gemfiles. In my opinion, this completely defeats the purpose of default gems, and makes bundler degrade the user experience instead of making it better. ### What was your diagnosis of the problem? My diagnosis was that when bundler replaces the set of gems known to rubygems, it restricts the world to what's in the Gemfile (or resolved from it), and that doesn't include default gems. ### What is your fix for the problem, implemented in this PR? My fix is to also include the set of default gems, unless they are already included in the gemfile dependencies. ### Why did you choose this fix out of the possible options? I chose this fix because it's reasonably simple and I think it shouldn't affect how other parts of bundler function. Fixes #6929. Fixes https://bugs.ruby-lang.org/issues/15503. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Allow to `bundle exec` default gemsDavid Rodríguez2019-03-271-0/+77
| | | | | | | | Even when they are not explicitly specified in the Gemfile.
* | Remove `bundle config` deprecations from specsremove_bundle_config_deprecationsDavid Rodríguez2019-03-291-2/+2
| |
* | This spec is now passing, it seemsunskip_not_failing_specDavid Rodríguez2019-03-281-2/+0
|/
* Remove ruby version leftoversremove_ruby_version_leftoversDavid Rodríguez2019-03-151-8/+3
|
* Remove old 1.9 stuffDavid Rodríguez2019-03-131-22/+4
|
* Remove unnecessary rubygems filters from specsDavid Rodríguez2019-02-251-16/+2
|
* Remove unnecessary ruby filters from specsremove_unnecessary_ruby_filtersDavid Rodríguez2019-02-221-1/+1
|
* Use newest interface to `bundle config` everywhereDavid Rodríguez2019-02-191-2/+2
|
* Fix 1.x specscheck_out_only_in_specsDavid Rodríguez2019-02-141-4/+4
|
* Remove now unnecessary `lack_errors` matcherDavid Rodríguez2019-02-141-2/+2
| | | | | Since the errors are checked on their own stream, no filtering is needed.
* Split stderr and stdout in specsDavid Rodríguez2019-02-141-5/+6
|
* Spec behaves consistenly across OS's apparentlyDavid Rodríguez2019-02-121-1/+1
|
* Stop leaking to system rubygems on subprocessesDavid Rodríguez2019-02-121-10/+8
| | | | | | | | | | | In order to be able to test against different versions of rubygems, we prepend our local copy of rubygems to the $LOAD_PATH. This is done as early as possible, inside each binstubs through [this helper file]. However, some subprocesses overwrite the `RUBYOPT` env variable, thus leaking to the system copy of rubygems again. Since we already [prepend the hacks file] to `RUBYOPT` in the main helper, while also preserving the previous value, this "customized environments" are not needed.
* Properly restrict rubygems version for failing specsDavid Rodríguez2019-02-101-1/+1
| | | | | These specs need https://github.com/rubygems/rubygems/pull/1527 to pass, so restrict them to rubygems version containing that.
* make system_bundle_bin_path helper and resolve failing tests for ruby < 2.6Colby Swandale2018-12-281-1/+2
|
* Backport from ruby coreSHIBATA Hiroshi2018-11-011-11/+11
|
* Added ruby_core filtering condition with some examples.SHIBATA Hiroshi2018-10-201-12/+12
| | | | The ruby core repository couldn't invoke its examples.
* Remove unnecessary assertion exclusionremove_unnecessary_assertion_exclusionDavid Rodríguez2018-09-241-4/+1
| | | | I think this was a bad fix and it's no longer necessary.
* Better conditional assertionfix_locally_failing_specDavid Rodríguez2018-09-111-1/+1
| | | | So that the spec also passes for developers under Linux.
* Uses logic from cli and removes redundant testankitkataria2018-09-021-7/+0
|
* Fixes test for --gemfile flagankitkataria2018-08-281-4/+10
|
* Add test for --gemfile flagankitkataria2018-08-241-0/+10
|
* Skip system bundler execution on Travis CI with Ruby 2.6.SHIBATA Hiroshi2018-06-151-0/+2
|
* fix failing exec spec that is blocking 1.16.2colby/fix-exec-specColby Swandale2018-04-141-14/+2
|
* Another attemptNikita Esaulov2018-03-151-3/+7
|
* Another attemptNikita Esaulov2018-03-151-0/+2
|
* Fix testNikita Esaulov2018-03-151-1/+1
|
* Update `expected_err` for ruby < 1.9Nikita Esaulov2018-03-151-1/+5
|
* Fix failure when exception backtrace is nilNikita Esaulov2018-03-151-0/+20
|
* Auto merge of #6223 - shayonj:s/hup-fix, r=segiddinsThe Bundler Bot2018-02-031-20/+50
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only trap INT signal and set to DEFAULT ### What was the end-user problem that led to this PR? The problem was commands like `nohup bundler exec {program}` wouldn't work as intended. For example, if a `HUP` signal were to be sent to the process running the `bundle exec ..`, it should in theory not terminate. Because, `nohup` would `IGNORE` that signal. But, that is not what the case is case is currently. ### What was your diagnosis of the problem? My diagnosis was, if a process/bundler execution already had a `SIGNAL` set to it, example `HUP`, then performing `bundle exec {program}`, would mean that bundler resets any prior `SIGNAL`s on that process and sets them to `DEFAULT`. ### What is your fix for the problem, implemented in this PR? My fix to the problem is to only trap `SIGNAL`s that we think should be set to `DEFAULT`, in this case, `INT`. ### Why did you choose this fix out of the possible options? I chose this fix because its lot less aggressive than setting every signal to `DEFAULT`, and gives us the work with a smaller set of `SIGNAL`s. It also felt cleaner than having to trap a signal first and then restore to its predecessor value. ---- This is a dump that shows the before and after signals, when `nohup bundle exec {program }` gets run. ``` SIGEXIT: Before Handler: (), Current Handler: (DEFAULT) SIGHUP: Before Handler: (IGNORE), Current Handler: (DEFAULT) SIGINT: Before Handler: (#<Proc:0x00007f8e100534f8@/Users/<>/.rvm/gems/ruby-2.4.2/gems/bundler-1.16.0/exe/bundle:5>), Current Handler: (DEFAULT) SIGQUIT: Before Handler: (DEFAULT), Current Handler: (DEFAULT) SIGTRAP: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGABRT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGIOT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGEMT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGSYS: Before Handler: (), Current Handler: (DEFAULT) SIGPIPE: Before Handler: (), Current Handler: (DEFAULT) SIGALRM: Before Handler: (DEFAULT), Current Handler: (DEFAULT) SIGTERM: Before Handler: (DEFAULT), Current Handler: (DEFAULT) SIGURG: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGTSTP: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGCONT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGCHLD: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGCLD: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGTTIN: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGTTOU: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGIO: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGXCPU: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGXFSZ: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGPROF: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGWINCH: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) SIGUSR1: Before Handler: (DEFAULT), Current Handler: (DEFAULT) SIGUSR2: Before Handler: (DEFAULT), Current Handler: (DEFAULT) SIGINFO: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT) ``` From this, we can see only `INT` is being trapped by bundler ``` SIGINT: Before Handler: (#<Proc:0x00007f8e100534f8@/Users/<>/.rvm/gems/ruby-2.4.2/gems/bundler-1.16.0/exe/bundle:5>), Current Handler: (DEFAULT) ``` hence, the only one being restored back to `DEFAULT` ---- Issue: https://github.com/bundler/bundler/issues/6150
| * Clean up signal handler testSamuel Giddins2018-01-151-37/+45
| |
| * Add spec to make sure unexpected signals are not restored to DEFAULTShayon Mukherjee2018-01-151-0/+22
| |
* | Fix failing spec in the bundle exec system gem speccolby/fix-exec-failing-testColby Swandale2018-01-261-1/+1
|/ | | | | | | | | There was an issue where a spec was failing because it was activating the version of bundler inside of RubyGems and not the development version that we're working on. This would cause the Lockfile to raise an error because we were generating a Bundler 2 lockfile but Bundler 1 was being activated.
* typofix by misspelltypo-fixSHIBATA Hiroshi2018-01-101-1/+1
|
* Added workarounds for Travis specific issues.SHIBATA Hiroshi2017-12-211-4/+8
|
* Try to get specs passing on old RubyGemsSamuel Giddins2017-12-211-8/+10
|
* Auto merge of #6007 - hsbt:use-halper-methods-for-path, r=segiddinsThe Bundler Bot2017-12-111-4/+2
| | | | | | | | | | | | | Use helper methods for relative path references in the specs Ruby core needs to change `Spec::Path.root` and gemspec, bin, spec directories structure. 1. I changed spec directory from `spec` to `spec/bundler` because ruby core has rubyspec files under the `spec/rubyspec`. 2. I changed gemspec location to `bundler.gemspec` to `lib/bundler.gemspec`. ref. https://bugs.ruby-lang.org/issues/12733#note-15 This pull request make we can modify root, gemspec path to flexible locations. After merging this pull request, I will add directory structure of ruby core repository to only `spec/support/path.rb`
* Auto merge of #6092 - dekellum:do-not-rescue-signal-exception, r=segiddinsThe Bundler Bot2017-10-301-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Avoid bundle exec rescue of SignalException Avoid rescue of SignalException in kernel_load and with_friendly_errors This allows SignalException to be handled gracefully by the ruby interpreter. This supersedes #6091. ### What was the end-user problem that led to this PR? Fixes #6090 ### What was your diagnosis of the problem? CLI::Exec#kernel_load should not rescue the SignalException. Neither should with_friendly_errors, so it unwinds all the way to the ruby interpreter. ### What is your fix for the problem, implemented in this PR? Two rescue and re-raises specific to SignalException. ### Why did you choose this fix out of the possible options? My first naive attempt was #6091, where I had missed the outer rescue in with_friendly_errors, all of the other special friendly error behavior, and the spec dependencies. While I still suspect that kernel_load and friendly_errors might be rescuing/handling more than they should (for comparison: binstub doesn't do this) this is a much more minimal, safer, and easier fix to #6090. (cherry picked from commit 6d0b74cde28ea0c1724f37ff799cd7524ff0d9b4)
* Ensure the rackup binstub is present on 2.0 when it should beseg-auto-cleanSamuel Giddins2017-08-281-0/+1
|
* Automatically bundle clean without a path set on 2.0Samuel Giddins2017-08-281-1/+1
|
View Lorry Controller Status