Add workflows for tests and R CMD check

[Kss2k]

Purpose

In reference to the email I sent previously, I am submitting this pull request for the commits I've made to the repository. This pull request includes the addition of workflows that enable the R CMD check and package tests to run automatically on pull requests.

The main purpose of this pull request is to demonstrate how these workflows can be activated on pull requests. Please feel free to review the changes. If you have any concerns or suggestions, don't hesitate to request modifications or reject the changes as you see fit.

Changes

I added two workflows for R CMD check and running tests using testthat (via devtools::test). Both workflows are set to run on pull requests (if approved by a maintainer). R CMD check is automatically triggered on push to main. Since the tests take quite a long time to run (approximately 45-50 mins), the tests workflow needs to be manually triggered by a maintainer on GitHub. This can be changed if you wish.

When creating the workflows I made some changes in regards to the R CMD check and the tests. For the R CMD check I added a new line to the DESCRIPTION file, specifying the Encoding (UTF-8), 'required' by roxygen2, when writing the documentation.

Regarding the tests a lot of changes were made. Firstly I renamed tests/tests/ to tests/testthat/, to make the tests runable by devtools::test(). testthat automatically added some lines to the DESCRIPTION file. I also updated some of the test-files, in cases where there were deprecation warnings (e.g,. "tol is deprecated, use tolerance instead", "context() is deprecated, and can be removed"). Additionally I added some global settings to R among them is warnings for partial matches. I.e., when you retrieve an object from a list using the $ operator, you may sometimes retrive it by a partial match (e.g., mylist$groupName may retrieve the partial match mylist$groupNames). I located some of these partial matches in the package, and corrected them accordingly.

Currently, the test workflow results in 4 errors, which I think stem from the package/tests themselves, and not from any of my commits.

── Failed tests ────────────────────────────────────────────────────────────────
Failure ('test-01-mirtOne.R:175:5'): dich
out1$M2 (`actual`) not equal to 11.76977 (`expected`).

  `actual`: 11.96
`expected`: 11.77

Failure ('test-04-multipleGroup.R:74:5'): one factor
so[[1]]$class_proportion (`actual`) not equal to 0.5104 (`expected`).

  `actual`: 0.51047
`expected`: 0.51040

Failure ('test-04-multipleGroup.R:86:5'): one factor
out1$M2 (`actual`) not equal to 166.4414 (`expected`).

  `actual`: 166.05
`expected`: 166.44

Failure ('test-17-DIF_DRF.R:45:5'): DIF
out$p (`actual`) not equal to c(0.1090403, 0.07219868, 0.175297, 0.1354964, 0.6970995) (`expected`).

  `actual`: 0.10905 0.07222 0.17533 0.13553 0.69715
`expected`: 0.10904 0.07220 0.17530 0.13550 0.69710

[ FAIL 4 | WARN 0 | SKIP 0 | PASS 532 ]

[Kss2k]

@philchalmers it might be worth considering splitting the test workflow into multiple smaller workflows, running smaller sunsets of the tests. E.g., one workflow running test files 00-03, 04-06, ... and so on. That way the tests would probably complete a bit faster, and you could choose to only run relevant tests on pushes/pull-requests.

[philchalmers]

Great, thanks! I'll give this new workflow a spin for a while to see how it works. Thanks for the code quality contributions.

[philchalmers]

Something in this pull seems to have triggered a check issue on my local version. Could you check it out? It looks to be related to a Debian specification somewhere.

✔  checking for GNU extensions in Makefiles ...
✔  checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS)
✔  checking use of PKG_*FLAGS in Makefiles
✔  checking use of SHLIB_OPENMP_*FLAGS in Makefiles ...
✔  checking pragmas in C/C++ headers and code ...
N  checking compilation flags used
   Compilation used the following non-portable flag(s):
     ‘-mno-omit-leaf-frame-pointer’
✔  checking compiled code ...
✔  checking installed files from ‘inst/doc’ ...
✔  checking files in ‘vignettes’ ...
─  checking examples ... [19s/19s] OK (19.8s)
✔  checking for unstated dependencies in vignettes ...
✔  checking package vignettes in ‘inst/doc’
✔  checking re-building of vignette outputs (387ms)
✔  checking for non-standard things in the check directory ...
✔  checking for detritus in the temp directory

[philchalmers]

Ignore that; this seems related to my Ubuntu desktop rather than this pull. On other OS instances (Ubuntu server included) this looks fine.

[Kss2k]

I see, I see that the same *note* is present on the workflow as well. As you suggest, it's caused by the platform. I think the compilation flags are inherited from the compilation flags used to build R itself -- since I wasn't able to deactivate the compilation flags by changing the Makevars file, or the environment variables. I updated the container image to use a different R-image (rocker/r-base). Now there should no longer be a note on non-portable compilation flags (on Github atleast). I completely forgot to mention this in my pull-request: Currently the image used in the workflow is hosted from a repo on my Github account (https://github.com/Kss2k/container-mirt). The reason for making a container in the first place is to avoid having to download (and compile) dependencies every time you run the checks. For the time being I've sent you an invite to be a collaborator on the repo. Once you accept, I intend to make you an administrator. If you wish I could downgrade my own role. We could also add branch protection rules, such that you need to approve any future updates/commits. If this is not satisfactory, it might be a good idea for you to copy/fork it, and host it from your own account (+ replacing the container in your workflow file). Best, Kjell man. 11. nov. 2024 kl. 22:51 skrev Phil Chalmers ***@***.***>:

…

Ignore that; this seems related to my Ubuntu desktop rather than this pull. On other OS instances (Ubuntu server included) this looks fine. — Reply to this email directly, view it on GitHub <#262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3BNAT4VX5CMQKUUYJZCVVT2AERHJAVCNFSM6AAAAABRSR6DDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRZGEYTIMZSGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[philchalmers]

Hi Kjell,

I've decided to go with the latter approach of hosting the docker image on my account by copying your current codebase, though I've not done this on Github before and am likely to hit some bumps along the way..... Nevertheless, I greatly appreciate all the information you've provided.

All the best,

Phil

[Kss2k]

Good idea! PS: If you wish to host the container publicly, it is not enough to make the repo public. You must also make the package (I.e., the container) public. I've forgotten this a few times my self... Best, Kjell

…

On Tue, 12 Nov 2024, 18:38 Phil Chalmers, ***@***.***> wrote: Hi Kjell, I've decided to go with the latter approach of hosting the docker image on my account by copying your current codebase, though I've not done this on Github before and am likely to hit some bumps along the way..... Nevertheless, I greatly appreciate all the information you've provided. All the best, Phil — Reply to this email directly, view it on GitHub <#262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3BNAT4XBSD4AZLUC7ZILST2AI4LHAVCNFSM6AAAAABRSR6DDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZRGE3TKNBYGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>