Question

与我的同事一起，我们致力于一个每天变得越来越重要的C ++库。我们已经通过gitlab-ci.yml文件构建了持续集成实用程序，让我们：

构建＆amp;在调试模式下测试
构建＆amp;在发布模式下测试
使用Valgrind执行内存泄漏等安全检查，并检查我们的库中是否有任何我们不想要的清晰符号
生成文档

所有让我们选择GitLab的东西！

我们希望对整个图书馆进行分析，并将基准测试推广到一个单独的项目中。我们已经使用 SSH密钥方法完成了类似的文档，但我们希望这次避免这种情况。

我们尝试了这样的脚本：

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，我有权同时推进这两个项目。我在哪里做错了什么？

Answer 1

gitlab ci令牌更像是github.com中的部署密钥，因此它只具有对存储库的读访问权限。要实际推送，您需要生成个人访问令牌并使用它。

首先，您需要生成令牌here in the gitlab documentation。确保检查read user和api scope。此外，这仅适用于GitLab 8.15及更高版本。如果您使用的是较旧的版本并且不希望升级，那么我可以向您展示一种替代方法，但它更复杂且安全性更低。

最后你的gitlab-ci.yml应该是这样的：

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
    - 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://${YOUR_USERNAME}:${PERSONAL_ACCESS_TOKEN}@gitlab.mycompany.home/developers/benchmarks.git HEAD:master
    - cd ..

Answer 2

您还可以提供用户和密码（具有写访问权限的用户）作为秘密变量并使用它们。

示例：

before_script:
 - git remote set-url origin https://$GIT_CI_USER:$GIT_CI_PASS@gitlab.com/$CI_PROJECT_PATH.git
 - git config --global user.email 'myuser@mydomain.com'
 - git config --global user.name 'MyUser'

您必须将GIT_CI_USER和GIT_CI_PASS定义为秘密变量（您始终可以为此创建专用用户）。

使用此配置，您通常可以使用git。我正在使用这种方法在发布后推送标签（使用Axion Release Gradle Pluing - http://axion-release-plugin.readthedocs.io/en/latest/index.html）

示例发布作业：

release:
  stage: release
  script:
    - git branch
    - gradle release -Prelease.disableChecks -Prelease.pushTagsOnly
    - git push --tags
  only:
   - master

Answer 3

虽然先前的答案或多或少都不错，但还是有一些重要的葛蒂的答案。

  before_script:
    - git config --global user.name "${GITLAB_USER_NAME}"
    - git config --global user.email "${GITLAB_USER_EMAIL}"
  script:
    - <do things>
    - git push "https://${GITLAB_USER_NAME}:${CI_GIT_TOKEN}@${CI_REPOSITORY_URL#*@}" "HEAD:${CI_COMMIT_TAG}"

对于其中一个，我们只需将用户名/电子邮件设置为git。

第二个在before脚本中包含它并不是至关重要，但是在进行“扩展”时可以更轻松地重用。

最后，推送https是“很好的”操作，但是由于我们没有使用存储的ssh密钥，因此我们应避免使用任何会泄露令牌的内容。例如，虽然gitlab不会在此命令中显示令牌，但git会很高兴地通知我们新的上游设置为https://username:thetokeninplaintexthere@url 因此，您的令牌以纯文本形式存在，因此请勿使用-u设置上游。

此外，这不是必需的，我们只执行一次推送。

此外，在确定URL时，我发现使用现有的CI_REPOSITORY_URL是最可靠的解决方案（例如，在移动回购协议时）。因此，我们只需要在URL字符串中替换用户名/令牌即可。

无法从gitlab-ci.yml推送

3 个答案: