Today I faced one of those "this is Witchcraft" moments.
CI was failing for a specific commit. I checked out that exact commit locally… everything clean. Built fine. No errors.
Witchcraft 🧙! "I'm exactly on the same commit, and in my local machine it does build with no problems".
This was a JS project. And in JS (TS doesn’t matter here), my first suspect is always dependencies.
So, I removed node_modules
and rebuilt from scratch.
Witchcraft x2 🧙🧙! still couldn’t reproduce the error.
So I went to the workflow file and started following step by step what CI was doing.
Witchcraft x3 🧙🧙🧙! it can't b... oh wait.
Of course the CI runs everything in a clean, pure node:20-alpine
image.
So I fired up the same container locally to see what was going on.
Now, this is just he context to what i want to share:
I use this tiny script like...a lot.
If you use
oh-my-zsh
, you can add it to~/.oh-my-zsh/custom/docker-run.zsh
(adapt to your setup):
docker-run.zsh
function docker-run() {
if [[ -z "$1" ]]; then
echo "Usage: docker-run <image>"
return 1
fi
local container_image="$1"
local workdir="/app"
docker run --rm -it \
-v "$PWD:$workdir" \
-w "$workdir" \
"$container_image" \
/bin/sh
}
Super simple. Just go to your project folder:
$» docker-run node:20-alpine
/app #
The devil’s in the details:
-
--rm
so the container is gone when you exit -
$PWD
mounts the current project inside the container -
it
so you’re dropped into the terminal -
sh
cause these minimal images usually don’t havebash
Back to the mysterious "Witchcraft!🧙 error" —>
Turned out there was a node version mismatch: v20.18.1
locally vs. v20.19.2
in the container.
No magic for today.
--
thanks for reading.
Some images such as the slim .NET Core runtime images, doesn't have a shell at all. docker debug can be used in this case (locally of course).