Use CI JOB TOKEN to push code #901
Conversation
Any update on this, as this is a blocker for us as well? |
There was a problem hiding this comment.
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-TOKENvsPRIVATE-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.
|
|
||
| EJOBTOKENCOMMENTCONDITION: ({projectPath}) => ({ | ||
| message: 'Invalid comment conditions using job token.', | ||
| 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. |
There was a problem hiding this comment.
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'.
| 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. |
Copilot uses AI. Check for mistakes.
| ) { | ||
| errors.push(getError("EGLNOPUSHPERMISSION", { projectPath })); | ||
| if (isJobToken) { | ||
| await got.get(urlJoin(projectApiUrl, "releases"), { headers: { [tokenHeader]: gitlabToken } }); |
There was a problem hiding this comment.
This feels quite hacky. Is there no better way to check job token read/write permissions? Maybe GraphQL API?
There was a problem hiding this comment.
@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
|
@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 🙇 |
There was a problem hiding this comment.
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.
GitLab now supports git push authenticted using CI JOB token. This PR update the authentication logic to also support CI JOB TOKEN when available.