Can't use TOKEN with a project with group permissions

[hlas]

Get this error:

[4:11:51 PM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlab.com/api/v4)
[4:11:51 PM] [semantic-release] › ✖  Failed step "verifyConditions" of plugin "@semantic-release/gitlab"
[4:11:51 PM] [semantic-release] › ✖  EGLNOPERMISSION The GitLab token doesn't allow to push on the repository *******.
The user associated with the GitLab token (https://github.com/semantic-release/gitlab/blob/master/README.md#gitlab-authentication) configured in the GL_TOKEN or GITLAB_TOKEN environment variable must allows to push to the repository *******.
Please make sure the GitLab user associated with the token has the permission to push (https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions) to the repository *********.

This is what I get with a direct call to the gitlab API:

curl --header "Private-Token: ***********" https://gitlab.com/api/v4/projects/****
[...]
  "shared_with_groups": [
    {
      "group_id": *****,
      "group_name": "*********",
      "group_full_path": "****",
      "group_access_level": 40,
      "expires_at": null
    }
 [....]
  ]
  "permissions": {
    "project_access": null,
    "group_access": null
  }

So, this code doesn't verify correctly the permissions: https://github.com/semantic-release/gitlab/blob/cfa2f177d866addb4618a6e0cd3aaeed1f70bf7e/lib/verify.js#L51

[nfriend]

@hlas Thanks for this! I was able to reproduce this as well in a test group/project.

My gut feeling is that this is a bug on GitLab's side - I expected this permission information to be available in some way through the Project API. I've opened https://gitlab.com/gitlab-org/gitlab/-/issues/290880 to investigate/discuss.

I'm not sure about the details of your setup, but perhaps using a project access token might be a workaround for you?

In lieu of solving https://gitlab.com/gitlab-org/gitlab/-/issues/290880, perhaps this module could test for permissions by attempting to push to the repository with the --dry-run flag instead of using project_access and group_access 🤔

[Sayrus]

Hey,

I'm having this issue. Following the issues lead me to https://gitlab.com/gitlab-org/gitlab/-/issues/223832 which was closed for inactivity but not fixed. Would you be open to a merge request to check shared_with_groups value in semantic-release as a workaround while waiting for a fix from Gitlab?

[fgreinacher]

Yes sure, thanks! I'm not sure though how shared_with_groups alone would help us determine push permissions.

[Sayrus]

Yes sure, thanks! I'm not sure though how shared_with_groups alone would help us determine push permissions.

As far as I can tell, it contains the info needed:

  "shared_with_groups": [
    {
      "group_id": 1,
      "group_name": "group-name",
      "group_full_path": "path/group-name",
      "group_access_level": 40,
      "expires_at": null
    }
  ],

From https://github.com/semantic-release/gitlab/blob/26d7f9f37e7f7b1904f1c6b48039132e95f872d9/lib/verify.js#L71, we only check access_level. Maybe I'm missing something since I only quickly glanced at the code. We'd probably need to fetch more about the PAT identity to see if it's a group access token/is in the group the project is shared with. Or the other way around: if the PAT user if a member of one of the groups the project is shared with.

[fgreinacher]

Yes shared_with_groups does not verify that the authenticated user is member of these groups, so we would need additional calls to determine the access level. I could imagine this become quite convoluted, so maybe we should rather consider @nfried's suggestion above:

In lieu of solving https://gitlab.com/gitlab-org/gitlab/-/issues/290880, perhaps this module could test for permissions by attempting to push to the repository with the --dry-run flag instead of using project_access and group_access 🤔

[Sayrus]

In lieu of solving https://gitlab.com/gitlab-org/gitlab/-/issues/290880, perhaps this module could test for permissions by attempting to push to the repository with the --dry-run flag instead of using project_access and group_access thinking

That makes sense, sending more requests will end up quite convoluted, harder to maintain and may even make things worse.

I've read the main repo's code and the code flow and maybe there is an even easier solution. Could we simply skip over this step and not check for push permission? Semantic release already does a git push --dry-run before calling verifyConditions.

https://github.com/semantic-release/semantic-release/blob/master/lib/git.js#L205

/**
 * Verify the write access authorization to remote repository with push dry-run.
 *
 * @param {String} repositoryUrl The remote repository URL.
 * @param {String} branch The repository branch for which to verify write access.
 * @param {Object} [execaOpts] Options to pass to `execa`.
 *
 * @throws {Error} if not authorized to push.
 */
async function verifyAuth(repositoryUrl, branch, execaOptions) {
  try {
    await execa('git', ['push', '--dry-run', '--no-verify', repositoryUrl, `HEAD:${branch}`], execaOptions);
  } catch (error) {
    debug(error);
    throw error;
  }
}

Which is called in the main: https://github.com/semantic-release/semantic-release/blob/4012f75386cced3c8806b7094f552cccc357b6f5/index.js#L85

Here are logs from a failing CI I have (first check from semantic-release/semantic-release, second from semantic-release/gitlab):

[10:58:42 AM] [semantic-release] › ✔  Allowed to push to the Git repository
[...]
[10:58:42 AM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlab.my-domain.com/api/v4)
[10:58:42 AM] [semantic-release] › ✖  Failed step "verifyConditions" of plugin "@semantic-release/gitlab"
[...]
[10:58:43 AM] [semantic-release] › ✖  EGLNOPERMISSION The GitLab token doesn't allow to push on the repository my-repo.

[fgreinacher]

Sorry for the late response.

I've read the main repo's code and the code flow and maybe there is an even easier solution. Could we simply skip over this step and not check for push permission? Semantic release already does a git push --dry-run before calling verifyConditions.

Generally this sounds feasible, but we might at some point want to get rid of that to enable use cases like #156 where the authenticated user cannot push, but can create tags via API.

What if we just verify by calling maintainer/developer-only API endpoints and see if they succeed, like in the description of https://gitlab.com/gitlab-org/gitlab/-/issues/223832?

[eugenberend]

Hi, is there no workaround for this issue? Our Gitlab access policy strongly prohibites giving an "extra" access to an individual repository, so this little bug makes the whole plugin unusable for us

[fgreinacher]

Currently there is no workaround for this.

Maybe we could use the GraphQL API to determine permissions: