Use CI JOB TOKEN to push code

[tachyons]

This PR is built on top of #859

GitLab now supports git push authenticted using CI JOB token. This PR update the authentication logic to also support CI JOB TOKEN when available.

[marchermans]

Any update on this, as this is a blocker for us as well?

[Copilot]

Pull Request Overview

This PR adds support for using GitLab CI Job Tokens as an alternative authentication method for semantic-release operations. The change allows CI pipelines to authenticate using the built-in CI_JOB_TOKEN instead of requiring separate access tokens, while handling the limitations of job tokens around commenting permissions.

• Adds job token detection and appropriate header handling (JOB-TOKEN vs PRIVATE-TOKEN)
• Implements validation to require explicit disabling of comment conditions when using job tokens
• Updates documentation and error messages to reflect support for multiple token types

Reviewed Changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
lib/resolve-config.js	Detects job token usage and sets appropriate token header
lib/verify.js	Adds job token validation and uses dynamic token headers
lib/publish.js	Uses dynamic token header for API requests
lib/success.js	Uses dynamic token header for API requests
lib/fail.js	Uses dynamic token header for API requests
lib/definitions/errors.js	Updates error messages to include job token information and adds new error for job token comment restrictions
test/helpers/mock-gitlab.js	Updates mock to handle both token types
test/resolve-config.test.js	Adds test for job token detection
test/verify.test.js	Adds tests for job token comment condition validation
test/integration.test.js	Adds integration test for job token workflow
README.md	Documents job token usage and limitations

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

There's an inconsistency in casing - the error message references 'successCommentCondition' and 'failCommentCondition' but the actual configuration options are 'successCommentCondition' and 'failCommentCondition'. Based on the test code, the correct names should be 'successCommentCondition' and 'failCommentCondition'.

Suggested change

	details: `When using a [job token](https://docs.gitlab.com/ci/jobs/ci_job_token/), [successCommentCondition](${linkify('README.md#successCommentCondition')}) and [failCommentCondition](${linkify('README.md#failCommentCondition')}) must be explicitly set to \`false\`, as job tokens do not have permissions to comment on issues and merge requests.
	details: `When using a [job token](https://docs.gitlab.com/ci/jobs/ci_job_token/), [successCommentCondition](${linkify('README.md#successcommentcondition')}) and [failCommentCondition](${linkify('README.md#failcommentcondition')}) must be explicitly set to \`false\`, as job tokens do not have permissions to comment on issues and merge requests.

[fgreinacher]

This feels quite hacky. Is there no better way to check job token read/write permissions? Maybe GraphQL API?

[tachyons]

@fgreinacher I don't think we have one at the moment, The only reliable way I know at the moment is dry run of git push

#859 (comment)

[fgreinacher]

@tachyons I'm really struggling with this due to all of the limitations with the job token. Please give me some more days to think about it 🙇

[fgreinacher]

Sorry this took so long @tachyons.

I'm fine to go forward with the job token, but I'd like this to be a more conscious decision of the user so that they are not surprised by the limitations. What do you think about introducing a dedicated configuration option for "opting in" to the job token instead of just reusing the existing variable? We might also use the same option to disable unsupported features like issue/MR comments.

[arvest-bjoneson]

@fgreinacher

I might potentially argue that the user is already explicitly "opting in" by manually assigning either GL_TOKEN or GITLAB_TOKEN the value of the CI_JOB_TOKEN. The upstream semantic-release project already inherently supports this, as the git client does not require any special headers when using a job token.

IMHO, with the error messages and documentation changes introduced by the this PR, the user is made directly aware of the limitations (specifically around comments), and asked to explicitly disable them when using the job token.

I believe it may actually be more confusing to allow these other properties to be set, and disabled transitively by some other configuration flag like "useJobToken: true" or something.

At present, the code in the PR will automatically determine if a job token has been assigned (which again, a user must explicitly do), and invoke logic which provides clear feedback to the user on the limitations through error messages if they do not read the documentation.

It would be relatively trivial to add a boolean config property, like useJobToken, however the user would still be required to read error output and/or documentation to understand what the implications of doing so are. I believe such a property would be redundant to the signal the user is already providing by having to explicitly assign a job token to one of the existing token variables.