action on `ubuntu-slim` runner disables EXE001

[ogauthe]

Hi! I had a lot of headaches with a EXE001 rule that was failing locally but not on CI.

I finally found out that ubuntu-slim runner was the issue: I get the expect behavior on ubuntu-latest.

As mentioned in the doc, these runners are not within a VM but just a container. There is an open issue about EXE001 behavior not running on windows/WSL (see also astral-sh/ruff#7994). So my guess is that the os behind ubuntu-slim container actually runs windows (or is detected as such by ruff), which makes ruff disables EXE001.

You can have a look at ogauthe/my-ruff-issue#1 for a full example: the very same workflows passes on ubuntu-slim but fails on ubuntu-latest.

My question: is there a way to get the ruff-action to run EXE001 on ubuntu-slim?

[ntBre]

Thanks for the report and for the reproduction repo! I was curious about this and added some additional debug logging to the workflow in brentbot/my-ruff-issue#1. In particular:

=== /proc/sys/kernel/osrelease ===
6.1.146.1-microsoft-standard
=== /proc/version ===
Linux version 6.1.146.1-microsoft-standard (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.5.0, GNU ld (GNU Binutils) 2.34.0.20200910) #1 SMP Mon Jul 21 20:38:16 UTC 2025
=== /proc/self/cgroup ===
14:misc:/
13:rdma:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
12:pids:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
11:hugetlb:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
10:net_prio:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
9:perf_event:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
8:net_cls:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
7:freezer:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
6:devices:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
5:memory:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
4:blkio:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
3:cpuacct:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
2:cpu:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
1:cpuset:/containers/0a4f46a3ab0283273c59dc9d76923c66931feb0aca53e59c453ce9d7373fffa3
=== /.dockerenv ===
NOT FOUND
=== /run/.containerenv ===
-rw-r--r-- 1 root root 0 Jan 20 15:05 /run/.containerenv

These checks roughly follow the checks in is_wsl. We first see that osrelease does include microsoft, which should then trigger the is-docker check, but the container isn't actually a Docker container, at least as checked by is-docker by looking for docker in the cgroup or for a /.dockerenv file.

So it seems that the is_wsl crate is missing a check for non-Docker containers that can also confuse the main heuristic.