GSoC self-assessment ideas for GitHub Actions

actions-exercises.md

Self-assessment ideas: R package testing + GitHub Actions

If you're new to either GitHub Actions or to CI testing of R packages, here are some exercises that can help you get a sense what's involved so that you can write a well-informed proposal. These are not mandatory, and we won't ask to see the results.

Set up simple GitHub Actions checks on an R package

1. Pick any R package on GitHub and fork it to your own account. It doesn’t matter who wrote the package or what it does, as long as it doesn’t yet have any Actions configured. If you prefer, you could make a new dummy package instead of forking one.
2. Add a GitHub Actions workflow that performs package checks on every push. Verify that the build passes reliably.
3. Modify the package code to introduce a bug, commit it, and verify that the build fails.
4. Commit a fix for the bug you introduced. Verify that the build passes again.

Expand Actions checks

Modify the package you set up above by doing any of the following. To keep this easy, you might want to implement each step in a separate Git branch so that you don't have to worry about e.g. differences between R versions while you're working on conditional runs.

1. Run package checks on more systems

   Modify the Actions workflow you used in task 1 to run:

   • Simultaneously on two different OSes
   • In two versions of R in the same OS
   • Inside two different Docker images.

   For each step, make sure all checks pass.

2. Add conditional checks

   In a new Actions workflow alongside the existing one, run the same R package checks as the existing workflow, but make them run conditionally:

   • When you push to a particular branch
   • At a scheduled time
   • When the package’s man/ folder is updated.

   For each step, make sure that:

   • The old workflow runs and passes every time
   • The new workflow runs when expected and that it passes
   • The new workflow does not run when you expected it not to

3. Handle dependencies

   1. Modify your R package to include the call udunits2::ud.convert(1:3, "cm", "km")
   2. Write a unit test that will fail if that call does not return c(1e-05, 2e-05, 3e-05).
   3. Update the Actions workflow from task 1 so that it will install udunits2 before checking the package
   4. Verify that the build passes

   Note that udunits2 relies on the system library libudunits, so to work correctly your workflow will need to either install it or run in a Docker image that already provides it.

Critique the existing PEcAn project CI setup

All commits to the PEcAn develop branch are required to have a passing CI build before they are merged. We currently use Travis for this, but would like to migrate to GitHub Actions.

Look at our .travis.yml file and at some recent Travis builds (https://travis-ci.org/pecanProject/pecan) and write down a few sentences in response to each question. Once again these responses are for your own use and you don't need to share them with us, but they might be very useful starting points when writing your project proposal.

1. If you were rebuilding this CI setup, what is the first thing you would change?
2. What do you think is the the worst pain point for PEcAn's code contributors?
3. What's the worst pain point for the maintainers of the Travis configuration?
4. If you were rebuilding this setup elsewhere, what is one thing you would keep?

Now look at the existing prototype of a GitHub Actions CI workflow (https://github.com/PecanProject/pecan/tree/actions-ci), and write down:

1. What does this workflow do better than the existing Travis CI workflow?
2. What does it do worse than the existing Travis CI workflow?
3. To completely switch from Travis to GitHub Actions, which things at minimum would need to change in the Actions workflow before we switched?

To finish, step back to the big picture: PEcAn faces many interesting technical challenges to keep all its parts working well together, but its key mission is to be a useful tool for ecosystem science. A successful GSoC proposal will address this context as well as the technical challenges.

1. Which one of the scientific goals of the PEcAn project would be most advanced by integrating GitHub Actions into PEcAn, and why?
2. At the end of the summer, what improvement from your project do you think will be most notable to a scientist who uses PEcAn but never looks at its CI results?
3. Why do you want to do this project? Why PEcAn rather than other organizations, and why this project rather than others?

See also: description of the project itself