search

actions / runner-images

GitHub Actions runner images
MIT License
10.27k stars 3.09k forks source link

Ruby `gem install ronn` fails on Windows Server 2022 #5100

Closed chrisd8088 closed 2 years ago

chrisd8088 commented 2 years ago

Description

In our Windows CI build job for the Git LFS project, we have a step which installs the ronn Ruby gem (https://github.com/rtomayko/ronn) with gem install ronn. This succeeds on a Windows Server 2019 Actions runner, but fails on a Windows Server 2022 runner, due to a what seems to be a C library or header problem. The specific failure is outlined in the "Actual behavior" section below.

Virtual environments affected

Image version and build link

Environment: windows-2022 Version: 20220207.1 Failed build: https://github.com/chrisd8088/git-lfs/runs/5236350328?check_suite_focus=true

Is it regression?

This is a regression from Windows Server 2019.

Environment: windows-2019 Version: 20220131.1 Successful build: https://github.com/chrisd8088/git-lfs/runs/5236480511?check_suite_focus=true

Expected behavior

We expect the Ruby gem to install cleanly and successfully, as it does with Windows Server 2019:

▶ Run gem install ronn
  gem install ronn
  shell: C:\Program Files\Git\bin\bash.EXE --noprofile --norc -e -o pipefail {0}
Successfully installed mustache-1.1.1
Temporarily enhancing PATH for MSYS/MINGW...
Building native extensions. This could take a while...
Successfully installed rdiscount-2.2.0.2
Building native extensions. This could take a while...
Successfully installed hpricot-0.8.6
Successfully installed ronn-0.7.3
Parsing documentation for mustache-1.1.1
Installing ri documentation for mustache-1.1.1
Parsing documentation for rdiscount-2.2.0.2
Installing ri documentation for rdiscount-2.2.0.2
Parsing documentation for hpricot-0.8.6
Installing ri documentation for hpricot-0.8.6
Parsing documentation for ronn-0.7.3
Installing ri documentation for ronn-0.7.3
Done installing documentation for mustache, rdiscount, hpricot, ronn after 5 seconds
4 gems installed

Actual behavior

The build failure output is as follows; it appears that the key issue may be a failure to build a small C test program used to check the system configuration during the build process. The result is perhaps a failure to run the test program and check its return value.

▶ Run gem install ronn
ERROR:  Error installing ronn:
    ERROR: Failed to build gem native extension.
Temporarily enhancing PATH for MSYS/MINGW...
Building native extensions. This could take a while...

    current directory: C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/gems/3.0.0/gems/rdiscount-2.2.0.2/ext
C:/hostedtoolcache/windows/Ruby/3.0.3/x64/bin/ruby.exe -I C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0 -r ./siteconf20220217-1960-zhwi49.rb extconf.rb
checking for random()... no
checking for srandom()... no
checking for rand()... yes
checking for srand()... yes
checking size of unsigned long... *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
    --with-opt-dir
    --without-opt-dir
    --with-opt-include
    --without-opt-include=${opt-dir}/include
    --with-opt-lib
    --without-opt-lib=${opt-dir}/lib
    --with-make-prog
    --without-make-prog
    --srcdir=.
    --curdir
    --ruby=C:/hostedtoolcache/windows/Ruby/3.0.3/x64/bin/$(RUBY_BASE_NAME)
    --with-rdiscount-dir
    --without-rdiscount-dir
    --with-rdiscount-include
    --without-rdiscount-include=${rdiscount-dir}/include
    --with-rdiscount-lib
    --without-rdiscount-lib=${rdiscount-dir}/lib
C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:755:in `Integer': can't convert nil into Integer (TypeError)
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:755:in `block in try_constant'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:419:in `popen'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:419:in `block in xpopen'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:331:in `open'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:412:in `xpopen'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:754:in `try_constant'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:1366:in `block in check_sizeof'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:971:in `block in checking_for'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:361:in `block (2 levels) in postpone'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:331:in `open'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:361:in `block in postpone'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:331:in `open'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:357:in `postpone'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:970:in `checking_for'
    from C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/3.0.0/mkmf.rb:1365:in `check_sizeof'
    from extconf.rb:11:in `block in sized_int'
    from extconf.rb:11:in `each'
    from extconf.rb:11:in `find'
    from extconf.rb:11:in `sized_int'
    from extconf.rb:15:in `<main>'

To see why this extension failed to compile, please check the mkmf.log which can be found here:

  C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/gems/3.0.0/extensions/x64-mingw32/3.0.0/rdiscount-2.2.0.2/mkmf.log

extconf failed, exit code 1

Gem files will remain installed in C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/gems/3.0.0/gems/rdiscount-2.2.0.2 for inspection.
Results logged to C:/hostedtoolcache/windows/Ruby/3.0.3/x64/lib/ruby/gems/3.0.0/extensions/x64-mingw32/3.0.0/rdiscount-2.2.0.2/gem_make.out
Error: Process completed with exit code 1.

Repro steps

  1. An Actions workflow which runs gem install ronn on a Windows Server 2022 runner, e.g.:

    name: CI
on: [push, pull_request]

jobs:
  build-windows:
    name: Build on Windows
    runs-on: windows-2022
    steps:
    - run: gem install ronn
      shell: bash

  2. Note that the same workflow but with runs-on: windows-2019 succeeds.

  3. Also note that while our legacy CI job for the Git LFS project first runs the now-deprecated actions/setup-ruby@v1 action, the problem can be seen without that step, as per the reproduction workflow script above.

chrisd8088 commented 2 years ago

A few further notes:

al-cheb commented 2 years ago

Hello @chrisd8088 , We will take a look at it.

chrisd8088 commented 2 years ago

Thanks, @al-cheb! I've added another few notes in the comment above; in particular, I wrote up the problems with ruby/setup-ruby@v1 and Bash and PATH in ruby/setup-ruby#293, and created some small workflows to demonstrate that problem.

If that were fixed first, we could work around this issue by running ruby/setup-ruby@v1, which then allows gem install ronn to succeed. But for the moment that workaround is not possible for us, due to the problems with PATH, so if there's a more direct way to get gem install ronn to work just with the system default Ruby installation, that would be awesome.

Thanks very much for taking a look at this; it's much appreciated! ❤️

mikhailkoliada commented 2 years ago

@chrisd8088 hello!

the failure happens just because we are having different versions of ruby be default on win19 and win22 (2.5 and 3.0 respectively). setup-ruby indeed helps mitigating this, but given that you can't use it at the moment the most suitable workarond for you would be changing the default $PATH value and put there a ruby version you wish, say, by executing the same function as we do in your pipeline's runtime.

chrisd8088 commented 2 years ago

Thanks for the advice and info, @mikhailkoliada! That's helped us formulate an alternative approach; I suspect we will stop using ronn altogether and replace it with either Pandoc or Asciidoctor. It'll be a bit more work on our end but as ronn appears to be unmaintained at this point, I think this is probably the right direction. Thanks again!