Was contemplating if it makes sense to have a single image for ALL pre-commit needs and alias `pre-commit` to `docker run pre-commit -v "$(pwd)":/workdir:rw`
Oh and yes, this is inspired by all the supply chain stuff. If the alternative is that each pre-commit hook becomes its own Docker image, I'm afraid it'll be too slow.
Any experiences?
(edited: docker exec isn't possible with volumes)
Oh wait... `docker exec` doesn't make sense for `-v "$(pwd)":/workdir:rw`. Can't attach/detach volumes on the fly like that. So we do need `docker run`.
But that's just one decision less then 🤞
Okay, I'm now running a globally aliased `pre-commit` to point at a `docker run` command that mounts the current working directory (a git repo) into the container and runs pre-commit from there.
It worked well, so I typed it up:
https://codeberg.org/benjaoming/pre-commit-docker-alias
I did have to override the `pre-commit install` with a custom hook because the default bash-executed hook doesn't see aliases. It probably doesn't work for commit hooks that are already running in Docker, then we need "dind" 🙃
@decibyte @valberg maybe a minor thing... but it seems like the right thing to fully isolate/externalize pre-commit from the application's environment so the dependencies of pre-commit itself (I know the hooks are isolated) aren't mixed. I know it's minimal but it has these:
```
cfgv>=2.0.0
identify>=1.0.0
nodeenv>=0.11.1
pyyaml>=5.1
virtualenv>=20.10.0
```
It can also have runtime dependencies, depending on the hooks.
Benjamin Balder Bach
VÃðir Valberg Guðmundsson
decibyte