Test new GitHub Action for containerised lesson builds?

[tobyhodges]

How could the content be improved?

Hi @swcarpentry/r-novice-inflammation-maintainers 👋

@froggleston has been developing a modified version of the GitHub Actions workflows we use to build and deploy lesson websites, which uses a container image to control the build environment. Based on his tests so far, it looks like this adjusted approach will make the builds more resistent to upstream changes, e.g. the semi-regular problems we encounter when a new version of R or a major dependency is released.

We are looking for an RMarkdown-based lesson where we could test the new workflows out. Would you be happy to give it a try here? Rob has tested the updated version on his own fork already and everything is looking good.

We'd like to apply the changes here then monitor how things run for a few months, before (hopefully) rolling out the new workflows across all of The Carpentries' lesson repositories.

[froggleston]

Thanks @tobyhodges ! I appreciate the heads up to get some testing started!

For those interested, a summary of what the future changes to the Workbench workflows mean are here: https://github.com/carpentries/sandpaper/pull/650

[Bisaloo]

Sounds good to me! I'm excited to see this in action.

[froggleston]

@Bisaloo - awesome! I've raised a PR to replace the workflows. I'll be around here or on Slack as usual if you have any issues or questions!

[froggleston]

And I've added pngquant to the Dockerfile so will be in the next Workbench docker release.

[froggleston]

So the scheduled build today failed, as I believe the cache expired just before the run was due to commence (caches are kept for 7 days). I've manually run Apply Package Cache to rebuild and cache again, and the build has succeeded.

[tobyhodges]

Thanks @froggleston. So if I understand correctly, now that the new cache was created after the scheduled build, the cache should not expire before the next weekly build and we should not see this problem again?

[froggleston]

Correct! We can monitor this next week.

[froggleston]

The build seems to have succeeded fine this time round, due to when the caches were made.

[Bisaloo]

I can also confirm it just worked great on a push.

[froggleston]

Just for info, your latest build failed because of the new Workbench docker image version (v0.1.16) was released and there is no cache for that version. To get your build up and running, please run the "03 Maintain: Apply Package Cache" workflow manually.

This is pretty much the final piece of the puzzle I'm working through and would appreciate some feedback.

When the package check workflow runs, I propose to detect when the docker "latest" rolls over to a new image version, and automatically run the Apply workflow if there are no package updates?

Update: I've implemented the above and it seems to work well with the fork I have of this lesson:

• Package update check: If the PR is skipped, it will attempt to run the Apply Package Cache automatically ("Skip PR Creation", then "Trigger Apply Cache Workflow")
• Apply package cache: This now has a clearer structure, and in this instance, a cache was already available so no cache generation was performed. As such, the final trigger to run the Build and Deploy step was not run.

In short, this should fulfil the above. When a scheduled Tuesday package check runs, if there is no valid cache and no packages are going to be updated (so no PR generated), it will automatically rebuild the package cache. This should mean that the final Build and Deploy step triggers, and your lesson will build with the new Workbench version!

[froggleston]

I've opened #673 to improve some of the workflow behaviour and reduce complexity in the repo workflow files themselves.