As commented in #3, building the container image separatedly and the using it at runtime can reduce the execution time for users of this Action. In this PR, a workflow is added, which builds image ghcr.io/chipsalliance/verible-linter-action and pushes it to the GitHub Container Registry, using the default token. Then, in the Action, that image is used instead of the Dockerfile.
The workflows are scheduled weekly. Feel free to adjust that to your needs.
NOTE: CI will fail below because this PR does not have permission for pushing to ghcr.io/chipsalliance. That will work after this is merged to main. Precisely, workflow Container will work as soon as it is merged, and Test will need to be rerun afte the image is pushed for the first time. The references to my fork above did work because I temporarily used ghcr.io/umarcor instead.
This is a folloy-up of #4.
As commented in #3, building the container image separatedly and the using it at runtime can reduce the execution time for users of this Action. In this PR, a workflow is added, which builds image
ghcr.io/chipsalliance/verible-linter-action
and pushes it to the GitHub Container Registry, using the default token. Then, in the Action, that image is used instead of theDockerfile
.The workflows are scheduled weekly. Feel free to adjust that to your needs.
NOTE: CI will fail below because this PR does not have permission for pushing to ghcr.io/chipsalliance. That will work after this is merged to main. Precisely, workflow Container will work as soon as it is merged, and Test will need to be rerun afte the image is pushed for the first time. The references to my fork above did work because I temporarily used ghcr.io/umarcor instead.