Docker Support

[gregtkogut]

@tdenewiler and @axydes, just for a sanity check before I open PRs, can you check my work in:

main...gregtkogut:publish_docker_image

and

sscpac/statick-action@main...gregtkogut:use_published_docker_image

Pretty simple. The former just pushes a docker image to the repository-affiliated space on GitHub Packages. In creating the Dockerfile I took into account the unhandled Dockerfile-related issues from the GitHub, e.g. eslint-in-userspace, adding statick-planning, etc.

The image here has the URL: ghcr.io/gregtkogut/statick:publish_docker_image

You can play with it directly, e.g.

docker pull ghcr.io/gregtkogut/statick:publish_docker_image
docker run  -it ghcr.io/gregtkogut/statick:publish_docker_image

This was created using a manually-initiated workflow, so the image name is the branch. For release-generated images (the intended use-case vs. the manual runs below), the image will be named after the release, and also a 'latest' tag is created.

I created a sample release in my personal statick repo, and here are the images names:

ghcr.io/gregtkogut/statick:0.0.2
ghcr.io/gregtkogut/statick:latest

The changes to the static-action repo just use the resulting image. The results are encouraging. Before the change running the statick-action took about 4-7 minutes. The new method using the pre-built image appears to take just over a minute or so. Which means someone using the more likely case of a single usage, could see less than 30 seconds to run statick within GitHub.

The history showing this difference in runtime is can be seen here: https://github.com/gregtkogut/statick-action/actions

Of course a lot of URLs will change for the actual PR.

I chose GitHub Packages for initial Docker support. It's pretty easy to add DockerHub later, if it makes sense. I thought that GitHub Packages probably had super-quick caching, etc, for use in GitHub Actions. At least I'd assume that's the case. Other use-cases, such as development or alternative CLI usage using containers might be a reason to later add DockerHub.

[tdenewiler]

In #392 (comment) we are talking about methods to allow a user to run Statick via Docker container in a local setting. I agree that the approach in https://github.com/tdenewiler/statick/tree/docker#docker is cumbersome and does not expose many of the desired options.

Another concern I have always had is that the Docker container will not contain all of the required dependencies for building and linking. The best example of this (for historical use cases) is the lack of ROS packages in the image. That opens up a can of worms, because which ROS distributions would you have in the image? And what happens when multiple base operating systems are needed to support all the LTS ROS distributions? Seems like multiple Statick Docker images would be required to support those cases.

There are likely more desired environments than ROS. The number of images could get out of hand. Finding a nice balance between utility and maintainability will be key.

[gregtkogut]

After PR merges, I hand-created:

ghcr.io/sscpac/statick:latest
ghcr.io/sscpac/statick:0.6.2

(Identical, but latest could be updated periodically)

statick-action is now pinned to v0.6.2, and the self-test successfully passes using that image.

Is there any reason now to not make an official Marketplace v1 release of Statick Action?

[tdenewiler]

Let's go for it. Then we can try out the action on some of our other repositories.

[gregtkogut]

Turns out we need the Organization admin to accept a Marketplace agreement. Who's our org. admin?

[denewiler]

@bbrockman, you helped set up our member accounts and the @sscpac/robotics group. Can you accept a Github Marketplace agreement so that we can provide our Statick tool as a Github Action?