-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create R-CMD-check-CRAN-incoming.yaml #365
Conversation
R CMD check CRAN incoming feasibility check notes found:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #365 +/- ##
=======================================
Coverage 80.05% 80.05%
=======================================
Files 29 29
Lines 3269 3269
=======================================
Hits 2617 2617
Misses 652 652 ☔ View full report in Codecov by Sentry. |
|
I tend to think that large components in the version number should not throw an error here, because that will be the standard situation during most of the development phase. Since bumping the version number is part of the CRAN release checklist, I believe we will not miss that when submitting to CRAN in all likelihood |
Adds a new R-CMD-check-CRAN-incoming.yaml GH Action
The Action attempts to run
R CMD check
in the same way that Win Builder does, enabling one to get early notification of problems that will ultimately need to be addressed before a CRAN submission. The goal is to replicate the process used on CRAN/Win Builder (which is probably not entirely possible) and make appropriate notifications when something of interest happens.To that end, it...
R CMD check
with arguments, environment variables, etc. as close as possible to those run on CRAN and Win Builder* checking CRAN incoming feasibility ... [12s] NOTE
Maintainer: 'CJ Yetman <cj@cjyetman.com>'
andNew submission
00check.log
as a Job Summary00check.log
as an ArtifactI'm still questioning whether it should also parse out the
Version contains large components (0.0.0.9000)
note. That would effectively show up on every PR unless the version number was a proper release version number, but when a release is being made it would be a good nudge that the version number needs to be changed. Thoughts on that?It could alternatively only be run manually through
workflow_dispatch
and/or it could ignore theVersion contains large components (0.0.0.9000)
note.