Bioconductor support is broken again

[mjsteinbaugh]

Using the recommended setting of checking against r-devel (thanks @LiNk-NY), Bioconductor 3.9 is now attempting to look for CRAN packages from R 3.7 instead of 3.6, which errors.

matrix:
  - R_VERSION: devel
    GCC_PATH: mingw_64

Error: (converted from warning) unable to access index for repository https://bioconductor.org/packages/3.9/bioc/bin/windows/contrib/3.7:
  cannot open URL 'https://bioconductor.org/packages/3.9/bioc/bin/windows/contrib/3.7/PACKAGES'
Execution halted

Alternatively, unsetting R_VERSION and attempting to check using the current version of R supported on AppVeyor also errors, since Bioconductor 3.9 requires R 3.6.

The downloaded binary packages are in
    C:\Users\appveyor\AppData\Local\Temp\1\RtmpyMBAbJ\downloaded_packages
Error: Bioconductor version '3.9' requires R version '3.6'; see
  https://bioconductor.org/install
Execution halted
Command exited with code 1
7z a failure.zip *.Rcheck\*

How can I fix the config to check against R 3.6 specifically?

[LiNk-NY]

Hi Michael, @mjsteinbaugh You should be able to use:

matrix:
  - R_VERSION: 3.6.0
    GCC_PATH: mingw_64

Best, Marcel

[mjsteinbaugh]

Thanks Marcel this is exactly what I was looking for.

[mjsteinbaugh]

For reference, setting BIOC_USE_DEVEL: "FALSE" (note use of quotes here) currently works more reliably for Bioconductor testing. This method is currently used by my appveyor.yml configuration for basejump.

[LiNk-NY]

@mjsteinbaugh Does that have you test your package with Bioc-release?

The best strategy would be to use Bioc-devel since release is pretty stable and any packages going through development (where CI is most useful) are most likely to be in Bioc-devel...

[mjsteinbaugh]

What I'm trying to do is set up a test matrix that tests against both bioc-release and bioc-devel builds, just like Travis. I'm finding that bioc-release is working on AppVeyor using a combination of R_VERSION: patched and BIOC_USE_DEVEL: "FALSE" but I'm currently running into configuration issues with bioc-devel on AppVeyor, due to r-devel using 3.7 and not all CRAN packages currently being available.

[ahmohamed]

Sorry to comment on a closed issue, but I can't get the suggestion above to work. R_VERSION: 3.6.0 errors because it is trying to download R from https://cloud.r-project.org/bin/windows/base/old/3.6.0/R-3.6.0-win.exe .Somehow r-Appveyor thinks 3.6.0 is an old release. Am I doing something wrong?

Thanks.

[ahmohamed]

Looking at the scripts below, I don't think there is currently a way to get R3.6.0 to work. L91 needs to be modified to check if $version < $release before adding old/ prefix.

https://github.com/krlmlr/r-appveyor/blob/676d9a7ec16492b24e5e2148342ebddaf801b40a/scripts/appveyor-tool.ps1#L71-L92

[mjsteinbaugh]

@ahmohamed You're correct about 3.6.0 not working in the build matrix. Here's my current Bioconductor configuration that works on AppVeyor: appveyor.yml

[ahmohamed]

@mjsteinbaugh Thanks. I saw your config, however it doesn't work for Bioc-devel. I ended up forking the repo and removing the buggy line that adds the old/ prefix. Here is my config (works for Bioc-devel):appveyor.yml

[mjsteinbaugh]

Oh nice! So setting 3.6.0rc seems to work?

[ahmohamed]

No. I also had to get my own forked appveyor-tool.ps1 https://github.com/ahmohamed/lipidr/blob/e9e4e6e3c06cb38797f38eb641dab9a63af6cb29/appveyor.yml#L7

[LiNk-NY]

Hi Ahmed, @ahmohamed You should send in a pull request to update appveyor-tool.ps1 code.

[ahmohamed]

@LiNk-NY This is just a quick and dirty workaround (basically for the next 10 days until R & Bioc3.9 release). The workaround actually breaks testing against old R releases. The correct fix is to actually check R_VERSION against current release version. I will try to send a proper pull request in the future.

[krlmlr]

Thanks for looking into it.

Maybe we should support a named version rc in addition to devel, release, oldrel and patched? The rc would usually be the same as devel, except when it's release time -- then it would map to the release candidate. Would that make sense?

[LiNk-NY]

Yes, that sounds like a good solution :+1:

[ahmohamed]

This would be a good solution. It would be great if the underlying bug (Assuming R_VERSION is old when provided as x.y.z) is also addressed.

[krlmlr]

How do we detect that a release candidate is available?

[LiNk-NY]

Hi @mjsteinbaugh @ahmohamed , Any updates on this? Thanks!

[ahmohamed]

This turned out to be a hard problem. r_versions API that we are using here does not return release candidates. This information is also not included in the r-svn repo. It would be too much work to implement this way.

The ultimate solution would be to ask Bioconductor maintainers to add an API endpoint that returns R versions associated with each Bioc version in a JSON format (similar to this page ). This way we will be able to mirror Bioconductor build machines. @LiNk-NY Let me know if this is possible.

[LiNk-NY]

We do have a mapping of versions here: https://bioconductor.org/config.yaml In order to avoid constant querying of the website, it's better to hard code the version numbers as the Travis CI folks do.

The issue we were seeing occurs between CRAN R and Bioconductor releases where the version of R is the Release Candidate (RC). This cannot be easily accounted for without some extra work. I think it is best to stick to the R versions and wait the time it takes for Bioconductor releases to catch up to the CRAN R release. We are currently past the above mentioned period and we are okay to use R release for Bioc-devel (3.10) and Bioc-release (3.9).

Best, Marcel

[rdiaz02]

Sorry if I am getting lost, but should @LiNk-NY comment on 27-May mean that as of now (2019-07-02) things should work with Bioc-devel? Because with both R_VERSION: release and R_VERSION: patched I am getting Error: Bioconductor version not change. (release: https://ci.appveyor.com/project/rdiaz02/oncosimul/builds/25695899; patched: https://ci.appveyor.com/project/rdiaz02/oncosimul/builds/25695185)

[LiNk-NY]

Hi Ramon, @rdiaz02

This issue would be resolved with PR #154. It is still yet to be merged.

CC: @krlmlr

[rdiaz02]

Hi Marcel, @LiNk-NY, Thanks for the update and clarification.

[krlmlr]

Merged now. Thanks for the nudge.

Please open a new issue if problems persist.