Discuss: Scoping of pilot

[dgkf]

Copying a proposal shared by @piresj today. Tagging @pharmaR/ws-repo as I think this is something we should settle on rather soon.

As we aim to have a demo available in June, let's decide on precisely what that means to us. @piresj proposed:

By the end of April:

• have one validation report with a specific storage place.
• basic container image
• basic validation pipeline
• basic validation repository

---

I'll update these notes as we agree on the details of what this should look like

[dgkf]

I'll throw in my own thoughts from the call today, and I'd appreciate hearing from others. @yonicd, I'd be specifically interested in your ideas about what we should target for the image.

Based on the recent exploration of r-hub/repos, I think we should aim for having the following:

Absolutely Minimum Goal

This would be a wizard of oz POC, where many of the technical details are faked to gauge viability and communicate intent.

• A clone of r-hub/repos with accompanying risk metrics pulled from riskscores

Minimum Technical Goal

The next goal is to start fleshing out the technical operations of such a solution. For this I propose the following:

• A choice of an image. As a technical POC, I'm okay with gaps. I would still probably lean toward just repurposing an r-hub container. Time allowing, I think we could host our own with a few tweaks.
• A minimal r-hub/repos pipeline, monitoring changes in CRAN and re-running riskmetric as packages are updated.
• A user-accessible repository with a minimal use case in mind. Implicitly filters CRAN packages to those in a narrow task view or to support a single package (I liked @mmengelbier's suggestion for stringr + dependencies (11 total packages))
• An example report. At a minimum showing metric values. Depending on whether we want to tackle a storage location for additional build/check logs, also including those. This need not be produced by our pipeline, but as an example of what tools could do with these build artifacts.

[yannfeat]

• A minimal r-hub/repos pipeline, monitoring changes in CRAN and re-running riskmetric as packages are updated.

I am ready to pick up this work, and I can do it by the end of April.

• A user-accessible repository with a minimal use case in mind. Implicitly filters CRAN packages to those in a narrow task view or to support a single package (I liked @mmengelbier's suggestion for stringr + dependencies (11 total packages))

@dgkf won't the filtering be part of the above-mentioned pipeline? Or is it yet another GitHub workflow?

• An example report. At a minimum showing metric values. Depending on whether we want to tackle a storage location for additional build/check logs, also including those. This need not be produced by our pipeline, but as an example of what tools could do with these build artifacts.

@Stefan-Doering-BI you have made progress on this, do you think the end of April would be a realistic target?