[ci] only use conda-forge when installing R packages in docs builds

[jameslamb]

For #3946, I'm experimenting with adding {rmarkdown} and {knitr} explicitly to the conda environment used in readthedocs builds (currently they are included implicitly by installing {pkgdown}).

While doing this, I've been testing locally by running the following.

docker run -it continuumio/miniconda3 /bin/bash

conda create \
    -q \
    -y \
    -c conda-forge \
    -n r_env \
        r-base=4.1.0=hb67fd72_2 \
        r-data.table=1.14.0=r41hcfec24a_0 \
        r-jsonlite=1.7.2=r41hcfec24a_0 \
        r-matrix=1.3_4=r41he454529_0 \
        r-pkgdown=1.6.1=r41hc72bb7e_0 \
        r-roxygen2=7.1.1=r41h03ef668_0

From

LightGBM/docs/conf.py

Lines 267 to 277 in 1d0d746

	/home/docs/.conda/bin/conda create \
	-q \
	-y \
	-c conda-forge \
	-n r_env \
	r-base=4.1.0=hb67fd72_2 \
	r-data.table=1.14.0=r41hcfec24a_0 \
	r-jsonlite=1.7.2=r41hcfec24a_0 \
	r-matrix=1.3_4=r41he454529_0 \
	r-pkgdown=1.6.1=r41hc72bb7e_0 \
	r-roxygen2=7.1.1=r41h03ef668_0

I found that environment solves were taking a long time, and remembered that mixing the default channels and conda-forge can lead to longer solve times:

• [ci] prevent getting incompatible dask and distributed versions #4054 (review)
• [package request] r-pkgdown ContinuumIO/anaconda-issues#11604 (comment)

This PR proposes adding --override-channels to the conda create call used to install dependencies on RTD. Per conda create --help.

--override-channels Do not search default or .condarc channels. Requires --channel.

In local testing, I found that adding this argument did lead to noticably faster solves. Running the conda create statement used in this project's RTD builds took 4m59s without that argument and 3m5s with it! Given that, I'm optimistic it'll lead to faster builds on RTD 😎

how I tested timings (click me)

# pull miniconda image so image-pulling doesn't add to timings
docker pull continuumio/miniconda3

# mixing conda-forge and anaconda default channels
time \
    docker run --rm -it continuumio/miniconda3 \
    conda create \
        -q \
        -y \
        -c conda-forge \
        -n r_env \
            r-base=4.1.0=hb67fd72_2 \
            r-data.table=1.14.0=r41hcfec24a_0 \
            r-jsonlite=1.7.2=r41hcfec24a_0 \
            r-matrix=1.3_4=r41he454529_0 \
            r-pkgdown=1.6.1=r41hc72bb7e_0 \
            r-roxygen2=7.1.1=r41h03ef668_0

# real 4m59.236s
# user 0m0.179s
# sys  0m0.247s

# only conda-forge
time \
    docker run --rm -it continuumio/miniconda3 \
    conda create \
        -q \
        -y \
        -c conda-forge \
        --override-channels \
        -n r_env \
            r-base=4.1.0=hb67fd72_2 \
            r-data.table=1.14.0=r41hcfec24a_0 \
            r-jsonlite=1.7.2=r41hcfec24a_0 \
            r-matrix=1.3_4=r41he454529_0 \
            r-pkgdown=1.6.1=r41hc72bb7e_0 \
            r-roxygen2=7.1.1=r41h03ef668_0

# real 3m5.042s
# user 0m0.173s
# sys  0m0.292s

Notes for Reviewers

@StrikerRUS could you temporarily enable this branch at https://readthedocs.org/projects/lightgbm/versions/ so we could test?

[StrikerRUS]

could you temporarily enable this branch

Sure, done! Made it hidden (accessible via a direct link only) to not confuse RTD readers with dev branches listed in the version selection widget.
https://readthedocs.org/projects/lightgbm/builds/15182764/

[StrikerRUS]

New build for this PR:

Build took 459 seconds

Some last builds for master branch:

Build took 514 seconds

Build took 507 seconds

Build took 495 seconds

Build took 481 seconds

Build took 490 seconds

Build took 505 seconds

Build took 483 seconds

[StrikerRUS]

Speedup is not so good as your local one 🙁
Will re-trigger one more time.

UPD:

Build took 476 seconds

By the way, it is possible to test our guesses with RTD Docker image, not with continuumio/miniconda3.
https://github.com/readthedocs/readthedocs-docker-images

[jameslamb]

By the way, it is possible to test our guesses with RTD Docker image, not with continuumio/miniconda

Oh thanks, didn't know about that!

Speedup is not so good as your local one

Yeah, sad! It still seems a little bit faster (both runs from this branch are faster than the fastest of the 7 most recent runs on master), so I think this change could still be helpful.

[StrikerRUS]

I think this change could still be helpful.

Yeah, maybe.

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