Including maven in Builder Image

[sbrinkerhoff]

I did not see any discussion around how tools are chosen to be included/excluded from the Runner image, and I expect there i some preference to not manage everything as part of the included container. I am opening this partially as a discussion item, but also as a real request.

Is your feature request related to a problem? Please describe.

I am using the actions-runner-controller along with the summerwind/actions-runner and enjoy both tools, and would like to continue to use the upstream components without managing my own runner image. At the same time, maven is included within the Github.com runners, and actions such as setup-java expect Maven is already in the image. As a result, no well used public action exists that supports the management of Maven itself.

Describe the solution you'd like
I would like Maven included in the base docker image so that users can experience a more similar environment to a Github.com builder and not have to support shims to install maven as an action that are only needed when using the included docker image.

Describe alternatives you've considered

• Extend the docker image and include Maven myself.

Additional context

[toast-gear]

Unforutnately we're not looking to add more tools into the base image, in general we only consider new tools if (and tbh we're a hesitant even if these tests are met):

• The tool itself is generally version insensitive
• Any config associated with the tool itself is generally version insensitive

We are strict on what goes in the base runner image due to the maintainers having very limited time to support the project (we have actual jobs). We understand maintaining your own images is a bit of a pain in the arse however we wouldn't be able to provide a stable base imave if we brought in lots of tools to the base image (nor are we experts on all the tools out there).

The good news is that GitHub are going to make running your own image less painful soon by loosening the requirement to always be running latest actions/runner#1396 (comment). Once this is done running your own image built from ours shouldn't be as difficult as it is currently, stability wise, as you can stop them suddenly randomly upgrading the moment GitHub release a new version of the runner software. If you can deploy a k8s centric project you should be able to also maintain your runner images. GitHub should also stop making them explode from upgrades soon and so you will be able to do a more managed approach to upgrading them with these 2 changes combined (the process is fairly easily automated).

[sbrinkerhoff]

Thank you @toast-gear; I appreciate the process you are using to evaluate tools to be added to the existing container, and understand the reluctance to add further tools.