你遇到的这个问题确实很常见——首次测试成功后续全部失败，结合NoSuchDriverException: invalid session id的报错，和共享内存不足或残留有直接关系。下面给你两种可行的方式来实现挂载/dev/shm，或者直接增大容器的共享内存：

方法一：全局配置GitLab Runner（所有job生效） #

这种方式会让使用该runner的所有job都自动挂载主机的/dev/shm，一劳永逸：

1. 找到GitLab Runner的配置文件config.toml（通常路径是/etc/gitlab-runner/config.toml，如果是自行安装的runner）。
2. 找到对应的runner节点（[[runners]]段落），在[runners.docker]下修改volumes配置，添加/dev/shm:/dev/shm：

   [[runners]]
     name = "你的Docker Runner名称"
     url = "你的GitLab实例地址"
     token = "你的runner token"
     executor = "docker"
     [runners.docker]
       # 其他配置保持不变
       volumes = ["/dev/shm:/dev/shm", "/cache"]  # 增加/dev/shm的挂载
       # 如果之前设置了shm_size，可以保留或者设为0，让容器使用主机的shm
       shm_size = 0
     [runners.cache]
       # 缓存配置保持不变
   

3. 重启GitLab Runner服务：

   sudo gitlab-runner restart
   

这样，后续所有用这个runner启动的容器，都会把自身的/dev/shm和主机的/dev/shm绑定，避免容器内共享内存不足的问题。

方法二：单个job级别配置（仅针对测试job） #

如果你不想修改全局runner配置，只想让这个测试job生效，可以直接在gitlab-ci.yml的job中设置shm_size，有时候增大shm就足够解决问题：

修改你的gitlab-ci.yml，给测试job添加shm_size字段：

test:
  stage: test
  services:
    - name: mysql:5.7
      alias: mysql-test
  image: chilio/laravel-dusk-ci:stable
  shm_size: '256m'  # 设置为256MB，根据你的需求调整大小
  script:
    - cp .env.ci .env
    # 后续测试命令...

这个配置会直接给该job的容器分配指定大小的共享内存，不需要挂载主机的/dev/shm也能解决大部分共享内存不足的问题。如果还是不行，再用方法一的挂载方式。

另外补充一下：你之前增大runner的shm_size但没生效，可能是因为runner的全局shm_size被job级别的配置覆盖了，或者设置的大小还是不够。挂载主机的/dev/shm相当于让容器使用主机的共享内存池，通常空间更大，也能避免容器间的shm残留问题。

内容的提问来源于stack exchange，提问作者Martijn Imhoff