summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Bump Travis entries to use rubygems 2.7.8bump_base_rubygems_and_ruby_2.3_in_travisDavid Rodríguez2019-02-102-5/+5
|
* Bump Travis entries to use MRI 2.3.8David Rodríguez2019-02-101-3/+3
|
* Properly restrict rubygems version for failing specsDavid Rodríguez2019-02-102-2/+2
| | | | | These specs need https://github.com/rubygems/rubygems/pull/1527 to pass, so restrict them to rubygems version containing that.
* Merge #6948Bundlerbot2019-02-102-5/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6948: Bump rubygems to 3.0.2 and ruby to 2.6.1 in TravisCI r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I have some spec failures locally, and they don't seem to be reproduced in TravisCI. ### What was your diagnosis of the problem? My diagnosis was that either my environment is messed up or there's some issues with the latest rubygems + ruby combination. ### What is your fix for the problem, implemented in this PR? My fix is to use latest rubygems and ruby in Travis, so I can double check whether the problem is just my environment or a real problem. ### Why did you choose this fix out of the possible options? I chose this fix because it's always good practice to test against the latest versions of your dependencies. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Bump main tested rubygems to 3.0.2travis_experimentsDavid Rodríguez2019-02-082-2/+2
| |
| * Bump main tested ruby to 2.6.1David Rodríguez2019-02-082-3/+10
| |
* | Merge #6952Bundlerbot2019-02-091-0/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6952: Bump TravisCI build to Xenial r=colby-swandale a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that CI in #6938 is failing, and I'm not sure why. ### What was your diagnosis of the problem? My diagnosis was that I should split the two changes made in that PR to find out the culprit. ### What is your fix for the problem, implemented in this PR? My fix is to split the TravisCI update to xenial, because my guess is that this is not the culprit, so if the build is green, we can merge this and upgrade :tada: ### Why did you choose this fix out of the possible options? I chose this fix because it means no work for me, just delegate to TravisCI. :) Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Bump TravisCI build to XenialxenialDavid Rodríguez2019-02-091-0/+1
|/
* Merge #6941Bundlerbot2019-02-052-1/+11
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6941: Ignore to add bundler lib direcotry if it is same as rubylibdir r=hsbt a=hsbt ### What was the end-user problem that led to this PR? In ruby core, the bundled bundler was located same as rubylibdir. When user used the specific version of default gems like json, Bundler uses default gems under the rubylibdir, not a specific version. Fixed https://bugs.ruby-lang.org/issues/15469 ### What was your diagnosis of the problem? See the details: https://bugs.ruby-lang.org/issues/15469#note-4 ### What is your fix for the problem, implemented in this PR? I avoid adding bundler directory from RUBYLIB environmental variable Because its directory was already added $LOAD_PATH. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * Added explicitly loading for RbConfig.SHIBATA Hiroshi2019-02-051-0/+1
| |
| * Ignore to add bundler lib direcotry if it is same as ↵ignore-bundler-lib-ruby-libSHIBATA Hiroshi2019-02-042-1/+10
|/ | | | | | | | | | | | | RbConfig::CONFIG["rubylibdir"]. https://bugs.ruby-lang.org/issues/15469 In ruby core, the bundled bundler was located same as rubylibdir. When user used the specific version of default gems like json, Bundler uses default gems under the rubylibdir, not specific version. I avoid to add bundler directory from RUBYLIB enviromental variable, Because its directory was already added $LOAD_PATH.
* Merge #6931Bundlerbot2019-01-294-0/+15
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6931: Add patch option in bundle config r=greysteil a=ankitkataria ### What was the end-user problem that led to this PR? Issue #5994 ### What was your diagnosis of the problem? As mentioned by @indirect I added a `patch` option in the bundler config, which by default is false. If set to true, patch level update are preferred if no update levels are specified. ### What is your fix for the problem, implemented in this PR? A patch level config option which can be opted into. Co-authored-by: Ankit Kataria <ankitkataria28@gmail.com>
| * resolve compatibility issuesAnkit Kataria2019-01-271-1/+1
| |
| * change prefer to patch_prefer and updated help textAnkit Kataria2019-01-274-7/+7
| |
| * update bundle config man pageAnkit Kataria2019-01-242-2/+4
| |
| * add patch option in bundle configAnkit Kataria2019-01-243-0/+13
| |
* | Merge #6935Bundlerbot2019-01-2817-26/+26
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6935: Make URLs in document consistent and secure r=greysteil a=aeroastro ### What was the end-user problem that led to this PR? There are 3 documentation problems * End-users experience 301 redirect when visiting http://www.bundler.io and http://bundler.io * End-users might accidentally send email addresses via http version of https://slack.bundler.io, which is not redirected automatically. * Partially fixing this is O.K., but consistent URLs throughout the documentation are easy to use. ### What was your diagnosis of the problem? I have manually visited the Slack invitation URL on https://bundler.io/ and noticed the problem. Following are the simple curl command to explain this problem. ``` $ curl -I http://slack.bundler.io HTTP/1.1 200 OK Server: Cowboy Connection: keep-alive X-Powered-By: Express Content-Type: text/html; charset=utf-8 Content-Length: 3726 Etag: W/"QPm3qygnJrqeFm+KK+VifA==" Date: Mon, 28 Jan 2019 07:32:02 GMT Via: 1.1 vegur ``` ``` $ curl -I http://www.bundler.io HTTP/1.1 301 Moved Permanently Content-Type: text/html; charset=utf-8 Location: https://bundler.io X-Redirector-Version: 84a0a5c Date: Mon, 28 Jan 2019 07:32:28 GMT ``` ``` $ curl -I http://bundler.io HTTP/1.1 301 Moved Permanently Server: GitHub.com Content-Type: text/html Location: https://bundler.io/ X-GitHub-Request-Id: FF7E:37F3:4DD47F:595032:5C4EB012 Content-Length: 178 Accept-Ranges: bytes Date: Mon, 28 Jan 2019 07:32:35 GMT Via: 1.1 varnish Age: 0 Connection: keep-alive X-Served-By: cache-nrt6127-NRT X-Cache: MISS X-Cache-Hits: 0 X-Timer: S1548660755.461639,VS0,VE91 Vary: Accept-Encoding X-Fastly-Request-ID: 8c832766ee3154dc26abd3e1adcd1258a243e4ce ``` ### What is your fix for the problem, implemented in this PR? My fix is to replace old URLs with new URLs. * Replace Slack invitation URLs with safe https ones * Replace http://www.bundler.io with https://bundler.io * Replace http://bundler.io with https://bundler.io ### Why did you choose this fix out of the possible options? Because rewriting URLs on document is easy and simple. Optionally, if someone could implement 301 redirect on Slack invitation URL, it would further help the issue. Co-authored-by: Takumasa Ochi <aeroastro007@gmail.com>
| * | Replace unsafe http URLs with https URLsTakumasa Ochi2019-01-2816-23/+23
| | |
| * | Replace 301 www.bundler.io with bundler.ioTakumasa Ochi2019-01-281-3/+3
|/ /
* | Merge #6924Bundlerbot2019-01-2411-18/+18
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6924: Bump rake version to 12.0 on gemspec template r=hsbt a=hsbt ### What was the end-user problem that led to this PR? Related with https://github.com/bundler/bundler/pull/6923 ### What was your diagnosis of the problem? rake-10.x displayed the warnings of `Object =~` with Ruby 2.7.0-dev. ### What is your fix for the problem, implemented in this PR? Rake 10.0 is EOL. I'm a maintainer of Rake. I have no plan to avoid `Object =~` warnings with Rake 10.x. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * | Update the additional versions of rake in rspec examples.update-default-version-of-templateSHIBATA Hiroshi2019-01-248-13/+13
| | |
| * | Fixed failing examples.SHIBATA Hiroshi2019-01-242-4/+4
| | |
| * | Bump rake version to 12.0 on gemspec template. Because rake-10.0 is EOL now.SHIBATA Hiroshi2019-01-241-1/+1
| | |
* | | Merge #6926Bundlerbot2019-01-242-8/+4
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6926: Move Rubocop development dependency into gemspec r=hsbt a=alyssais ### What was the end-user problem that led to this PR? The problem was that tools like RubyGems.org or Bundix that use the gemspec as the source of truth for dependencies didn't pick up on the development dependency on Rubocop. ### What was your diagnosis of the problem? My diagnosis was that the reason for this, which was that Rubocop had a minimum Ruby version of 2.0.0, was no longer an issue, since Bundler 2 doesn't support Rubies that old anyway. ### What is your fix for the problem, implemented in this PR? My fix was to move the Rubocop requirement into the gemspec. ### Why did you choose this fix out of the possible options? I chose this fix because it addresses the problem I was having, feels right, and the old workaround doesn't look like it's necessary any more. Co-authored-by: Alyssa Ross <hi@alyssa.is>
| * | Move Rubocop development dependency into gemspecAlyssa Ross2019-01-232-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that Bundler no longer supports Ruby <2.3, the Ruby minimum version requirement that prevented Rubocop from being specified as a development dependency in the gemspec no longer applies. Having Rubocop in the gemspec is useful for tools like RubyGems.org or Bundix that use it as the source of truth for dependencies.
* | | Merge #6923Bundlerbot2019-01-232-2/+2
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6923: Ignore `Object =~` warnings. r=segiddins a=hsbt ### What was the end-user problem that led to this PR? We faced a lot of warnings with `rake spec` of bundler repository. ### What was your diagnosis of the problem? Ruby 2.7.0-dev added the warnings for `Object =~` comparison. ### What is your fix for the problem, implemented in this PR? I added the additional condition and bump a version of the development dependency. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * | Added condition for Object =~ comparison.SHIBATA Hiroshi2019-01-231-1/+1
| | |
| * | Bump rake version of Bundler's dependency.SHIBATA Hiroshi2019-01-231-1/+1
|/ / | | | | | | Ruby 2.7.0-dev added the warnings about Object =~. We need to avoid it.
* | Merge #6315Bundlerbot2019-01-233-33/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6315: Removed compatibility hack for old rubies. r=hsbt a=hsbt ### What was the end-user problem that led to this PR? Nothing. ### What is your fix for the problem, implemented in this PR? Bundler will never use them in version 2. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * | Update .travis.ymlremove-old-rubySHIBATA Hiroshi2019-01-121-0/+1
| | |
| * | Merge branch 'master' into remove-old-rubySHIBATA Hiroshi2019-01-1279-331/+836
| |\ \
| * | | Removed old ruby in Travis CI.SHIBATA Hiroshi2018-10-171-2/+0
| | | |
| * | | Removed compatibility hack for old rubies.SHIBATA Hiroshi2018-10-173-34/+9
| | | |
* | | | Merge #6884Bundlerbot2019-01-231-1/+1
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6884: Remove unnecessary condition r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that some code in the feature flags implementation seemed uncovered. ### What was your diagnosis of the problem? My diagnosis was that the code should be either covered or removed. ### What is your fix for the problem, implemented in this PR? My fix was to remove the code. ### Why did you choose this fix out of the possible options? I chose this fix because the scenario where that code would get covered is more likely to be unintentional and risk introducing a bug. Defining a feature flag without a default block is the same as don't defining a feature flag and just relying on the default value for the setting. In these circumstances, it's more likely that the developer forgot to include a default block, so letting that case crash would be better, I think. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Remove unnecessary conditionremove_unnecessary_conditionDavid Rodríguez2019-01-071-1/+1
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is currently dead code because all feature flags specify a default block. With the current implementation, if we ever defined a feature flag without specifying a default block, it would instead return the default setting value. I think it is better to raise an error in that case, since it would probably be an overlook and not something intentional.
* | | | Merge #6793Bundlerbot2019-01-234-228/+0
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6793: Removed exe/bundle_ruby and its example. r=hsbt a=hsbt Originated from #3489 `exe/bundle_ruby` was already removed from bundler's gemspec. We can remove it now. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * | | Removed deprecated example.remove-bundle_rubySHIBATA Hiroshi2018-11-211-8/+0
| | | |
| * | | Removed exe/bundle_ruby and its example.SHIBATA Hiroshi2018-11-203-220/+0
| | | |
* | | | Merge #6864Bundlerbot2019-01-152-2/+12
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6864: Include URL in Bundler::Fetcher::FallbackError message for Net::HTTPNotFound r=segiddins a=greysteil ### What was the end-user problem that led to this PR? It was really painful to debug persistent NotFound errors, as it wasn't clear where they were coming from, ### What was your diagnosis of the problem? Bundler was obfuscating the URL that wasn't found unnecessarily. ### What is your fix for the problem, implemented in this PR? My fix is to add the URL to the `Bundler::Fetcher::FallbackError` message for `Net::HTTPNotFound` errors. ### Why did you choose this fix out of the possible options? I chose this fix because it was simple and easy to test. Co-authored-by: Grey Baker <greysteil@gmail.com>
| * | | Ensure credentials are masked in FallbackError from Net::HTTPNotFoundgreysteil/show-notfound-uriGrey Baker2019-01-142-1/+10
| | | |
| * | | Include URL in Bundler::Fetcher::FallbackError message for Net::HTTPNotFoundGrey Baker2019-01-032-2/+3
|/ / /
* | | Merge #6856Bundlerbot2018-12-3012-25/+62
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6856: Test against Ruby 2.6 and RubyGems 3 r=colby-swandale a=segiddins ### What was the end-user problem that led to this PR? The problem was we weren't testing our compatibility with the latest and greatest. Co-authored-by: Samuel Giddins <segiddins@segiddins.me> Co-authored-by: Colby Swandale <me@colby.fyi>
| * | | fix breaking bundler 1 spec for ruby 2.6 with RG 2.7segiddins/ruby-2.6Colby Swandale2018-12-291-3/+3
| | | |
| * | | ignore RubyGems warnings about deprecated methods in version.rbColby Swandale2018-12-291-1/+5
| | | |
| * | | embed Shellwords.escape into bundler gemspecColby Swandale2018-12-291-1/+2
| | | |
| * | | fix usuage of IO.popen on Ruby 1.8Colby Swandale2018-12-281-1/+1
| | | |
| * | | make system_bundle_bin_path helper and resolve failing tests for ruby < 2.6Colby Swandale2018-12-283-2/+7
| | | |
| * | | set `bundle` spec helper to load the system bundler binstub directly instead ↵Colby Swandale2018-12-281-1/+1
| | | | | | | | | | | | | | | | of depending on the $PATH
| * | | Fix specs that are broken in ruby 2.6Samuel Giddins2018-12-283-9/+24
| | | |
| * | | Test against Ruby 2.6 and RubyGems 3Samuel Giddins2018-12-284-10/+22
| | | |
View Lorry Controller Status