Pushing back changes with CI_JOB_TOKEN - Possible?

Hi,

There’s a lot of historical information here and elsewhere online stating that CI_JOB_TOKEN only has read permissions to the repository, but based on the documentation here it seems to be that this is outdated:

The token has the same permissions to access the API as the user that caused the job to run. A user can cause a job to run by taking action like pushing a commit, triggering a manual job, or being the owner of a scheduled pipeline. Therefore, this user must be assigned to a role that has the required privileges.

Despite that, I’m unable to push changes made to files as part of the pipeline with this token, always getting: remote: You are not allowed to upload code.

The CI/CD job is instructed to run a PowerShell script:

  script:
    - $Script = 'https://gitlab.example.com/Public/PSDeploy/-/raw/main/Publish.ps1'
    - Invoke-Expression -Command ((New-Object System.Net.WebClient).DownloadString($Script)) -ErrorAction Stop

and the push attempt uses the format:

git push --push-option="ci.skip" https://gitlab-ci-token:$($CICD)@$CI_SERVER_HOST/$CI_PROJECT_PATH.git HEAD:$($CI_COMMIT_BRANCH)

I’ve also tried git push --push-option="ci.skip" $CI_REPOSITORY_URL HEAD:$($CI_COMMIT_BRANCH) as a shorter form of the above.

The script functions as required including publishing a build folder to the project package registry using the job token, but it just fails at this last push step.

The project is private, I’m an owner of it, the branch is not protected (and developers and maintainers can push to it).

I am able to get this working by using a project access token (PAT) in place of the job token, but I wanted to simplify things by avoiding having to setup a PAT for many projects that can’t be grouped.

Self-hosted GitLab: 15.6.0-ee
Runner version: 15.6.1 on Windows Server 2019.

Help much appreciated

@robinmalik

Thanks for the post! The documentation you linked to shows which endpoints can be authenticated against with the CI_JOB_TOKEN and git push is not something yet supported. We have an epic open where we are capturing use cases for additional CI_JOB_TOKEN permissions where you can add support to an existing issue for this functionality. Until then the workaround is to use the PAT as you have found.

I hope this helps!

-James H, GitLab Product Manager, Verify:Pipeline Execution

I hope this helps!

Thanks James, glad to have that cleared up!

There is another very useful thing you can do in the interim, and that is to improve your documentation. “The token has the same permissions to access the API as the user that caused the job to run” does not adequately describe the reality.