我将作业设置为只在将作业推送/合并到分支"dev“时才能运行,但我也希望这样做,因此如果手动触发该管道,我就能够运行它们。就像这样:
test:
stage: test
<this step should be run always>
build:
stage: build
rules:
- if: $CI_COMMIT_REF_NAME == "dev"
- if: <also run if the pipeline was run manually, but skip if it was triggered by
我使用GitLab Runner在AWS EC2 spot实例上运行CI作业,使用其对Docker的自动标度功能。
突然之间,GitLab CI未能运行作业,并向我展示了我想要启动的所有作业的以下作业输出:
Running with gitlab-runner 14.9.1 (f188edd7)
on AWS EC2 runner ...
Preparing the "docker+machine" executor
10:05
ERROR: Preparation failed: exit status 1
Will be retried in 3s ...
ERROR:
我有一个很长的gitlab CI,是一种单声道存储库的结构。如下所示: Project A
--- .gitlab-ci.yaml (contains thousands of jobs across 3 stages(plan, test and apply) and also includes gitlab-ci folder)
--- gitlab-ci/my-ci.yaml (folder than contains specific ci files, this has 2 stages, plan and apply for my-new-code)
-
我想在停靠容器as explained in the doc中使用GitLab运行器,主要是为了方便地将其部署到另一台机器上。我想知道如何使用它来安全地运行GitLab发送给运行器的CI/CD作业。 GitLab运行器文档警告using shell as an executor is unsafe,因为所有代码都以GitLab运行器用户权限运行,因此可以访问该用户在主机上有权访问的所有内容。 然而,在运行in a docker container的GitLab运行器中使用shell executor是否安全?我的直觉是,所有的安全问题都归结于docker容器:如果它不是以--privileg
我是Python /CD作业的新手,但我正在尝试设置一个GitLab脚本,该脚本在推送到GitLab时会触发CI/CD作业来运行它,并调用一个内部函数再次推送到GitLab,前提是满足一定的条件。因此,例如,假设我有以下内容:
def hasFileInDirectory():
# checks if the current directory has at least 1 other file in it
if (1 or more files exist):
print 'Great! You have enough files!';
在我的本地开发机器上,我使用docker.from_env(version=auto) ()来获得一个没有任何问题的docker客户端。如果我在一个在docker容器内运行(或在本地调试期间使用gitlab-runner exec docker ... )的gitlab-ci作业中运行相同的语句来获得一个docker客户端,我会得到一个DockerException: Error while fetching server API version: ('Connection aborted.', error(2, 'No such file or directory