summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Try to use env with RGV variable in the toplevelHiroshi SHIBATA2020-03-062-14/+6
|
* Update .github/workflows/ubuntu-bundler3.ymlHiroshi SHIBATA2020-03-061-1/+1
| | | Co-Authored-By: David Rodríguez <deivid.rodriguez@riseup.net>
* For Ruby 2.3Hiroshi SHIBATA2020-03-061-1/+2
|
* StyleHiroshi SHIBATA2020-03-062-4/+2
|
* Merge spec:sudo to ubuntu and ubuntu-bundler3 jobsHiroshi SHIBATA2020-03-063-37/+11
|
* Remove needless dependencyHiroshi SHIBATA2020-03-062-2/+0
|
* Install dev dependencies programmaticallyDavid Rodríguez2020-03-061-4/+8
| | | | | | | | | | | | | Without shelling out. It should be faster, and it avoids a ruby 2.3 issue where gems installed through a subprocess are not picked up by the currently running rubygems. I'm also removing some unneeded `travis_retry` from the TravisCI configure. These steps shouldn't timeout and if they do, we should figure out why. Also, they could be hiding other issues not related to the network. In this case, `travis_retry bin/rake spec:parallel_deps` was hiding the issue installing dev dependencies being fixed by this commit.
* continue-on-error with ruby-headHiroshi SHIBATA2020-03-061-0/+1
|
* Revert "Added additional dependency for Ruby 2.8"Hiroshi SHIBATA2020-03-061-2/+0
| | | | This reverts commit a39e100be885f72a261a4c78032655d13502e44e.
* Added additional dependency for Ruby 2.8Hiroshi SHIBATA2020-03-061-0/+2
|
* Simplify to install parallel gemHiroshi SHIBATA2020-03-061-1/+1
|
* renameHiroshi SHIBATA2020-03-062-2/+2
|
* Run test with BUNDLER_SPEC_SUB_VERSION=3Hiroshi SHIBATA2020-03-061-0/+5
|
* Revert "Try to remove needless installation"Hiroshi SHIBATA2020-03-062-0/+2
| | | | This reverts commit f018c6dd687b33c71b5ddb42c5e437704e73bd15.
* Try to remove needless installationHiroshi SHIBATA2020-03-062-2/+0
|
* Added RGV to spec:realworldHiroshi SHIBATA2020-03-062-0/+2
|
* Removed needless envHiroshi SHIBATA2020-03-061-1/+0
|
* Removed needless graphviz dependsHiroshi SHIBATA2020-03-061-1/+0
|
* Update .github/workflows/ubuntu.ymlHiroshi SHIBATA2020-03-061-1/+1
| | | Co-Authored-By: David Rodríguez <deivid.rodriguez@riseup.net>
* Remove Travis configurationHiroshi SHIBATA2020-03-061-43/+0
|
* Migrate spec:sudo to GitHub ActionsHiroshi SHIBATA2020-03-061-0/+32
|
* Split bundler 3 jobsHiroshi SHIBATA2020-03-062-19/+40
|
* SimplifyHiroshi SHIBATA2020-03-061-1/+19
|
* Use exclude instead of includeHiroshi SHIBATA2020-03-061-6/+18
|
* spaceHiroshi SHIBATA2020-03-061-1/+1
|
* Move version specified matrix to GitHub ActionsHiroshi SHIBATA2020-03-062-14/+10
|
* Remove trailing whitespaceHiroshi SHIBATA2020-03-061-1/+1
|
* oopsHiroshi SHIBATA2020-03-061-1/+1
|
* Run with BUNDLER_SPEC_SUB_VERSIONHiroshi SHIBATA2020-03-062-22/+2
|
* Removed needless stepHiroshi SHIBATA2020-03-061-1/+0
|
* Run lint on GitHub ActionsHiroshi SHIBATA2020-03-062-4/+25
|
* skip spec:sudoHiroshi SHIBATA2020-03-061-3/+3
|
* debugHiroshi SHIBATA2020-03-061-3/+3
|
* move spec:parallel_deps with parallel_rspecHiroshi SHIBATA2020-03-061-2/+3
|
* USe matrix with RGVHiroshi SHIBATA2020-03-061-0/+3
|
* Try to migrate GitHub Actions from Travis CIHiroshi SHIBATA2020-03-061-0/+35
|
* Merge #7665Bundlerbot2020-03-052-8/+18
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7665: Fix sudo specs environment r=hsbt a=deivid-rodriguez ### What was the end-user or developer problem that led to this PR? The developer problem is that sudo specs are not correctly setting the environment (except for ruby 2.3). The specs are accidentally passing but you can tell that they are running against the system ruby by the [warning messages they print](https://travis-ci.org/rubygems/bundler/jobs/658272719#L531-L558). This causes problems when migrating to github actions. See https://github.com/rubygems/bundler/pull/7660#discussion_r385616844. Another problem is that the environment is setup manually outside of `rake spec:sudo`, so there's no easy way of running sudo specs manually if your system does not have the right sudoers configuration. ### What is your fix for the problem, implemented in this PR? My fix is to properly set sudo configuration to preserve the environment so that the correct ruby can be found by sudo specs, and also to move the logic inside `rake spec:sudo` so that the specs can easily be run manually without side effects. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Restore sudo configuration after sudo specsfix_sudo_specs_envDavid Rodríguez2020-03-041-4/+7
| |
| * Move sudo specs setup to `rake spec:sudo`David Rodríguez2020-03-042-5/+15
| |
| * Move sudoers confguration together with sudo specsDavid Rodríguez2020-03-041-1/+1
| |
| * Fix environment for "sudo specs"David Rodríguez2020-03-041-4/+2
| | | | | | | | | | | | | | | | | | | | | | Previously, sudo specs were running against system ruby, not against RVM ruby. We need to make sure `sudo` is always configured to preserve the path the `ruby`. This was previously done only for ruby 2.3, but needs to be done everywhere to ensure that the specs run against the correct ruby. Together with this change, I added a bare test to make sure that "sudo specs" run against the correct ruby.
| * Remove unnecessary lineDavid Rodríguez2020-03-041-1/+0
| |
* | Merge #7661Bundlerbot2020-03-041-99/+44
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7661: Revise CoC based on Contributor Covenant 2.0 r=deivid-rodriguez a=indirect Bundler has had a code of conduct since before the Contributor Covenant was available as an option. In my (admittedly somewhat vague) memory, we continued to use our own custom CoC based on wanting clear enforcement examples directly in the CoC. The Contributor Covenant now contains enforcement examples as of 2.0, so I am proposing that we migrate Bundler's CoC to CC 2.0. Additional benefits: - Merging with RubyGems gets easier, since RubyGems uses CC already (rubygems/rubygems#3157). - The `bundle gem` template and Bundler itself will now use the same CoC. Co-authored-by: André Arko <andre@arko.net>
| * | Revise CoC based on Contributor Covenant 2.0indirect/contributor-covenantAndré Arko2020-02-271-99/+44
| | | | | | | | | | | | | | | | | | | | | Bundler has had a code of conduct since before the Contributor Covenant was available as an option. In my (admittedly somewhat vague) memory, we continued to use our own custom CoC based on wanting clear enforcement examples directly in the CoC. The Contributor Covenant now contains enforcement examples as of 2.0, so I am proposing that we migrate Bundler's CoC to CC 2.0. Additional benefits: - Merging with RubyGems gets easier, since RubyGems uses CC already (rubygems/rubygems#3157). - The `bundle gem` template and Bundler itself will now use the same CoC.
* | | Merge #7663Bundlerbot2020-03-041-3/+2
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7663: Reformulation of changes after bundler 2.1 has been released r=deivid-rodriguez a=jesperronn ### What was the end-user or developer problem that led to this PR? Upgrading document talks about bundler 2.1 in future tense, but it has already been released. ### What is your fix for the problem, implemented in this PR? Update text to reflect the deprecation texts are already added in version 2.1, and that version 2.1 has already been released Co-authored-by: Jesper Rønn-Jensen <jesperrr@gmail.com>
| * | Reformulation of changes after bundler 2.1 has been releasedJesper Rønn-Jensen2020-03-021-3/+2
| | | | | | | | | Update text to reflect the deprecation texts are already added in version 2.1, and that version 2.1 has already been released
* | | Merge #7664Bundlerbot2020-03-0450-50/+50
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7664: Bump man pages month r=deivid-rodriguez a=deivid-rodriguez <!-- Thanks so much for the contribution! If you're updating documentation, make sure you run `bin/rake man:build` and squash the result into your changes, so that all documentation formats are updated. To make reviewing this PR a bit easier, please fill out answers to the following questions. --> ### What was the end-user or developer problem that led to this PR? CI fails when man pages month gets out of date. ### What is your fix for the problem, implemented in this PR? My fix is to update the month in the man pages to the current one. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Bump man pages monthbump_man_pagesDavid Rodríguez2020-03-0450-50/+50
|/ /
* | Merge #7580Bundlerbot2020-02-279-49/+32
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7580: Automultiplatform again r=indirect a=deivid-rodriguez This PR is a reintroduction of #7215, now that I consider the multiplatform feature usable enough. ### What was the end-user problem that led to this PR? The problem was that currently if the gemfile include gems for specific platforms, like the default `gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]` Rails uses, bundler will always print a noisy warning, but I don't think users are doing anything wrong, just running `bundle install` on it. Also, unless they run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`, and commit the resulting lockfile, they will continue to get the same warning over and over again. ### What was your diagnosis of the problem? My diagnosis is that the fact that some gems will be unused under some platforms is inherent to the multiplatform feature itself, so we shouldn't warn about it because it's expected. Take the following Gemfile for example (a simplification of the default Gemfile Rails generators create): ```ruby source "https://rubygems.org" gem "rails" gem "tzinfo-data", platforms: "jruby" ``` If I type that Gemfile, it means that I'm explicitly opting into the multiplatform feature. So the behavior I would want as a user when I run `bundle install` on it is: * Resolve and lock the Gemfile for all platforms (`jruby` and whatever platform I'm running). * Install the resolution for the platform that I'm currently running. That way, when the other developers of my team using `jruby` install the `Gemfile`, they install a predictable, deterministic resolution. Currently, the only way to get that behavior is to run: ``` $ bundle install $ bundle lock --add-platform java ``` But there's no way to do it without getting a warning on the first `bundle install`, which annoys people because it makes you think you're doing something wrong. If you only plan to use MRI, you shouldn't specify any jruby-specific gems in your Gemfile and write instead: ```ruby source "https://rubygems.org" gem "rails" ``` If on the other hand you only plan to use jruby, then you should not specify any `platform` option at all and write ```ruby source "https://rubygems.org" gem "rails" gem "tzinfo-data" ``` So, to sum up, I think the range of platforms users expect to support can be guessed implicit from the Gemfile and the running platform. So we should resolve by default for all those platforms and don't warn about behavior that's most likely expected. ### What is your fix for the problem, implemented in this PR? My fix is to do the right thing by default, and not warn users at all. That is: * Resolve the gemfile and lock it for all platforms present in the Gemfile. * Install gems for the current platform if requested. ### Why did you choose this fix out of the possible options? I chose this fix because I think it's better for our users. We currently have a specific setting to avoid this warning, which I guess we added given the complaints. We no longer need that setting, nor the warning, so I removed both. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Revert "Revert "Remove now unused method""automultiplatform_againDavid Rodríguez2020-02-271-4/+0
| | | | | | | | | | | | This reverts commit 13cef81582858af9509726f3a24a817cf029ad9b.
View Lorry Controller Status