[R-pkg-devel] Two (newbie/luser) questions about adding CI to github hosted package

[Duncan Murdoch]

On 16/03/2021 9:04 a.m., Chris Evans wrote:
> Hugely appreciated Duncan.
> 
> ----- Original Message -----
>> From: "Duncan Murdoch" <murdoch.duncan using gmail.com>
  ...

>> You have 5 workflows, and their current content doesn't appear to match
>> the results on your actions page.  Pick one, run it, and I'll see if I
>> can spot the reason for a failure.
> 
> That is so appreciated Duncan. One stupid question: is there a way to run a
> workflow other than by making an upload/push (or a pull request)?

If you have something like this in your yaml file:

# Controls when the action will run.
on:

   pull_request:
     branches: [ master ]

   workflow_dispatch:


then it says the workflow will run when there is a pull request to the 
master branch, and also on request (that's what "workflow_displatch:" 
means).  You can leave out the "pull_request:" lines and only run on 
request.

To actually make the request, you go onto your Github site, go to the 
Actions page, then pick one of the workflows from the list on the left.
If it has "workflow_dispatch" in the file, you'll see a "Run workflow" 
button appear on the right.  It's actually a drop down box; you can 
choose to use the workflow from a different branch by choosing it from 
the list.

Something I'm not sure about is whether choosing a workflow from a 
different branch also selects your package code from that branch, or 
whether you have to choose that on the main Code page.  Experiment, it's 
free!

> 
> I think I have discovered that the workflows are controlled by the yaml files
> in .github/workflows so I have deleted all except R-CMD-check.yaml and I think
> that when I now commit and push this that should delete the other workflows
> on github and trigger this one to run.  If you could look at that one then
> that would be hugely appreciated.  I see it says:
> 
>      strategy:
>        fail-fast: false
>        matrix:
>          config:
>            - {os: macOS-latest,   r: 'release'}
>            - {os: windows-latest, r: 'release'}
>            - {os: windows-latest, r: '3.6'}
>            - {os: ubuntu-18.04,   r: 'devel', rspm: "https://packagemanager.rstudio.com/cran/__linux__/bionic/latest", http-user-agent: "R/4.0.0 (ubuntu-18.04) R (4.0.0 x86_64-pc-linux-gnu x86_64 linux-gnu) on GitHub Actions" }
>            - {os: ubuntu-18.04,   r: 'release', rspm: "https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
>            - {os: ubuntu-18.04,   r: 'oldrel',  rspm: "https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
>            - {os: ubuntu-18.04,   r: '3.5',     rspm: "https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
>            - {os: ubuntu-18.04,   r: '3.4',     rspm: "https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
>            - {os: ubuntu-18.04,   r: '3.3',     rspm: "https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
> 
> 
> Some questions as I, I think, make some progress:
> 
> 1) Why is windows-latest pointing at 3.6?  I am on 4.0.4 locally for windows.  I assume this is because I have copied or pulled in
> a template that is out of date.  Can I just replace that '3.6' with 'release'

I think so.

> 2) My guts say that at this point it is sensible for me to test against devel, release and oldrel but that after the next
> release I could stop testing against oldrel?  Is that sensible?

This really depends on your audience.  It looks like the script you have 
came from the tidyverse people; they try to support 4 releases before 
the current one.  That's pretty extreme, you don't really need all 
those.  But I'd leave oldrel in place.  There are definitely lots of 
people out there who haven't updated to 4.0.x yet, for various reasons, 
e.g. not being admin on their computer.

> 
> 3) I see tests against 3.3, 3.4 and 3.5 there for ubuntu 18.04 and no 20.04.  Am I correct that I could replace the above
> with this:
> 
>      strategy:
>        fail-fast: false
>        matrix:
>          config:
>            - {os: macOS-latest,   r: 'release'}
>            - {os: windows-latest, r: 'release'}
>            - {os: windows-latest, r: 'release'}
>            - {os: ubuntu-18.04,   r: 'devel', rspm: "https://packagemanager.rstudio.com/cran/__linux__/bionic/latest", http-user-agent: "R/4.0.0 (ubuntu-18.04) R (4.0.0 x86_64-pc-linux-gnu x86_64 linux-gnu) on GitHub Actions" }
>            - {os: ubuntu-18.04,   r: 'release', rspm: "https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
>            - {os: ubuntu-18.04,   r: 'oldrel',  rspm: "https://packagemanager.rstudio.com/cran/__linux__/bionic/latest"}
>            - {os: ubuntu-20.04,   r: 'devel',     rspm: "https://packagemanager.rstudio.com/cran/__linux__/xenial/latest"}
>            - {os: ubuntu-20.04,   r: 'release',     rspm: "https://packagemanager.rstudio.com/cran/__linux__/xenial/latest"}
>            - {os: ubuntu-20.04,   r: 'oldrel',     rspm: "https://packagemanager.rstudio.com/cran/__linux__/xenial/latest"}
> 
> [I have changed the windows '3.6' to 'release' and the last three ubuntu calls to 20.04 and the R versions to 'devel', 'release'
>   and 'oldrel' and the repositories to point at xenial not bionic.  I have only done this here in the Email, not on disc!]

I don't know.  This depends on all those paths in the rspm field being 
available.  If RStudio is making them available, that is probably fine.


> It would be nice to check all that occasionally but I am sure that at the frequency I'm pushing up new functions and tweaks,
> so my colleagues can check things, I am putting far too much work on github with all those.  Could I just check windows
> and macOS release and devel by commenting out lines there.  Or is it better to have different yaml files and just to put
> the one you want in .github/workflows for each particular push?  No great difference?

My feeling is you want lots of versions, and lots of platforms, but not 
necessarily the product of those two things.  If something is going to 
fail because of a platform issue, it'll likely fail in the "release" 
version.  If it is going to fail because of R changes, it'll likely fail 
on all platforms.

As you've probably seen, when one of those jobs fails, you get email:  I 
don't like repetitive emails, so I limit the jobs I run.

Duncan Murdoch