Cannot push from gitlab-ci.yml

后端 未结 3 1544
礼貌的吻别
礼貌的吻别 2020-12-23 12:18

With my colleagues, we work on a C++ library that becomes more and more important each day. We already built continuous integration utilities through the gitlab-ci.yml

相关标签:
3条回答
  • 2020-12-23 12:27

    While the previous answers are more or less fine, there are some important gotya's.

      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}"
    

    For one, we only need to set the username/email to please git.

    Secondly having it in the before script, is not super crucial, but allows for easier reuse when doing 'extend'.

    Finally, pushing https is 'fine' but since we're not using a stored ssh key, we should avoid anything that can reveal the token. For one, while gitlab won't print the token in this command, git will happily inform us that the new upstream is set to https://username:thetokeninplaintexthere@url So there's your token in plain text, so don't use -u to set an upstream.

    Also, it's not needed, we are only doing a single push.

    Further more, when determining the URL, I found that using the exist CI_REPOSITORY_URL to be the most reliable solution (when moving repo's for example or whatnot). So we just replace the username/token in the URL string.

    0 讨论(0)
  • 2020-12-23 12:35

    The gitlab ci token is more like the deploy key in github.com, so it only has read access to the repository. To actually push you will need to generate a personal access token and use that instead.

    First you need to generate the token as shown here in the gitlab documentation. Make sure you check both the read user and api scopes. Also this only works in GitLab 8.15 and above. If you are using an older version and do not wish to upgrade there's an alternative method I could show you but it is more complex and less secure.

    In the end your gitlab-ci.yml should look something like this:

    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 ..
    
    0 讨论(0)
  • 2020-12-23 12:42

    You could also provide user and password (user with write access) as secret variables and use them.

    Example:

    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'
    

    You have to define GIT_CI_USER and GIT_CI_PASS as secret variables (you could always create dedicated user for this purpose).

    With this configuration you could normally work with git. I'm using this approach to push the tags after the release (with Axion Release Gradle Pluing - http://axion-release-plugin.readthedocs.io/en/latest/index.html)

    Example release job:

    release:
      stage: release
      script:
        - git branch
        - gradle release -Prelease.disableChecks -Prelease.pushTagsOnly
        - git push --tags
      only:
       - master
    
    0 讨论(0)
提交回复
热议问题