fix(resolve-config.js): use the env CI_JOB_TOKEN for the gitlab token

[mmuenker]

This merge would resolve issue #156.

If the env GL_TOKEN and GITLAB_TOKEN are not defined the env CI_JOB_TOKEN would be used.

With the usage of the env CI_JOB_TOKEN the user who triggers the pipeline would also be the author of the new tag and release. This could cause some permission problems if the user who triggers the pipeline has not permission to create tags or/and releases.

[MRigal]

@mmuenker Although tests pass, this won't work as the CI_JOB_TOKEN does not have push rights on the repository to push the tag. Only release creation is permitted. See https://docs.gitlab.com/ce/api/#gitlab-ci-job-token

Here an example of output using CI_JOB_TOKEN

'EGITNOPERMISSION',
  details: '**semantic-release** cannot push the version tag to the branch `semantic-release` on the remote Git repository with URL `blabla`.\n' +

[EvanCarroll]

@MRigal While not ideal, I don't see why that should hold up this patch. Currently there is nothing stopping you from explicitly providing a token that doesn't have access to the repository. Why should we stop a fall back from the same thing?

Also the GItLab Release API creates the tag for you if tag_name doesn't exist and ref is set. It would seem this would be easy to do, I think we would just have add ref

[MRigal]

@EvanCarroll you may read the original issue https://github.com/semantic-release/gitlab/issues/156

Since the Gitlab Job Token does not allow to push, it's not possible to push version changes or tags to the repo. So the PR is a nice try but pointless, as Gitlab is too restrictive here

[gdraganic]

@MRigal It isn't pointless in case of SSH auth to the repository which handles writing to repo and pushing tags. If CI_JOB_TOKEN could be used for auth to Releases API, Personal Access Token can be avoided. This gives us two security benefits:

1. SSH key only has write access to the project repository
2. There is no long living PAT with full api and repository:write access

Also worth mentioning that Gitlab API auth uses JOB-TOKEN header instead of PRIVATE-TOKEN for auth with CI_JOB_TOKEN.

[EvanCarroll]

@MRigal It isn't pointless in case of SSH auth to the repository which handles writing to repo and pushing tags. If CI_JOB_TOKEN could be used for auth to Releases API, Personal Access Token can be avoided. This gives us two security benefits:

1. SSH key only has write access to the project repository
2. There is no long living PAT with full api and repository:write access

Also worth mentioning that Gitlab API auth uses JOB-TOKEN header instead of PRIVATE-TOKEN for auth with CI_JOB_TOKEN.

My fork supports this, fyi.

[flickerfly]

Looks like there is more activity around this idea in #1729. https://github.com/semantic-release/semantic-release/issues/1729#issuecomment-1354472875

[fgreinacher]

I'm closing this PR because it is not sufficient without changes in semantic-release core. Let's reconsider after https://github.com/semantic-release/semantic-release/issues/1729 is solved.