Benjamin Balder BachApr 3

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)

#precommit

Show threadBenjamin Balder BachApr 3

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 🤞

Show threadBenjamin Balder Bach

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" 🙃

pre-commit-docker-alias

Experiment: Alias your global pre-commit to a Docker container and reduce attack surface on dev systems

Codeberg.org
Apr 4 at 2:40pmWeb
Show threadBenjamin Balder BachApr 4

A screenshot from running a dockerized pre-commit.

And here's the whole darn alias 🥳

```
$ which pre-commit
pre-commit: aliased to docker run -v "pre-commit-cache":/home/dockeruser/.cache -v "$(pwd)":/repo:rw -e PRECOMMITALIAS="$(alias pre-commit)" -e PGID="$(id -g)" -e PUID="$(id -u)" pre-commit:python3.14
```

Instructions on building and running it are in the repo ⬇️
https://codeberg.org/benjaoming/pre-commit-docker-alias

#precommit

Show threadVíðir Valberg GuðmundssonApr 4
@benjaoming I know @decibyte is a fan of running pre-commit in a container. I haven't practiced it myself. I'm a big fan of https://github.com/j178/prek btw. which might make things faster.
GitHub - j178/prek: ⚡ Better `pre-commit`, re-engineered in Rust

⚡ Better `pre-commit`, re-engineered in Rust. Contribute to j178/prek development by creating an account on GitHub.

GitHub
Show threadBenjamin Balder BachApr 4

@valberg thanks! I heard of it and wondered.. but running prek won't solve the issue that exists with running the hooks on the local development laptop, though... (edit: Ah I see you mean to dockerize prek instead of pre-commit, right?)

Looking forward to hearing what @decibyte does!

Show threadVíðir Valberg GuðmundssonApr 4
@benjaoming @decibyte Yeah, didn't mean that prek would solve the issue, just that it might speed up your experience with running in a container :)
Show threadBenjamin Balder BachApr 4

@valberg @decibyte I found that the overhead of spinning up the current container is like 0.4s.

But I have to add Node to the container to scratch my biggest itch, so that might add a bit.

Show threadBenjamin Balder BachApr 4
@valberg very sneaky: dockerize `prek` and alias it as `pre-commit` 😎 cc @decibyte
Show threaddecibyteApr 4
@valberg @benjaoming I wouldn't say I'm a fan of running anything in a container as such. But I prefer running things like pre-commit in the same environment as the application.
Show threadBenjamin Balder BachApr 4

@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.