Closed umarcor closed 3 years ago
Sounds like a good idea! Could you submit a draft for that?
How could we ensure we allow users to select a particular version of verible with this approach? With the current approach it will be simple to add that as we will just download a different file (not yet implemented but it's on the roadmap)
Gimme some minutes and I will open a PR: https://github.com/umarcor/verible-linter-action/tree/container-action
How could we ensure we allow users to select a particular version of verible with this approach? With the current approach it will be simple to add that as we will just download a different file (not yet implemented but it's on the roadmap)
Build different container images (one for each version/variant) and let the user specify it (either explicitly, or through some keyword). Since GitHub Actions provides a Container Registry accessible with the default token, it is cheap to create as many images as necessary. It can be effectively used as a cache for toolchains.
The current implementation of this Action is of type Composite. In the first five steps, the dependencies are downloaded and installed: https://github.com/chipsalliance/verible-linter-action/blob/main/action.yml#L31-L51. In the last step, which is a single bash script, the actual functionality is implemented: https://github.com/chipsalliance/verible-linter-action/blob/main/action.yml#L52-L87.
I recommend to convert this Action into a Container Action, since having it be a Composite does not provide any meaningful advantage in this use case.
The advantage of spliting dependency installation into a Dockerfile is that it can be later decoupled. That means, building and deploying the container image on one side, and using it in the action on the other side. As a result, the Action will be executed faster.
For reference, that approach is used in mithro/actions-includes:
Similar strategy, without decoupling, in dbhi/qus:
and eine/tip: