Gitlab CI/CD cannot git push from .gitlab-ci.yml

Question

I'm writing GitLab CI/CD pipeline script in .gitlab-ci.yml I want to check if a specific file changed in another repo and if so I would like to copy the file, commit and push to the current repo. everything works until I get to the 'git push' part

I tried several ways to fixed it:

stages:
    - build

build:
  stage: build
  script:
    - echo "Building"
    - git checkout -b try
    - git remote add -f b https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.{otherRepo}.git
    - git remote update
    - CHANGED=$(git diff try:mobile_map.conf b/master:mobile_map.conf)
    - if [ -n "${CHANGED}" ]; then
        echo 'changed';
        FILE=$(git show b/master:mobile_map.conf > mobile_map.conf);
        git add mobile_map.conf;
        git commit -m "updating conf file";
        git push;
      else
        echo 'not changed';
      fi
    - git remote rm b

for this code I get :

fatal: unable to access 'https://gitlab-ci-token:[MASKED]@gitlab.{curr_repo}.git/': The requested URL returned error: 403

also I tried to add this line in the beginning :

git remote set-url origin 'https://{MY_USER_NAME}:"\"${PASSWORD}\""@gitlab.{curr_repo}.git'

and I get this error message:

fatal: Authentication failed for 'https://{MY_USER_NAME}:"\"${PASSWORD}\""@{curr_repo}.git/'

also I added:

 - git config --global user.name {MY_USER_NAME}
 - git config --global user.email {MY_EMAIL}

please help me, Thanks

Answer 1

Job-tokens only have read-permission to your repository.

A unique job token is generated for each job and provides the user read access all projects that would be normally accessible to the user creating that job. The unique job token does not have any write permissions, but there is a proposal to add support.

You can't use deploy-tokens because they can't have write-access to a repository (possible tokens). You could use a project-access-token with read-write-access to your repository.

You can use project access tokens:

• On GitLab SaaS if you have the Premium license tier or higher. Project access tokens are not available with a trial license.

• On self-managed instances of GitLab, with any license tier. If you have the Free tier: [...]

Then you can use your project-access-token as an environment variable in the url.

git push "https://gitlab-ci-token:$PROJECT_ACCESS_TOKEN@$CI_SERVER_HOST/$CI_PROJECT_PATH.git"

At least that's how we use it in our pipelines. I hope this helps you further.

Answer 2

Complete example of simple GitLab CI stage, that commits back to its own repo

ci_section_name:
  # N.B. This stage produces an extra commit to the repo!
  stage: stage_name
  script:
  - apt-get update && apt-get install -y git
  - echo "hello" >> file_to_be_modified.txt  # your real job may do smth else
  after_script:
  - git config user.name "Name On Your Choice"
  - git config user.email "email_on_your_choice@$CI_SERVER_HOST"
  - git pull "https://project_access_token_name:$PROJECT_VARIABLE_WITH_ACCESS_TOKEN_VALUE@$CI_SERVER_HOST/$CI_PROJECT_PATH.git" $CI_COMMIT_BRANCH --rebase --autostash
  - git commit -a -m "Message on your choice"
  - git push "https://project_access_token_name:$PROJECT_VARIABLE_WITH_ACCESS_TOKEN_VALUE@$CI_SERVER_HOST/$CI_PROJECT_PATH.git" HEAD:$CI_COMMIT_BRANCH

I want to stop on few important aspects:

• file_to_be_modified.txt - any modified files in the example are supposed to already exist in the repo, if you need add smth new, you will need include at least git add command

• project_access_token_name - is the name of used Project Access Token, not the token value itself (see screenshots below); you should create it by hands for your GitLab project if necessary

• PROJECT_VARIABLE_WITH_ACCESS_TOKEN_VALUE - is the name of Project Variable (see screenshots below), you should create this variable by hands for your GitLab project and populate it with value of chosen Project Access Token; btw, you can add literal value of the token into stage code instead, but it is probably bad for security reasons

• --rebase --autostash - note that autostashing your changes instead of simply trying to pull-push them will help you to guarantee the push in case of conflicts (even our new GitLab stage may conflict between its launches) but files would be left with conflict trace instead of correct content; because it is hard to resolve conflicts automatically, it is supposed that you control such situation with another tools (for example, further build on conflict state will simply fail)

• This simple example will lead to an infinite flow of commits, probably real stage should contain some only conditions, etc.

Screenshots

GitLab Project Access Tokens page

GitLab Project CI/CD Settings menu, where to find Variables settings

Add project Variable pop-up