Skip to content
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

Make sure all CI is running and is feature complete #13

Closed
seabbs opened this issue May 7, 2024 · 3 comments · Fixed by #65
Closed

Make sure all CI is running and is feature complete #13

seabbs opened this issue May 7, 2024 · 3 comments · Fixed by #65
Assignees

Comments

@seabbs
Copy link
Contributor

seabbs commented May 7, 2024

As a first step before any development we need to make sure that all required CI is in place and that it works as expected.

@athowes
Copy link
Collaborator

athowes commented May 13, 2024

Flag that I'm not that familiar with CI and could do with more guidance before feeling ready to tackle this.

@seabbs
Copy link
Contributor Author

seabbs commented May 13, 2024

Fair enough.

We likely want github actions to:

  • Build the pkgdown
  • Do a Rmd check against multiple OS's (if we have things in our tests we don't expect to run on CRAN then we might also way two versions of this (i.e with and without those tests being skipped)
  • Lint the package using lintr.
  • Code coverage with codecov
  • Manage the deployment of our README and the use of the all contributors bot.
  • Check our cmdstan code works with the latest version of Cmdstanr (optional/stretch goal).
  • Benchmarking using touchstone (also a stretch goal/its own issue).

All of these are implemented for epinowcast and so in the first instance we can mostly just copy them across and read through them to check there is nothing specific to epinowcast in them.

That donee we can change our branch protection rules for main to start requiring some of them be be successful prior to merging

For things like linting and Rmd checks currently we expect those to fail but a focus early in the development should be to get the code base (via cutting and documentation etc) to a place where those both pass. This should really be done ahead of adding in new features, making interface changes, or adding lots of tests in my view. The other critical CI we need in place before adding tests is code coverage as that will help us when building out the testing suite.

I think the place to start here is a PR setting up one CI and we can go from there.

@athowes
Copy link
Collaborator

athowes commented May 28, 2024

I suggest we do #60 and then after that I have a go at working through these remaining ones (to the extent they're not already working):

  • Build the pkgdown
  • Do a Rmd check against multiple OS's (if we have things in our tests we don't expect to run on CRAN then we might also use two versions of this [i.e with and without those tests being skipped])
  • Lint the package using lintr
  • Code coverage with codecov
  • Manage the deployment of our README and the use of the all contributors bot Issue 29: Update README workflow #60
  • Check our cmdstan code works with the latest version of Cmdstanr (optional)
  • Benchmarking using touchstone (optional)

@athowes athowes self-assigned this May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants