[ci] Add debian-clang-devel CI job for the R package

[jameslamb]

The R package failed on CRAN check on its most recent submission (documented in #4105).

This PR proposes a CI job that attempts to replicate that environment, so that similar problems can be caught before submitting to CRAN in the future.

Following the suggestion in #4105 (comment), this tries to replicate CRAN's r-devel-linux-x86_64-debian-clang test, using the same container image that R Hub uses for that purpose.

[jameslamb]

I was able to replicate the error from CRAN locally with this approach.

Pushing now to see if it's replicated on GitHub Actions as well. If it is, then I'll add another commit to try to actually patch the test so it will pass.

[jameslamb]

Seems like this check is working! CUDA jobs are failing for probably-unrelated reasons (#4158 (comment)), but I can see that that new debian-clang-devel job failed with exactly the same error as seen on CRAN.

https://github.com/microsoft/LightGBM/pull/4164/checks?check_run_id=2275252015

[jameslamb]

@StrikerRUS I received an email from Guolin yesterday. CRAN is asking us fix this problem and re-submit.

Dear maintainer,

Please see the problems shown on
https://cran.r-project.org/web/checks/check_results_lightgbm.html.

Apparently your package fails its checks in a strict Latin-1* locale,
e.g. under Linux using LANG=en_US.iso88591 (see the debian-clang
results).

Please correct before 2021-04-21 to safely retain your package on CRAN.

Best,
-k

I think it's very important that {lightgbm} not get kicked off of CRAN even for a day, as that would break any users' automation that relies on installing {lightgbm} from CRAN.

I'll update this PR to make sure the package passes tests on r-devel-linux-x86_64-debian-clang.

@StrikerRUS which of these options would you prefer? I'm ok with whichever one you want, so we can come to a quick resolution well before April 21.

1. Submit the R package to CRAN as version 3.2.0.1 (this idea was rejected in [RFC] version changes + more frequent releases #3210 but we could consider this a special case)
2. Do a 3.2.1 release of all of LightGBM

[StrikerRUS]

@jameslamb I'd prefer variant 2. Luckly, we haven't merged any breaking changes that doesn't fit for minor release into master yet.

[jameslamb]

@jameslamb I'd prefer variant 2. Luckly, we haven't merged any breaking changes that doesn't fit for minor release into master yet.

ok sounds good! I'll get this PR working today, and I'll open a separate PR for the release with the usual release checklist.

[jameslamb]

/gha run r-solaris

Workflow Solaris CRAN check has been triggered! 🚀
https://github.com/microsoft/LightGBM/actions/runs/734409844

solaris-x86-patched: https://builder.r-hub.io/status/lightgbm_3.2.0.99.tar.gz-c7db3e53db4e4344bf08bf7f18b4af43
solaris-x86-patched-ods: https://builder.r-hub.io/status/lightgbm_3.2.0.99.tar.gz-b1123d0e5c734026ba562be06f63df8a
Reports also have been sent to LightGBM public e-mail: http://www.yopmail.com/lightgbm_rhub_checks
Status: success ✔️.

[jameslamb]

Ok I think the debian check will pass now!

[jameslamb]

Ok I've updated this with all the blocking CI fixes that are now on master (#4161, #4167, #4168, #4158), so hopefully now it should be ready for a normal review with no need to use any admin privileges.

[StrikerRUS]

I've pushed empty commit with the aim to re-run CI and not overwrite important logs for Dask ranker error at the same time.

[StrikerRUS]

👍

[StrikerRUS]

Thanks a lot for improving testing CRAN environment coverage!

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