我和同事们一起开发了一个日益重要的C++库,我们已经通过gitlab-ci.yml
文件构建了持续集成实用程序,使我们能够:
- 在调试模式下生成和测试
- 发布模式下的构建和测试
- 使用Valgrind执行安全检查,如内存泄漏,并检查库中是否有任何我们不希望包含的清除符号
- 生成文档
所有让我们选择GitLab的东西!
我们希望对我们的整个库进行概要分析,并在一个单独的项目中推送基准测试。我们已经使用SSH key方法对我们的文档进行了类似的操作,但这次我们希望避免这样做。
我们试过这样一个脚本:
test_ci_push:
tags:
- linux
- shell
- light
stage: profiling
allow_failure: false
only:
- new-benchmark-stage
script:
- git clone http://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.mycompany.home/developers/benchmarks.git &> /dev/null
- cd benchmarks
- touch test.dat
- echo "This is a test" > test.dat
- git config --global user.name "${GITLAB_USER_NAME}"
- git config --global user.email "${GITLAB_USER_EMAIL}"
- git add --all
- git commit -m "GitLab Runner Push"
- git push http://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.mycompany.home/developers/benchmarks.git HEAD:master
- cd ..
我们还尝试了一个基本的git push origin master
来推送更新的文件,但每次都得到相同的答案:
remote: You are not allowed to upload code for this project.
fatal: unable to access 'http://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@gitlab.mycompany.home/developers/benchmarks.git/': The requested URL returned error: 403
这两个项目都在同一个site
下,我有权利推送这两个项目。我哪里做错了?
5条答案
按热度按时间hwamh0ep1#
gitlab ci令牌更像是www.example.com中的deploy密钥github.com,所以它只有对仓库的读权限,要真正推送,你需要生成一个个人访问令牌并使用它。
首先你需要生成gitlab文档中所示的令牌。确保你同时检查了read user和API作用域。而且这只在GitLab 8.15及以上版本中有效。如果你使用的是旧版本并且不想升级,我可以给你展示一个替代方法,但是它更复杂,更不安全。
最后你的gitlab-ci.yml应该看起来像这样:
3xiyfsfu2#
虽然前面的答案或多或少是罚款,有一些重要的gotya的。
首先,我们只需要将用户名/电子邮件设置为please git。
其次,在before脚本中使用它并不是非常重要,但在执行“extend”时可以更容易地重用它。
最后,推送https是“好的”,但由于我们没有使用存储的ssh密钥,我们应该避免任何可能泄露令牌的操作。首先,虽然gitlab不会在这个命令中打印令牌,但git会很高兴地通知我们新的上游设置为https://username:thetokeninplaintexthere @ url所以这是明文形式的令牌,所以不要使用-u来设置上游。
此外,这是不需要的,我们只是做一个单一的推动。
此外,在确定URL时,我发现使用现有的CI_REPOSITORY_URL是最可靠的解决方案(例如,在移动存储库时),因此我们只需替换URL字符串中的用户名/令牌。
lo8azlld3#
您还可以提供user和password(具有写访问权限的用户)作为秘密变量并使用它们。
示例:
您必须将
GIT_CI_USER
和GIT_CI_PASS
定义为秘密变量(您总是可以为此创建专用用户)。有了这个配置,你就可以正常地使用git了。我使用这个方法在发布后推送标签(使用Axion Release Gradle Pluing-http://axion-release-plugin.readthedocs.io/en/latest/index.html)
发布作业示例:
hiz5n14c4#
我正在使用以下GitLab作业:
我正在使用我自己的基于alpine check this GitHub repository for more info的danger89/repo_mirror_pull docker映像。
这个GitLab作业从预定义的远程仓库+分支(见下面的变量)拉取上游变更,并在CI/CD中本地合并它们,然后再次将它们推送到GitLab。
基本上我创建了一个仓库pull mirror(GitLab CE上没有免费提供,GitLab只支持推送镜像)。
再次,另见:https://github.com/danger89/repo_pull_sync_docker_image
关于这个问题,请参阅上面的
git push
命令,它允许您使用GitLab(project)访问令牌将更改推回GitLab。wfauudbj5#
查看GitLab 15.9(2023年2月)是否有帮助。
首先,文档"GitLab CI/CD job token"确实提到:
该令牌与导致作业运行的用户具有相同的访问API的权限。
用户可以通过执行诸如推送提交、触发手动作业或成为已调度管道的所有者等操作来使作业运行。
因此,必须将此用户分配给具有所需权限的角色。
其次,GitLab 15.9(针对Saas www.example.com或自管理示例)提出了以下建议:gitlab.com or self-managed instances) proposes:
控制哪些项目可以使用CI/CD作业令牌访问您的项目
存储在
CI_JOB_TOKEN
CI/CD变量中的CI/CD作业令牌使作业中的API调用身份验证更加直观,从而实现了高级自动化。例如,令牌可以与在其他项目中运行管道的机器人自动化项目一起使用。
令牌的生存期很短,但与触发管道的用户具有相同的权限。
为了使其使用更加安全,我们添加了一个设置,允许您定义一个受信任项目列表,您可以使用作业令牌访问您的项目。
这一附加的安全层意味着只有这些项目能够使用作业令牌访问您项目的API。
在bot自动化示例中,它允许您控制哪些bot项目可以与您自己的项目交互。
默认情况下,此设置当前在现有项目中处于禁用状态,以避免影响管道,但强烈建议在所有项目中启用它。
默认情况下,对所有 * new * 项目启用此选项。
参见文档和Issue。
添加到允许列表的项目可以使用CI/CD作业令牌从正在运行的管道进行API调用。
因此,如果你需要推送到一个单独的项目,将你当前的项目添加到它的入站访问列表中,你的管道(使用你当前的项目)将能够使用默认的
CI_JOB_TOKEN
标记推送到你单独的项目。