Publish docker image and use that in the Action

[ZedThree]

This would hopefully save one or two minutes off each Action run. Building the docker image and publishing to ghcr.io should be fairly easy to automate

[zhongfu]

I've been thinking about how this can be done, perhaps something like:

• have an action that publishes a single image for both non-split/split workflows, perhaps on each push with a tag
• update the action.yml files to point to either the latest image, or the corresponding tagged image
  • though if we're going with the latter, then we might have to manually update action.yml for each new release -- it doesn't seem like we can use variables (e.g. github.action_repository, github.action_ref) in that context

so far, it seems to shave ~1 minute off the build/pull step, with times going from ~1m19s to ~24s. not too bad, but perhaps we can bring this down even more if we can reduce the size of the image -- the image (less the base Ubuntu system) seems to be weighing in at around 1.58GB!

[zhongfu]

i also tried running review.py on the runner directly as part of a composite action (after installing only the required apt packages, plus everything in requirements.txt) -- that brought the setup time down to ~6s, since clang-tidy 12/13/14 (but not 11) is already installed on the ubuntu-latest runner image

[ZedThree]

Ah, nice, thanks for looking into this @zhongfu! That's a good point that we'd need the tag inside action.yml. There's some discussion on how to do this here: https://github.com/orgs/community/discussions/38311 but it sounds very complicated.

Ideally both the action.yml and published image would automatically get the same tag when a new version is released, but I can't see how to make that work. Maybe if the image was published on push to master? There is a registry_package event, so how about:

• PR merge commit triggers Docker image publish tagged with commit hash
• package publishing triggers workflow to update action.yml to use latest image

The images wouldn't have nice versions then, and they also wouldn't match up to the release commit.

I've also refactored the project layout so that there's a single installable package (see #69). We could also publish that on pypi, which would allow people to use the package outside of this Action. I think that's probably more advanced use though, as the user would need to take more care to have everything installed and call review with the correct arguments

[ZedThree]

The Alpine image is like 5MB, so that might be a good base, although I'd be worried people would have to install a lot more packages

[vadi2]

It would make obtaining necessary headers a lot more difficult. It's already a challenge that the action can't see the headers you've installed into the runner. Using Ubuntu makes it a bit simpler as lots of projects can obtain their dependencies from apt or having existing instructions setup for that. But using a highly-specialised distro like Alpine would complicate it even further.