search

r-universe-org / help

Support and bug tracker for R-universe
https://docs.r-universe.dev/
9 stars 2 forks source link

PharmaR ideas and requirements #390

Open jeroen opened 6 months ago

jeroen commented 6 months ago

https://github.com/pharmaR/regulatory-r-repo-wg/issues/76

dgkf commented 6 months ago

Thanks for all your feedback today @jeroen! just following up on a couple points discussed today. (tagging @wiligl, @borgmaan, @Crosita for visibility)

Build info

Could you help point me to the best place to track reproducible builds?

I'm poking around in this aorsf workflow (linked via the windows build icon in the r-universe builds tab). Are these build logs the best place to track this info? I'm able to find runner info and a set of steps for the build. This might be enough for our use case. Just want to make sure I'm pointing to the right resources when taking this back to the rest of our team.

If the logs are best found in github actions, then one challenge we have is GitHub's retention policy (90 days for public repos). In the regulated use case this would probably need to be far longer (I'd need to double check on the explicit requirements, but it would be on the order of 10+ years).

That said, at the R Validation Hub, if this were the only limitation we could certainly build up some tools to mirror logs periodically.

Package dependencies during checks

Our goal is that when using the package we'd be able to point to the same repository or set of repositories for grabbing all required packages and be confident that documented check results would be replicated with the same set of packages.

In practice, I'm hoping we could simply point to a set of repositories such as:

options(repos = c(
  ropensci = "https://ropensci.r-universe.dev/2024-03-31",
  ppm = "https://p3m.dev/cran/2024-03-31"
))

From a regulatory perspective, the goal is that re-running the builds/checks using only the packages in these repos would reproduce the original build/check results.

From what I can tell, checks are not re-calculated when a reverse dependency is updated. Similarly, for packages available in the same snapshot of an r-universe, they may have been initially built/checked using dependencies from CRAN at different times meaning we can't assume their checks would be reproduced given only a snapshot.