Repository navigation
bundle install fails on windows-latest after using bundle config #13
Description
Activity
In contrast, passing options directly to
bundle installworks fine:bundle --path .bundle/gemsHowever, that results in warnings about using persistent flags with
bundle install.Could you link to a log failing because of this? And/or share a workflow triggering it?
There's literally nothing in the log. You can find a workflow example here: https://github.com/asciidoctor/asciidoctor-pdf/blob/master/.github/workflows/ci.yml#L21 (I'm currently messing with it, so I could be changing).
2020-01-30T11:23:35.9402420Z Running `bundle install --jobs 3 --retry 3 --verbose` with bundler 2.1.4 2020-01-30T11:23:36.4473629Z Fetching https://github.com/prawnpdf/prawn-table.git 2020-01-30T11:23:39.8952804Z NOTE: Gem::Specification#rubyforge_project= is deprecated with no replacement. It will be removed on or after 2019-12-01. 2020-01-30T11:23:39.9130110Z ##[error]Process completed with exit code 1. 2020-01-30T11:23:39.9155841Z Cleaning up orphan processesSo the process is just dying.
This may or may not having anything to do with this action. I really have no idea because it's giving absolutely no information when it dies. Maybe that's GitHub Actions suppressing the output. Maybe that's Windows. If this issue only serves as a warning to others not to use
bundle configon Windows runners, I would be okay with that. We can only fix what we can fix.For completeness, here are the warnings we get when using flags instead of
bundle config.[DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set path '.bundle/gems'`, and stop using this flag [DEPRECATED] The `--without` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set without 'docs lint coverage'`, and stop using this flagAs long as the error doesn't happen during the
uses: eregon/use-ruby-action@v1step, I think it is unlikely it has anything to do with this action.
An easy way to make sure would be to use https://github.com/actions/setup-ruby and see if it fails too.BTW, could you use
eregon/use-ruby-action@v1and noteregon/use-ruby-action@v1.10.0as recommended in the README? That way you'll get bug fixes, and old releases are not guaranteed to work.I'm currently messing with it, so I could be changing
ycan be used to point to a specific version of a file in GitHubA link to a log would help me understand better.
I found https://github.com/asciidoctor/asciidoctor-pdf/runs/416999064?check_suite_focus=true
That seems clearly a bug of either GHA or Bundler 2.I would recommend to not install bundler explicitly, unless you really need a specific version. This action already provides a version of bundle for all Rubies (see https://github.com/eregon/use-ruby-action#bundler).
That way you'll get bug fixes, and old releases are not guaranteed to work.
Oh, I didn't know that it works that way.
@slonopotamus That's documented in https://github.com/eregon/use-ruby-action#versioning
Reacted by Marat RadchenkoI'll have a look at this later today. I tried the following locally with ruby master on Windows:
PS C:\Greg\GitHub\asciidoctor-pdf> bundle config --local path .bundle/gems PS C:\Greg\GitHub\asciidoctor-pdf> bundle config --local without docs lint coverage PS C:\Greg\GitHub\asciidoctor-pdf> bundle --jobs 3 --retry 3See fix at asciidoctor/asciidoctor-pdf#1531
There's always been some quirky things with PowerShell in CI. How STDERR output is handled is a configurable item. Same with EXIT codes.
Thank you for looking at this @MSP-Greg, it's much appreciated and I had no idea what's going on here. I'll close this issue because I don't think this action can do anything about it, it seems a GitHub Actions/PowerShell issue.
I think it's best to discuss in the PR: asciidoctor/asciidoctor-pdf#1531
Maybe a workaround would be to useshell: bashfor multi-line scripts.
That might be useful as I expect many Ruby developers are more familiar withbashthan PowerShell, and it allows to use a common syntax on all 3 OS.use shell: bash for multi-line scripts
That explodes with JRuby on Windows.
That explodes with JRuby on Windows.
@slonopotamus Can you show an example log where that happens?
BTW, I'm happy to improve the README based on the discussion in the PR.
11 remaining items
I removed the Bash launcher on JRuby, it seems better now.
Reacted by MSP-GregReacted by Patrik RagnarssonUsing separate steps fixes the problem.
https://github.com/mojavelinux/asciidoctor-pdf/actions/runs/33167078
I see no warnings though, which is very strange. While we work to pinpoint the cause of the exit 1, perhaps recommending using separate steps is a reasonable tradeoff until then.
In that run, the existing Bundler is used, which might change something, but probably not.
It seems far more likely the problem is indeed PowerShell with multiple lines.The full warning is:
Fetching https://github.com/prawnpdf/prawn-table.git NOTE: Gem::Specification#rubyforge_project= is deprecated with no replacement. It will be removed on or after 2019-12-01. Gem::Specification#rubyforge_project= called from D:/a/asciidoctor-pdf/asciidoctor-pdf/.bundle/gems/ruby/2.7.0/bundler/gems/prawn-table-515f2db29486/prawn-table.gemspec:19.And in https://github.com/asciidoctor/asciidoctor-pdf/runs/416845301 it's cut after the first warning line:
Fetching https://github.com/prawnpdf/prawn-table.git NOTE: Gem::Specification#rubyforge_project= is deprecated with no replacement. It will be removed on or after 2019-12-01.So it really seems PowerShell just aborts on STDERR output, for multi-line scripts, as @MSP-Greg said.
I think this would be highly valuable to report to GitHub Actions as a bug when using PowerShell with multiple lines. Could you report it?
Thanks for that assessment, @eregon. That seems to be it!
I agree, this should go upstream. I'm not very familiar with the GitHub Actions project. Do you know where it should be filed?
I just tried the following in a step, and it passed:
- name: ruby test run: | ruby -e "STDERR.puts 'Causes PS exit?'" ruby -vI think https://github.community/t5/GitHub-Actions/bd-p/actions is a good place to report it.
A bit of searching led me to
https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference
And$ErrorActionPreference = 'stop'is according to https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_preference_variables?view=powershell-7#erroractionpreference:Determines how PowerShell responds to a non-terminating error, an error that doesn't stop the cmdlet processing. For example, at the command line or in a script, cmdlet, or provider, such as the errors generated by the Write-Error cmdlet.
You can use a cmdlet's ErrorAction common parameter to override the preference for a specific command.
The valid values are as follows:
...
Stop: Displays the error message and stops executing.And "the Write-Error cmdlet" seems similar as writing to STDERR.
Sounds related at least.In that run, the existing Bundler is used, which might change something, but probably not.
Nope, it didn't change anything. It works either way when I use separate steps.
I can reproduce the failure in GitHub Actions with:
https://github.com/eregon/use-ruby-action/runs/418285035?check_suite_focus=true- name: Test run: | gem install bundler bundle config --local path .bundle/gems ruby -e 'STDERR.puts %{NOTE: warning}; STDERR.puts 42' echo after
Removing the
bundle configmakes it pass:
https://github.com/eregon/use-ruby-action/runs/418285586?check_suite_focus=true- name: Test run: | gem install bundler ruby -e 'STDERR.puts %{NOTE: warning}; STDERR.puts 42' echo after
Not installing latest bundler also passes:
https://github.com/eregon/use-ruby-action/runs/418287337?check_suite_focus=true- name: Test run: | bundle config --local path .bundle/gems ruby -e 'STDERR.puts %{NOTE: warning}; STDERR.puts 42' echo after
Installing latest bundler and
bundle configbut no STDERR print passes too:
https://github.com/eregon/use-ruby-action/runs/418294467?check_suite_focus=true- name: Test run: | gem install bundler bundle config --local path .bundle/gems echo after
So somehow
gem install bundler+bundle config --local path .bundle/gems+ STDERR output cause the failure? Maybe recent Bundler does something strange to the shell?What version (Bundler or Ruby) passed? I'll check this locally...
I'm not sure what's wrong here, but I already spent too much time debugging weird Windows shell bugs.
Please report the issue to GitHub Actions, for example at https://github.community/t5/GitHub-Actions/bd-p/actionsThis is clearly not a bug of this action.
As far as I'm concerned, this is a solved issue either by:
- Using a separate step or
- Setting
$ErrorActionPreference = 'Continue'
It's just not a hill I want to die on trying to solve otherwise.
If I use
bundle configto set bundler options (e.g.,bundle config --local without docs), the subsequent call tobundle installfails. The action gives no reason why it failed.This does not happen on ubuntu-latest.