summaryrefslogtreecommitdiff
path: root/spec
Commit message (Collapse)AuthorAgeFilesLines
* Fully switch to https sourceshttps_sourcesDavid Rodríguez2019-04-243-86/+25
|
* Merge #6329Bundlerbot2019-04-241-0/+33
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6329: Stop printing “failed to update” message when changing sources r=segiddins a=segiddins ### What was the end-user problem that led to this PR? The problem was `bundle update` shows incorrect message when updating git gems Closes #6325 ### What was your diagnosis of the problem? My diagnosis was we need to check if the source has changed ### What is your fix for the problem, implemented in this PR? My fix only prints the message when the source has not changed Note that is does not yet fix the "updated the git sha" case, since the locked spec and the new spec actually share the same source object! Co-authored-by: Samuel Giddins <segiddins@segiddins.me> Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Add a failing spec for not warning when a git gem updates ref but not versionSamuel Giddins2019-04-131-0/+16
| |
| * [Update] Stop printing “failed to update” message when changing sourcesSamuel Giddins2019-04-131-0/+17
| |
* | Merge #7129Bundlerbot2019-04-241-0/+49
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7129: Bundle env improvements r=deivid-rodriguez a=deivid-rodriguez This came from debugging #7096. ### What was the end-user problem that led to this PR? The problem was that `bundle env` is great, but could be more useful and accurate. ### What is your fix for the problem, implemented in this PR? My fix is to start improving it, by dumping more paths, and more accurate information, and getting the paths tested. ### Why did you choose this fix out of the possible options? I have a few more improvements in mind, but I want to keep my PRs small. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Add user home to `bundle env`David Rodríguez2019-04-151-0/+7
| | |
| * | Add some specs for rubygems paths in `bundle env`David Rodríguez2019-04-151-0/+41
| | |
| * | Add require so that env specs can run in isolationDavid Rodríguez2019-04-151-0/+1
| | |
* | | Skip platform warnings in inline modeskip_platform_warnings_during_bundle_inlineDavid Rodríguez2019-04-241-0/+13
| | | | | | | | | | | | Since there's no lock file, I don't think they make sense.
* | | Merge #7125Bundlerbot2019-04-241-0/+14
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7125: Ignore `frozen` setting in inline mode r=indirect a=deivid-rodriguez Fixes #7114. ### What was the end-user problem that led to this PR? The problem was that the inline mode wouldn't work if `BUNDLE_FROZEN` is set. ### What was your diagnosis of the problem? My diagnosis was that since we're in frozen mode, the current platform doesn't get added to the definition, and thus platform validation fails. ### What is your fix for the problem, implemented in this PR? My fix is to temporary ignore `BUNDLE_FROZEN` for the inline mode. The inline mode can't really be frozen since it has no lock file. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Ignore `frozen` setting in inline modeignore_frozen_setting_in_inline_modeDavid Rodríguez2019-04-121-0/+14
| | | |
* | | | Merge #7127Bundlerbot2019-04-231-0/+24
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7127: Add git and branch options to `bundle add` r=deivid-rodriguez a=tokachev Closes #6841 These changes will allow to add a gem with the git or branch options. ``` bundle add redis --git "https://github.com/redis/redis-rb" --branch "staging" ``` The result in Gemfile will be: ``` gem "redis", "~> 4.0", :git => "https://github.com/redis/redis-rb", :branch => "staging" ``` Co-authored-by: Baumgarten <baumgarten@localhost.localdomain>
| * | | | Add git and branch options to `bundle add`Baumgarten2019-04-131-0/+24
| | | | |
* | | | | Add spec for using relative requiresrequire_relativeDavid Rodríguez2019-04-221-0/+16
| | | | |
* | | | | Add missing requireDavid Rodríguez2019-04-221-0/+2
| |_|/ / |/| | | | | | | | | | | So that the spec can be run in isolation.
* | | | Merge #7120Bundlerbot2019-04-141-6/+27
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7120: Fix spec calling incorrect helper r=deivid-rodriguez a=deivid-rodriguez Thanks so much for the contribution! To make reviewing this PR a bit easier, please fill out answers to the following questions. ### What was the end-user problem that led to this PR? The problem was the subprocess spawed by one spec was crashing, but that was not making the spec fail. ### What was your diagnosis of the problem? My diagnosis was that since the spec was checking for a failure status of the subprocess, that was not specific enough to detect the particular bug in this spec (it was calling `clean_system`, removed from bundler 3, instead of `unbundled_system`). ### What is your fix for the problem, implemented in this PR? My fix is to restore the previous strategy for these specs, namely, check for a more specific status than 0 or 1. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Fix spec calling incorrect helperfix_helpers_specsDavid Rodríguez2019-04-121-6/+27
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The spec was crashing on bundler 3, but since the spec was checking for a failure status for the subprocess, it was actually passing. So, as part of this change, I make helper specs more resilient again. These specs were previously checking for a more specific status than 0 or 1, but I removed that at some point. Now I see how it was useful, so I'm restoring it.
* | | | Merge #7128Bundlerbot2019-04-1413-14/+15
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1412-14/+14
| | | | |
| * | | | Added explicitly loading rspec. Because ruby core didn't use rspec cli directly.SHIBATA Hiroshi2019-04-141-0/+1
| | |_|/ | |/| |
* | | | Merge #6730Bundlerbot2019-04-1441-194/+172
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1215-44/+44
| | | |
| * | | s/last_command.stderr/err/David Rodríguez2019-04-1223-84/+84
| | | |
| * | | Unify stderr helpersDavid Rodríguez2019-04-1220-42/+38
| | | |
| * | | Print errors to stderr by default, and remove configuration optionGrey Baker2019-04-124-27/+9
| |/ /
* | | Fix bin conflict spec to not use deprecated featurewarn_to_deprecationDavid Rodríguez2019-04-121-2/+2
| | |
* | | Another tryDavid Rodríguez2019-04-121-1/+1
| | |
* | | Remove unnecessary requireDavid Rodríguez2019-04-121-1/+1
| | |
* | | Improve wordingDavid Rodríguez2019-04-121-2/+2
| | |
* | | Run related specs for all versionsDavid Rodríguez2019-04-121-2/+2
| | |
* | | Add warning about conflicting executablesDavid Rodríguez2019-04-121-2/+11
| | |
* | | 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.
* | | Remove debugging shellsDavid Rodríguez2019-04-121-4/+0
|/ /
* | Merge #7113Bundlerbot2019-04-121-50/+46
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7113: Make `init_gems_rb` a regular setting r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that we have a feature flag to change the file name of the file where gems are defined from `Gemfile` to `gems.rb`, and it is unclear whether we will actually do this, and when. ### What was your diagnosis of the problem? My diagnosis was that a feature flag is not a good fit here. It's perfectly fine to configure this and allow users to use `gems.rb` by default for their gems, but we don't know when/if we will actually change the default so a plain setting feels better than a feature flag. ### What is your fix for the problem, implemented in this PR? My fix is to convert the `init_gems_rb` feature flag into a plain setting. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Make `init_gems_rb` a regular settingmake_init_gems_rb_a_settingDavid Rodríguez2019-04-111-50/+46
| | | | | | | | | | | | | | | | | | | | | I think it's nice that users can configure this and start using `gems.rb`. But there's no need to make this a feature flag and change its default value. Let's keep generating Gemfile's by default until we are ready, if we ever are.
* | | Remove `prefer_gems_rb` settinginit_gems_rbDavid Rodríguez2019-04-113-55/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | In my opinion, it's overkill to provide a setting for how little this setting was doing. Both types of Gemfile are supported and work regardless of this setting. The only difference this setting would make is the warning message one would get when having _both_ types of Gemfiles in the same project. I changed things so that gems.rb is always looked up first, and the warning message in case you have both always tells you to remove Gemfile and Gemfile.lock.
* | Move on to bundler 3David Rodríguez2019-04-1148-406/+255
| | | | | | | | | | | | * Drop bundler 1 stuff from tests. * Move all feature flags to bundler 3 (like they are in 2-0-stable) and get them tested.
* | Fix deprecation warningDavid Rodríguez2019-04-111-1/+1
| |
* | Fix some specs to not rely on remembering flagsDavid Rodríguez2019-04-112-4/+5
| |
* | Change deploy specs to properly configure deploymentDavid Rodríguez2019-04-111-6/+9
| |
* | Merge #7057Bundlerbot2019-04-119-58/+168
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7057: Review multiple sources deprecation r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I had not yet reviewed the deprecation about multiple global sources being present on a Gemfile, and thus the specs were skipped. ### What was your diagnosis of the problem? My diagnosis was that we need to delay the removal of multiple sources support to bundler 3, so that we can show the deprecations in the 2.x series. I also noticed that part of the deprecation message was inaccurate. In order to upgrade the warning to an error, you would also need to configure the `lockfile_uses_separate_rubygems_sources` setting. Otherwise you will get an error that these two settings depend on each other and can't be enabled separatedly. ### What is your fix for the problem, implemented in this PR? My fix is to delay these feature flags to bundler 3 so that the deprecation specs pass. Also, since before giving this advice I'd like to study why we have two different settings that can't be enabled separately, and why the can't be merged to a single one, I have removed that part of the message for now. ### Why did you choose this fix out of the possible options? I chose this fix because it keeps me moving with reviewing all the deprecations for bundler 3 breaking changes, and makes sure that the deprecations for this change of behavior are tested (and passing). Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Refactor list specs to not change gemfile sourcesmultiple_sources_deprecationDavid Rodríguez2019-04-082-15/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, all specs would bundle a Gemfile from the "repo1" source by default. Then, some list specs would end up using a "repo2" source. The behavior when changing repo sources is changing with the `disable_multisource` setting, but it is unrelated to the list command. So, I refactored the list command specs to not change sources, and extracted the behavior change about changing sources to a separate spec.
| * | Check the full warning textDavid Rodríguez2019-04-081-1/+8
| | |
| * | Fix multiple source deprecation spec on bundler 2David Rodríguez2019-04-081-2/+2
| | |
| * | Move multiple global source removal to bundler 3David Rodríguez2019-04-086-21/+55
| | | | | | | | | | | | And fix specs.
| * | Merge multisource related settingsDavid Rodríguez2019-04-082-5/+2
| | |
| * | Unify multiple source deprecation specsDavid Rodríguez2019-04-082-14/+17
| | | | | | | | | | | | | | | | | | Move them to the file where all deprecations are tested. And test just the simple case, since the deprecations logic should be the same for all cases.
| * | Remove unnecessary Gemfile creationDavid Rodríguez2019-04-081-1/+0
| | | | | | | | | | | | Gemfile is not considered in this situation.
| * | Remove redundant `bundle! :install`David Rodríguez2019-04-081-2/+0
| | | | | | | | | | | | `install_gemfile!` already runs that.
* | | Merge #7110Bundlerbot2019-04-093-8/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7110: Cleanup old rubies stuff r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that there was still some code specific for old rubies in our code base. ### What is your fix for the problem, implemented in this PR? My fix is to remove that code. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
View Lorry Controller Status