1518 upversion lock

[bms63]

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.

Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the devel branch until you have checked off each task.

• Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
• Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
• Updated relevant unit tests or have written new unit tests - See Unit Test Guide
• If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
• Update to all relevant roxygen headers and examples
• Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
• Address any updates needed for vignettes and/or templates
• Update NEWS.md if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
• Build admiral site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
• Address or fix all lintr warnings and errors - lintr::lint_package()
• Run R CMD check locally and address all errors and warnings - devtools::check()
• Link the issue in the Development Section on the right hand side.
• Address all merge conflicts and resolve appropriately
• Pat yourself on the back for a job well done! Much love to your accomplishment!

[github-actions]

Package	Line Rate	Health
admiral	98%	✔
Summary	98% (3777 / 3865)	✔

[bms63]

Time to use that fancy tech!!

[bundfussr]

I think at the moment none of the R-CMD checks uses renv.lock. Shouldn't we use it for the 4.0 check?

[bms63]

I think at the moment none of the R-CMD checks uses renv.lock. Shouldn't we use it for the 4.0 check?

Not sure I am following.

I'm pretty sure the lock file is used for the other checks: man, lintr and test coverage, but it is not used for the R-CMD checks

[bundfussr]

In the past we used renv.lock for the 3.6 R-CMD check and for the other R-CMD checks the package versions available at the release date of the corresponding version.
As we move from 3.6 to 4.0 now, should we use renv.lock for the 4.0 R-CMD check.

[bms63]

I don't believe the lock file is needed in the R-CMD check workflow anymore.

I just did a quick scan, and I don't see it referenced anywhere. The lock file has lots of packages that don't need to be installed to run the R-CMD checks (i.e. the imports versus the suggests). I think this is why it was removed from this workflow

https://github.com/pharmaverse/admiralci/blob/main/.github/workflows/r-cmd-check.yml

[bundfussr]

OK, I see.

[bundfussr]

On the other hand, in #1512 I used dplyr 1.0.0 functionality in one of the examples but forgot to update renv.lock. All R-CMD check passed (because they did not use renv.lock). But if we have merged the PR, local R-CMD check would fail for all developers and contributors who use renv.lock.
So maybe it would be better to use renv.lock for the lowest version we are testing.
@bms63 , @thomas-neitmann , what do you think?

[bms63]

@bundfussr made a separate issue. Can we update lock file? happy to discuss more

[bundfussr]

It seems that the workflows are still using R 3.6 but I do not know why. @cicdguy , could you have a look.

[cicdguy]

It seems that the workflows are still using R 3.6 but I do not know why. @cicdguy , could you have a look.

Ok, yes. Something is amiss. I am investigating.

[cicdguy]

Ah, it's a GitHub shenanigan: actions/runner#1189
The environment variable doesn't get translated from the top level of the workflow as an input variable. We'll need to un-DRY the workflow. I'll do it in this PR. We need to do the same everywhere else for all pipelines as well.

[cicdguy]

@bundfussr and @bms63 - we'll need to make similar changes everywhere for all admiral packages. Unfortunate that GitHub doesn't support such a basic feature.

[bundfussr]

Thanks @cicdguy ! I have created corresponding issues in admiraldev and admiralonco.

[bundfussr]

@cicdguy , by the way, are you aware of the following warning occurring in "Normalize inputs"?

Warning: The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

[cicdguy]

@cicdguy , by the way, are you aware of the following warning occurring in "Normalize inputs"?

Warning: The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Yes, we are aware of this one and will resolve it at some point.