Added check_gh.yaml#232
Conversation
Signed-off-by: David Muñoz Tord <david.munoztord@mailbox.org>
|
Thanks for the PR! I'm trying to understand the use case better — could you walk me through the workflow you're trying to achieve? From what I can gather, the goal is to use testthat::snapshot_download_gh() to pull snapshot artifacts from CI, which requires the standard r-lib/actions/check-r-package@v2 with upload-snapshots: true. The org's reusable workflows don't produce artifacts in that format, so the download fails. My concern is that this adds a second R CMD check workflow alongside the existing check.yaml, meaning every PR would run the full check twice. That's a lot of extra CI time for something that could be handled locally. The typical snapshot workflow is: run tests locally, review with testthat::snapshot_review(), accept with testthat::snapshot_accept(), and commit the updated _snaps/ files. CI then just verifies they match. Is there a specific reason the snapshots can't be generated locally in your case (e.g., platform-specific output differences)? |
The reason is that I had issue with some programmers trying to reproduce issues but dealing with the dependencies locally can be a bit of a pain, especially when they can't really install github versions in their environment. But I definitely see your point.. that is true that is a waste of CI credits and resources. One solution would be to not run automatically but just as workflow on dispatch maybe ? |
Signed-off-by: David Muñoz Tord <david.munoztord@mailbox.org>
Signed-off-by: David Muñoz Tord <david.munoztord@mailbox.org>
Added check_gh.yaml to be able to create actual snapshot for
testthat::snapshot_download_gh()which has issues with custom pipelines. I does exactly the same as R-CMD-CHECK as-CRAN otherwise.I think this would be a really useful addition, what do you think ?