CI/CD 和runner 机器上文件权限问题

我在.gitlab-ci.yml中在两个不同的runner下执行cd /etc/gitlab-runner的路径，一个是有权限的（755），另一个是没有权限的（700）。
有权限的runner类型是shell，没有权限的runner类型是docker，runner在同一台机器上是用docker安装的。
whoami过，用户都是gitlabr-runner，且服务器上的目录权限是755
百思不得其解。。

running on两个地方，
Running on a2b996dc42fc（755权限一致的日志）
Running on runner-docker…（700权限和时间不一致的日志）
后续再怎么排查额。。

你是run在不同的docker里面的话，是不是起docker的时候mount的volume不一致

您好，

如果可以的话，请提供完整的.gitlab-ci.yml文件。以下信息供您参考：
1）shell执行器是直接在gitlab runner所在机器上直接执行，查看的是gitlab runner所在主机的文件系统；2）docker执行器将会根据.gitlab-ci.yml文件中配置的镜像（如果没有指定，则使用创建docker执行器时指定的默认镜像）来启动一个docker容器，因此看到的是该容器内部的文件系统，而不是gitlab runner所在主机的文件系统。

不好意思，那么久才回复您。我大致明白了您的意思。
的确我觉得这个stage里的runner是通过image这个参数临时创建出来的runner镜像，等到stage全部运行完，这个runner镜像就会销毁。所以我没有办法在其中（runner上）增加永久的脚本文件。

                               
登录/注册后可看大图

那么问题来了，我们能不能通过自己的image来启动一个一直运行着得runner镜像？或者说只能用一台虚机去启动一个runner才是一直运行着的？

期待您的回复，谢谢~

您可以指定一个自己build的image来运行pipeline中的作业，但不管是用哪个image来运行作业，runner都只会在运行这个作业的时候才会使用这个image来启动一个容器环境，作业执行结束了容器就会被销毁掉。
这里面有几个概念比较容易混淆，需要先了解清楚：
1）runner是一个运行器，它会根据excutor（执行器）的类型来创建 运行作业的环境 ，比如SHELL类型就会创建一个shell会话；如果是docker类型，就会按照相应镜像启动一个容器来运行作业。因此runner程序会一直运行，但不等同于作业的运行环境，可以把runner理解成一个调度器。
2）运行作业的环境，并不等同于您的部署环境。作业可以看成一系列的命令，比如您可以在一个作业中通过一系列kubectl命令来把应用部署到k8s中，而如果您使用docker类型的执行器来执行这个作业，那么这个作业（一系列的kubectl命令）将在这个docker容器里执行，但应用（比如您自己build的应用镜像）将被部署到k8s环境中。

嗯首先感谢回复，我理解您说的两点。

现状是我发现有以下两类，比如两个运行器runner（执行器类型是不一样的，第一种是shell，第二种是自己build的image），且这两个runner都是容器形式：
第一种类型是容器一直不销毁的，即便stage结束后，这个容器的进程仍然存在。这点好处是我可以预先在这个容器里放公共的脚本，那么其它程序用这个runner去编译或部署时都可以共享公共的脚本。
第二种类型是我定义了自己的image，这个runner在stage运行完后，容器的进程会跟着被销毁。

所以我更倾向于第一种形式去创建runner，但是有点不太清除这两种创建的方式。我猜测第一种容器不销毁是这么操作的：先在服务器运行一个容器，然后在容器里去注册runner。而销毁的那种我猜测不需要额外做操作，只要定义image这个参数就行了？

我觉得可能我还需要去看下官网。。有没有哪个link介绍得比较详细得么？