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.
@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.
I might potentially argue that the user is already explicitly "opting in" by manually assigning either 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 |
|
@arvest-bjoneson I get your point, but the job token does have quite some limitations. Going forward we might add more functionality to the gitlab plugin that does not work with the job token. I want to make very clear that using the job token imposes several restrictions. So to move this forward I kindly ask for two changes:
@tachyons Are you still able and willing to work on this? If not I'll try to take care in the next 1-2 weeks. |
|
@fgreinacher that sounds fair. If @tachyons is unable to respond, I'd be willing to take a crack at this over the next couple of days. Most of the changes are from a branch I had originally created. |
4 participants
GitLab now supports git push authenticted using CI JOB token. This PR update the authentication logic to also support CI JOB TOKEN when available.