-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
switch for local / Docker commands #13
Comments
@wesley-dean-flexion Looks interesting but I am not sure how many users will tend to use docker versions. Would be great to see an example of it to see how beneficial it will be. Have you got any example repo. |
I do not have a good example repo that I can share. Sorry. My concern is that getting the entirety of my team to install and maintain the various tools may look like an imposition and represent a barrier to adoption. However, everyone has Docker installed locally and we're free to use Docker containers in our CI/CD processes. My vision was that we could include a switch in the installation process looked something like:
If it's the native option, the .pre-commit.yaml is generated the way that it is currently. If it's the Docker option, the .pre-commit.yaml is generated something like:
(the It's entirely possible -- probable -- that an arbitrary user won't need this functionality as they can install the required tooling on their local systems. My hope is to achieve team-wide adoption; to that end, I want to preempt team members from citing the burden of installing a few tools as justification for resisting progress. This idea is completely optional. As with the Git module source PR, the resulting .pre-commit.yaml can be updated on the backend with some Thanks!! |
@wesley-dean-flexion Thank you for the detailed explanation and example. I can see the benefits of using docker images. Please make a PR and let me know if you need any help |
@sudokar just a thought... most of the pre-commit hooks (e.g., terraform_fmt, terraform_docs) in the generated .pre-commit-config.yaml file use Anton Babenko's tooling for running the aforementioned scripts with locally-installed tools, which is normal and what most sane people would do. I'm wondering, though, if it would be useful to others to use Dockerized versions of those tools. So, for example, instead of running the
terraform_docs.sh
script, use the official terraform_docs container (quay.io/terraform-docs/terraform-docs:latest). If that makes sense, perhaps it would be good to add a switch to the module generator which would set a local/dockerized tools parameter.Why? Because I tend to run
terraform
and such in Docker because downloading it and installing it every few days as Hashicorp releases patches is tiresome to me.I'm happy to draft the shell script wrappers if you find this interesting.
The text was updated successfully, but these errors were encountered: