[ci] [R-package] use R 4.2.1 in Windows CI jobs (fixes #4881)

[jameslamb]

Fixes #4881.
Replaces #5274.

Changes in this PR

• upgrade from R 4.1.3 to R 4.2.1 in Windows CI jobs
• upgrade from Rtools40 to Rtools42 in Windows CI jobs
• explicitly pass version parsed from VERSION.txt into test_r_package_windows.ps1 (instead of relying on wildcards like lightgbm_*.tar.gz
• extend "skip one test when compiling with MSVC" fix from [ci] [R-package] ensure that MSVC jobs fail when tests fail (fixes #5439) #5448 to all MSVC jobs

Why did the check in configure.win need to change?

Compiling the test program used to check for inet_pton with the compiler that ships with RTools42 (gcc 10.3), results in the following error.

conftest.cpp: In function 'int main()':
conftest.cpp:3:13: error: invalid conversion from 'INT (*)(INT, LPCSTR, PVOID)' {aka 'int (*)(int, const char*, void*)'} to 'void*' [-fpermissive]
    3 |   void* p = inet_pton;
      |             ^~~~~~~~~
      |             |
      |             INT (*)(INT, LPCSTR, PVOID) {aka int (*)(int, const char*, void*)}

To avoid that casting, this PR proposes just assigning the address of inet_pton to a function pointer for a function with exactly the same signature as the one LightGBM's code expects.

Why does the use of "lightgbm_*.tar.gz" need to be replaced with "lightgbm_$env:LGB_VER.tar.gz"?

I'm not sure...probably related to R or some tool shipping with RTools42 not working well with wildcards. While testing in #4881, I saw errors like the following:

Error: no packages were specified

Notes for Reviewers

#4881 refers to creating a comment-triggered workflow for the UCRT toolchain for Windows builds, but I don't think that's necessary any more now that R 4.2.0 has actually been released and Rtools42 contains the UCRT build tools.

I closed #4881 in favor of this because that PR was getting very busy with debugging commits and comments.

References

There is some documentation about Rtools42 adding its own compilers to PATH, but I think that just means to R's PATH (referenced by R CMD commands).

e.g., see https://cran.r-project.org/bin/windows/base/howto-R-4.2.html

To make the use of Rtools42 simpler, when R is installed via the binary installer it by default uses Rtools42 for the compilers and libraries. PATH will be set by R (inside front-ends like RGui and RTerm, but also R CMD) to include the build tools (e.g. make) and the compilers (e.g. gcc). In addition, R installed via the binary installer will automatically set R_TOOLS_SOFT (and LOCAL_SOFT for backwards compatibility) to the Rtools42 location for building R packages. This feature is only present in the installer builds of R, not when R is installed from source.

and r-lib/actions#574 (comment)

Some additional relevant information in the r-lib/actions project:

• r-lib/actions@7d98418
• https://github.com/r-lib/actions/blob/8e8f7edba0e5bda9318f9377c0dc9c2f5d0fb786/setup-r/src/installer.ts#L431-L457

How I tested this

Given the changes to configure.win, I also tested the project on R Hub and win-builder.

Generated the CRAN source distribution like this:

sh build-cran-package.sh

Then used that .tar.gz to test on win-builder and R Hub.

passing on win-builder (click me)

• ✅ R-release (logs)
• ✅ R-devel (logs)
• ✅ R-oldrelease (logs)

See https://win-builder.r-project.org/. This project is run by some of the CRAN maintainers, and very closely matches the Windows builds on CRAN.

There are functions in {devtools} to automate uploading to this service, e.g. devtools::check_win_release(). Unfortunately, those only take a director to be packaged with R CMD build. That doesn't work with the custom stuff build-cran-package.sh has to do to build vignettes:

LightGBM/build-cran-package.sh

Line 206 in dc4794b

# Object files are left behind from compiling the library to generate vignettes.

So I manually changed the maintainer to myself in DESCRIPTION, built the package with build-cran-package.sh, then uploaded manually at https://win-builder.r-project.org/upload.aspx.

passing on R Hub (click me)

I tried checking the package built from this branch on all 4 platforms supported by R Hub.

• ✅ windows-x86_64-devel (logs)
• ✅ windows-x86_64-oldrel (logs)
• ✅ windows-x86_64-patched (logs)
• ✅ windows-x86_64-release (logs)

EMAIL <- "****" # my personal email
PACKAGE_TARBALL <- "lightgbm_3.3.2.99.tar.gz"

result <- rhub::check(
    path = PACKAGE_TARBALL
    , email = EMAIL
    , check_args = c(
        "--as-cran"
    )
    , platforms = c(
        "windows-x86_64-devel"
        , "windows-x86_64-oldrel"
        , "windows-x86_64-patched"
        , "windows-x86_64-release"
    )
    , env_vars = c(
        "R_COMPILE_AND_INSTALL_PACKAGES" = "always"
        , "_R_CHECK_FORCE_SUGGESTS_" = "true"
        , "_R_CHECK_CRAN_INCOMING_USE_ASPELL_" = "true"
    )
)

[jmoralez]

I'm approving to unblock but I'm not the best person to review this. Hopefully someone else can provide their review.

[jameslamb]

Thanks for much for that honesty, @jmoralez , much appreciated!

I agree, it would have been better to have @guolinke or @shiyu1994 review this. Normally I'd wait for one of them, but since #5525 is so time-sensitive, I'm going to merge this to unblock testing there.

These changes will make it into that PR so they'll have another chance to review there, and I think all of the extra testing with win-builder and R Hub there will be give us high confidence that this is working (or catch any issues with it 😬 ).

[guolinke]

@jameslamb no problems, this PR looks good to me.

[jameslamb]

ok thank you!

[github-actions]

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.