bundle install fails on windows-latest after using bundle config

[mojavelinux]

If I use bundle config to set bundler options (e.g., bundle config --local without docs), the subsequent call to bundle install fails. The action gives no reason why it failed.

##[error]Process completed with exit code 1.

This does not happen on ubuntu-latest.

[mojavelinux]

In contrast, passing options directly to bundle install works fine:

bundle --path .bundle/gems

However, that results in warnings about using persistent flags with bundle install.

[eregon]

Could you link to a log failing because of this? And/or share a workflow triggering it?

[mojavelinux]

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).

[mojavelinux]

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 processes

So the process is just dying.

[mojavelinux]

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 config on Windows runners, I would be okay with that. We can only fix what we can fix.

[mojavelinux]

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 flag

[eregon]

As long as the error doesn't happen during the uses: eregon/use-ruby-action@v1 step, 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@v1 and not eregon/use-ruby-action@v1.10.0 as 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

y can be used to point to a specific version of a file in GitHub

A 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).

[slonopotamus]

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.

[eregon]

@slonopotamus That's documented in https://github.com/eregon/use-ruby-action#versioning

[MSP-Greg]

@mojavelinux

I'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 3

See 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.

[eregon]

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 use shell: bash for multi-line scripts.
That might be useful as I expect many Ruby developers are more familiar with bash than PowerShell, and it allows to use a common syntax on all 3 OS.

[slonopotamus]

use shell: bash for multi-line scripts

That explodes with JRuby on Windows.

[eregon]

That explodes with JRuby on Windows.

@slonopotamus Can you show an example log where that happens?