As suggested by @yonicd do a reverse dependency check for rxode2 too

[mattfidler]

I think he said that the repositories that do this are here:

https://github.com/yonicd/slackposts

[mattfidler]

@yonicd I'm having a hard time finding the github workflow, if/when you get time can you point me to it. It isn't super urgent, but it would be appreciated.

[yonicd]

@mattfidler here are some resources for setting it up. If you need to have a short meeting for more hands on explanations or a PR let me know. Happy to contribute.

Slides from talk about some non-conventional gha usage

• repo/deck 16-19
  • Lots of gha snippet code in the deck repo that are good for copy/pasting

repo setup:

• lets say you have a parent repo (P) and two child repos (C1, C2)
• on a commit from P you want to dispatch C1 and C2
  • P: https://github.com/yonicd/slackteams/blob/adv_gha_caching/.github/workflows/R-linux.yml#L139_L157
    • A new job, dispatch, that is triggered after check successfully completes
  • C1/C2: https://github.com/yonicd/slackthreads/blob/9508e0ca89a9ad13a239b6712b416b1e245d7b67/.github/workflows/R-mac-revdep.yml
    • The child repos have a new workflow that is waiting for the dispatch from P.
    • At the end of this workflow there is a final step that on workflow failure you open in P a new issue that will notify that there was a failure in C1/C2

Notes

• The workflows are pretty old so they probably can use some dusting off with more current inner steps/caching

Extensions

• This workflow may also be interesting to you. I was experimenting with the idea of splitting up a workflow into cached steps that would only trigger if the relevant file would have a hash change. (think {targets} for gha @billdenney)
  • The idea being that not all changes warrant a full workflow run (DESCRIPTION/README/Vignettes), this is very helpful on expensive and complicated setups with heavy dependencies across repos.
• You may also find slides +20 that explain the {shield} workflow also interesting. It basically tries to create more space between your repos and CRAN, with the thinking that once a package gets updated on CRAN and breaks something in your package you are caught flat footed and need to quickly react and be at the mercy of certain cranky CRAN maintainers moods. Shield will run your cmd checks as if you were depending on the main branch of the dependency and not the CRAN tip (I like to get bad news as early as possible).

[mattfidler]

Thanks so much @yonicd !!!

I will take this to the nlmixr2 team. I think we will probably need to decide if we will be combining the nlmixr2 package before applying this. With that being said, I think we will work on this starting Jan. I hope you have a great holiday season 😄