summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* | | | Merge #7011Bundlerbot2019-03-043-8/+8
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7011: Do not prepend ENV vars for sys_exec calls, but use env param of Open3.popen3 r=deivid-rodriguez a=janpio ### What was the end-user problem that led to this PR? Several tests were failing on Windows because of the same problem: ### What was your diagnosis of the problem? On macOS and Linux you can prepend `ENV_VAR=value` in front of a command to set an environment variable for just this command execution. On Windows this construct doesn't exit and such a command fails. ### What is your fix for the problem, implemented in this PR? `Open3.popen3`, the method used to executed the command in `sys_exec`, also has an optional `env` parameter which you can use to supply a hash of environment variables. Instead of prepending on the command itself, the code now uses that parameter for the env variables. (Suggested by @deivid-rodriguez in https://github.com/bundler/bundler/issues/6886#issuecomment-452010623). ### Why did you choose this fix out of the possible options? The parameter of `Open3.popen3` perfectly matches our use case. --- Fixes 35 failing tests on Windows. closes #6886 Co-authored-by: Jan Piotrowski <piotrowski+git@gmail.com>
| * | | | make rubocop happyJan Piotrowski2019-03-032-2/+2
| | | | |
| * | | | fix other sys_exec calls that prepended an env variableJan Piotrowski2019-03-032-2/+2
| | | | |
| * | | | set ENV via Open3.popen3 param in sys_exec instead of via command being executedJan Piotrowski2019-03-031-6/+6
| |/ / /
* | | | Merge #7013Bundlerbot2019-03-043-2/+2
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7013: Move azure-pipeline folder to a hidden folder r=deivid-rodriguez a=colby-swandale ### What was the end-user problem that led to this PR? We have a folder whose purpose is to contain support files for the Azure CI called `azure-pipelines`. The issue is that this folder does not relate to the Bundler development environment and is showing up in `ls` when it doesn't really need to be. ### What is your fix for the problem, implemented in this PR? Move `azure-pipelines` to a hidden folder with the same name Co-authored-by: Colby Swandale <me@colby.fyi>
| * | | | move azure-pipeline folder to a hidden foldercolby/azure-pipeline-hiddenColby Swandale2019-03-043-2/+2
| | | | |
* | | | | Merge #7015Bundlerbot2019-03-041-1/+1
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7015: Expand comparison path for Windows compat r=deivid-rodriguez a=janpio ### What was the end-user problem that led to this PR? A specific test (#6890) was failing... ### What was your diagnosis of the problem? ... because the comparison was missing the drive letter on Windows. ### What is your fix for the problem, implemented in this PR? I added expansion of the path that was already present in the implementation but not the test. ### Why did you choose this fix out of the possible options? Makes the test pass and looks right. --- closes #6890 fixes 1 failing test on Windows Co-authored-by: Jan Piotrowski <piotrowski+git@gmail.com>
| * | | | | expand comparison path for Windows compatJan Piotrowski2019-03-031-1/+1
| | |/ / / | |/| | | | | | | | | | | | | which adds a `C:` to the path
* | | | | Merge #7014Bundlerbot2019-03-0411-75/+27
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7014: Fix all offenses of some easy cops r=deivid-rodriguez a=deivid-rodriguez References https://github.com/bundler/bundler/pull/7009/files#r261892716. ### What was the end-user problem that led to this PR? The problem was just some leftover consistency offenses. ### What was your diagnosis of the problem? My diagnosis was that we can easily fix these globally. ### What is your fix for the problem, implemented in this PR? My fix is to enable the three cops and run `rubocop --auto-correct`. ### Why did you choose this fix out of the possible options? I chose this fix because these cops depend on each other, so enabling just one of them leaves weird indented code behind. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | | Auto-correct `Style/TrailingCommaInHashLiteral` offensesglobally_enable_some_layout_copsDavid Rodríguez2019-03-045-17/+6
| | | | | |
| * | | | | Auto-correct `Style/TrailingCommaInArrayLiteral` offensesDavid Rodríguez2019-03-044-13/+3
| | | | | |
| * | | | | Fully enable some dependent Layout copsDavid Rodríguez2019-03-044-45/+18
|/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | These cops leave weird styling if enabled separately, but do what you want if enabled all together. So fix all remaining style issues for them at once.
* | | | | Merge #7010Bundlerbot2019-03-032-5/+5
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7010: Use double quotes for `git commit -m` r=colby-swandale a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that Azure logs are full of "error: pathspec 'COMMIT'' did not match any file(s) known to git." and other similar ones. ### What was your diagnosis of the problem? My diagnosis was that Windows' git doesn't like single quotes. ### What is your fix for the problem, implemented in this PR? My fix is to use double quotes, which is also consistent with our global style. ### Why did you choose this fix out of the possible options? I chose this fix because it brings the number of spec failures on Windows from 657 to 474! :tada: Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Use double quotes for `git commit -m`windows_friendly_gitDavid Rodríguez2019-03-032-5/+5
| |/ / / | | | | | | | | | | | | | | | | Apparently single quotes don't work on Windows, and this also makes our code more consistent.
* | | | Merge #6978Bundlerbot2019-03-032-2/+14
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6978: Add check for already installed plugin r=deivid-rodriguez a=ankitkataria ### What was the end-user problem that led to this PR? Fixes #6946 ### What was your diagnosis of the problem? There was no check to ensure that the plugin was already installed or not. ### What is your fix for the problem, implemented in this PR? I added the check [here](https://github.com/bundler/bundler/compare/master...ankitkataria:plugin-fix?expand=1#diff-68bd939cd3589d8fdda08a12433659ebR109) I also added a small test for the same Co-authored-by: Ankit Kataria <ankitkataria28@gmail.com>
| * | | add check for already installed pluginAnkit Kataria2019-02-212-2/+14
| | | |
* | | | Merge #7004Bundlerbot2019-03-024-74/+358
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7004: Bump rubocop to 0.65.0 r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that running rubocop (to fix style issues in other PRs) prints several warnings in the parser gem. ### What was your diagnosis of the problem? My diagnosis was that we should upgrade rubocop. ### What is your fix for the problem, implemented in this PR? My fix is to upgrade rubocop, fix the config to be compatible with the new version, and regenerate the TODO config. ### Why did you choose this fix out of the possible options? I chose this fix because it does the job. There's still some stuff I don't like about the current "rubocop maintainance" that I've proposed in #7003. But for the current situation I think this works. Closes #6608. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Bump rubocop to 0.65.0David Rodríguez2019-03-014-74/+358
|/ / / | | | | | | | | | Fix config and regenerate TODO config.
* | | Merge #6991Bundlerbot2019-02-284-45/+69
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6991: Fix deprecation specs r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was the current deprecation specs are broken. Not the deprecations themselves, their specs. ### What was your diagnosis of the problem? My diagnosis was we need to fix the specs for the deprecations before actually making sure that the deprecations themselves are properly enabled. ### What is your fix for the problem, implemented in this PR? My fix is to: * Get the target version corrected. Deprecation specs should run on bundler 2, not on bundler 1, since deprecations are disabled on bundler 1. * Get the deprecation matcher fixed. The previous version was passing every time any deprecation was printed and a positive expectation was set. That means that on a spec printing a single deprecation, the assertion `expect(warnings).to have_major_deprecation("bananas will be deprecated in favor of potatoes")`, or any other message, would just pass. This explains why the deprecation specs were currently passing on bundler 1 and it's fixed by https://github.com/bundler/bundler/commit/33383f2faae10cd307b86466921b1a17391bae80. ### Why did you choose this fix out of the possible options? This fix changes the target for the deprecation specs to bundler 2 (https://github.com/bundler/bundler/commit/e54ddb60298036e3a25c95deda6d575d384ff48a) and uses the following strategy to get CI green after that: * If the deprecation is already correct on bundler 2, do nothing, the specs already pass. * If the deprecation is incorrect on bundler 2, but the fix is a no-brainer, fix it here. For example, the `bundle update --all` deprecation (968fe965c), or the `bundle console` deprecation (5bece2f0f). * If the deprecation is incorrect on bundler 2, but fixing it requires a separate discussion, skip the spec for now, and stage the fix for a separate PR. I chose this fix because it keeps this PR simple and focused, while unblocking fixing the rest of the deprecations by at least having correct (although disabled) specs for them. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Split (and skip) specs about multiple source deprecationfix_deprecation_specsDavid Rodríguez2019-02-281-8/+19
| | | | | | | | | | | | | | | | I'll get to this on a separate PR.
| * | | Prefer the `err` helper for checking errorsDavid Rodríguez2019-02-281-15/+15
| | | | | | | | | | | | | | | | The helper already considers the stream errors are printed to.
| * | | Remove now unnecessary filteringDavid Rodríguez2019-02-281-5/+4
| | | | | | | | | | | | | | | | Those deprecation messages are no longer printed.
| * | | Make sure deprecation specs run on bundler 2David Rodríguez2019-02-281-3/+3
| | | | | | | | | | | | | | | | And skip the rest of the broken ones.
| * | | Fix major deprecation matcherDavid Rodríguez2019-02-282-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous logic was broken. Previously, changing the expectation about gems.rb vs Gemfile deprecation to ```ruby expect(warnings).to have_major_deprecation("gems.rb is preferred to chocolate ice-cream") ``` would still pass.
| * | | Adapt `bundle show` deprecation specsDavid Rodríguez2019-02-281-1/+5
| | | |
| * | | Delay `bundle console` removal to bundler 3David Rodríguez2019-02-282-2/+6
| | | |
| * | | Remove unnecessary gems.rb file creationDavid Rodríguez2019-02-281-1/+0
| | | | | | | | | | | | | | | | | | | | Not necessary for the test since the main before block already creates one.
| * | | Delay requiring --all to update everything to bundler 3David Rodríguez2019-02-282-2/+7
| | | | | | | | | | | | | | | | Since we haven't even yet deprecated the old behavior.
| * | | Move some test setups to before blocksDavid Rodríguez2019-02-282-5/+10
| | | |
| * | | Remove unnecessary gsubDavid Rodríguez2019-02-281-2/+0
|/ / /
* | | Merge #6997Bundlerbot2019-02-281-13/+4
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6997: Smaller ci matrix r=colby-swandale a=deivid-rodriguez Fixes #6956. ### What was the end-user problem that led to this PR? The problem was that we have a very slow CI ### What was your diagnosis of the problem? My diagnosis was that the CI matrix is very big, and that old rubies use more resources than new rubies. ### What is your fix for the problem, implemented in this PR? My fix is to remove some entries and when it comes to testing old rubygems version, test only the rubygems version each tested MRI version shipped with. ### Why did you choose this fix out of the possible options? I chose this fix because it saves us some time, and it gives all rubies the same amount of CI resources. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Use rubygems 3.0.2 for testing compatibility modesmaller_ci_matrixDavid Rodríguez2019-02-271-1/+1
| | | |
| * | | Test only the rubygems version each MRI version shipped withDavid Rodríguez2019-02-271-12/+3
|/ / /
* | | Merge #6982Bundlerbot2019-02-2631-186/+64
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6982: Remove unnecessary rubygems filters r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was there's a lot of unnecessary code, specially in specs, that's never run. ### What was your diagnosis of the problem? My diagnosis was that since dropping support for old rubygems versions, this code is no longer necessary. ### What is your fix for the problem, implemented in this PR? My fix is to remove the code. ### Why did you choose this fix out of the possible options? I chose this fix because red is great on diffs. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Remove rubygems compatibility guardremove_unnecessary_rubygems_filtersDavid Rodríguez2019-02-252-13/+0
| | | | | | | | | | | | Bundler 2 can't be installed on these rubygems, so it's not necessary.
| * | Remove more unnecessary rubygems version checksDavid Rodríguez2019-02-255-56/+27
| | |
| * | Remove unnecessary old rubygems deprecationDavid Rodríguez2019-02-252-29/+4
| | |
| * | Remove unnecessary rubygems filters from specsDavid Rodríguez2019-02-2522-88/+33
|/ /
* | Merge #6971Bundlerbot2019-02-243-5/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6971: Fix warning message about bundler version r=colby-swandale a=deivid-rodriguez Fixes #6909. ### What was the end-user problem that led to this PR? The problem was that we're recommending a command to make a warning go away that doesn't really make the warning go away. ### What was your diagnosis of the problem? My diagnosis was that the current recommendation installs the latest bundler, which might not be the same as the version the lock file was created with. If it's not the same, the warning will not go away. ### What is your fix for the problem, implemented in this PR? My fix is to recommend installing exactly the version the lockfile was created with. ### Why did you choose this fix out of the possible options? I chose this fix because it's really simple and it should work. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Fix warning message about bundler versionfix_upgrade_instructionsDavid Rodríguez2019-02-183-5/+9
| | | | | | | | | | | | | | | | | | | | | To actually make the warning go away, we need to recommend exactly installing the locked version. Otherwise the latest version gets installed, but not used to being a different major than the one locked, so the warning stays.
* | | Merge #6983Bundlerbot2019-02-2417-71/+23
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6983: Remove unnecessary ruby filters r=colby-swandale a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was there's a lot of unnecessary code, specially in specs, that's never run. ### What was your diagnosis of the problem? My diagnosis was that since dropping support for old ruby versions, this code is no longer necessary. ### What is your fix for the problem, implemented in this PR? My fix is to remove the code. ### Why did you choose this fix out of the possible options? I chose this fix because red is great on diffs. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Remove unnecessary ruby filters from specsremove_unnecessary_ruby_filtersDavid Rodríguez2019-02-2215-61/+23
| | | |
| * | | Remove ruby version major deprecationDavid Rodríguez2019-02-222-10/+0
| | | | | | | | | | | | | | | | Since the current master will never run those rubies.
* | | | Merge #6984Bundlerbot2019-02-23708-414/+503
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6984: Refresh all VCR cassettes r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was our VCR cassettes contain responses recorded a long time ago, but the real APIs might have changed or give different results since then. ### What was your diagnosis of the problem? My diagnosis was that we should re-record the cassettes every once in a while. ### What is your fix for the problem, implemented in this PR? My fix removes old the previous cassettes and re-records them. ### Why did you choose this fix out of the possible options? I chose this fix because I'm not sure how to do it otherwise. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Refresh all VCR cassettesrefresh_vcr_cassettesDavid Rodríguez2019-02-22708-414/+503
|/ / /
* | | Merge #6965Bundlerbot2019-02-2210-55/+34
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6965: Turn on deprecations by default r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was we've had deprecations in place for a long time, but we've never displayed them to users by default. ### What was your diagnosis of the problem? My diagnosis was that the current strategy doesn't work because: * Printing deprecations as an optin feature almost never get enabled, so most users don't know about the stuff we'll be deprecating in the future. * Printing deprecations in "deprecation releases" doesn't work well either, because it's unclear how long the deprecation release should last and thus how long we need to hold the final release (that will inhibit installation of the deprecation release). ### What is your fix for the problem, implemented in this PR? My fix is to remove the concept of deprecation releases, and to add a feature flag for printing major deprecations that it's enabled by default. As a extra related change, I also reworded the deprecation messages, because I find the current message "[DEPRECATED FOR 2.0] <Message about the deprecation>" a bit confusing because it's unclear what the version printed is referring to (deprecation horizon? current running version?), so I changed it to just "[DEPRECATED] <Message about the deprecation>". ### Why did you choose this fix out of the possible options? I chose this fix because it (once released) finally makes it so that users will know about our deprecations. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Rename major_deprecations to silence_deprecationsdeprecation_changesDavid Rodríguez2019-02-213-6/+6
| | | |
| * | | Remove now redundant configsDavid Rodríguez2019-02-212-5/+0
| | | | | | | | | | | | | | | | Since deprecations are enabled by default.
| * | | Fix deprecations bugDavid Rodríguez2019-02-211-1/+1
| | | | | | | | | | | | | | | | | | | | Deprecations enabled or not, we only want to print deprecations for the running major version, never for future versions.
| * | | Remove major_deprecations feature flagDavid Rodríguez2019-02-213-2/+2
| | | | | | | | | | | | | | | | Leave it as a setting with default true value.
View Lorry Controller Status