Add Workbench session init container image

[skyeturriff]

Part of https://github.com/rstudio/rstudio-pro/issues/6920

Hoping to get some early(ish) feedback on adding a new image. I know this might be a bit awkward given this repo is in a bit of transition, so want to help mitigate any headaches/future pains where I can and make sure I'm doing things properly!

This image will be the new init container as part of Workbench's efforts to improve session components. I used connect-content-init as my example for how to set this up.

So far I've only added a new bake target for a daily build. I added this to the build-manual and build-bake-preview github workflows.

NOTE This also updates the rstudio_workbench_daily branch to kousa dogwood in get-version.py

I've tested this locally via

just preview-bake workbench-session-init-daily
mkdir init
docker run --rm -v $(pwd)/init:/mnt/init rstudio/workbench-session-init-preview:workbench-session-init-jammy-2024.11.0-daily-328.pro3

I also included a basic goss test.

[CLAassistant]

All committers have signed the CLA.

[zachhannum]

Should also get approval from someone on platform, but I think it would be good to go ahead and get this into dailies for QA and testing! IMO we can push up additional PRs to add the release build and swap out the run script for something more elegant.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[bschwedler]

Will this also help us reduce what is included in the session image?

• Remove unused Workbench Components #624

[bschwedler]

This looks good overall. Thanks for adding these!

[bschwedler]

Do we need to specify the version for products we aren't building in the workflow?

I don't yet fully understand if all bake targets require all these env vars.

[bschwedler]

@ianpittwood This is really a question for you.

[ianpittwood]

Yeah. It's a bake limitation. It doesn't handle null values on build variables even if they're not part of the specified targets.

[bschwedler]

If there are specific session component files, we should probably check for them here.

If we want to check the indivdual contents of a tarfile that was added to the container, we could use a command block, running tar with the -t flag to ensure that the tarball has the expected contents.

[skyeturriff]

Ooh, I think the issue here is the tarball gets cleaned up in the last line of the Dockerfile RUN command, so it won't be around for goss to test against. But I think it's good practice to verify this, so I could check against the extracted directory structure. I'm uncertain how this would behave across versions though, if say we removed or added contents to the archive in a future release. I think in that case, we'd need to update the test, which would then only run successfully against the latest version?

[skyeturriff]

Will this also help us reduce what is included in the session image?

@bschwedler That's the goal, yes! We'll use the init container to load all the session-specific components( vscode, rsession, rserver-launcher, etc.) into the session image, so the session image itself only needs to include the basics (system dependencies, R, python, etc.). Zach's prototype includes an example "base" session image here

[ianpittwood]

LGTM

[ianpittwood]

Yeah. It's a bake limitation. It doesn't handle null values on build variables even if they're not part of the specified targets.

[skyeturriff]

I'm going to merge this in as-is so we can start to get dailies for testing, and address what's remaining (adding the release build, swapping out the run script, a more robust goss test) in follow-up PR(s)

[zachhannum]

@ianpittwood @bschwedler does the repo need to be created manually on the dockerhub side of things? https://github.com/rstudio/rstudio-docker-products/actions/runs/11611641762/job/32333438273#step:4:1398

[ianpittwood]

@ianpittwood @bschwedler does the repo need to be created manually on the dockerhub side of things? https://github.com/rstudio/rstudio-docker-products/actions/runs/11611641762/job/32333438273#step:4:1398

Oh yes, let me go do that for you guys.

[ianpittwood]

@zachhannum @skyeturriff it had a successful build now to Dockerhub.