chipsalliance / verible-linter-action

Automatic SystemVerilog linting in github actions with the help of Verible
Apache License 2.0
24 stars 11 forks source link

Optimise execution by using a Container Action #3

Closed umarcor closed 3 years ago

umarcor commented 3 years ago

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:

tgorochowik commented 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)

umarcor commented 3 years ago

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.