Docs: deprecate deploy tokens for Gitlab or clarify use in docs

[skycaptain]

Tell us more.

Deploy tokens are limited to this scope. However, the docs suggest that deploy tokens are a suitable way of defining RENOVATE_TOKEN. This is misleading because deploy tokens lack read_api and api permissions.

[viceice]

feel free to send a PR to fix it 🤗

[HonkingGoose]

Before creating a PR, let's get some more info! 😉

---

Hi @mbrodala 👋

You added the info about Deploy tokens to Renovate's GitLab Authentication docs with this PR:

• docs(platform/gitlab): Mention Deploy Token #30042

But a user says that the Deploy token is bad for RENOVATE_TOKEN, as it lacks the read_api and api permissions.

Can you tell us how you're using the Deploy token? Are you maybe setting extra permissions in some config file? Or doing something else to get it working?

Thank you! 😄

[skycaptain]

I think it's mentioned in the PR between the lines: Registry authentication works with a deploy token. Thus, a deploy token could work for a host rule but not as a general alternative for a PAT or GAT. For example, a deploy token cannot create a MR nor push to a repository on GitLab.

Maybe, I could have added more context on what I find misleading:

First, the docs starts with this correct sentence.

You can authenticate Renovate to GitLab, with a Personal Access Token, or Group Access Token.

BTW. Project Access Tokens are also an valid option and work similar to _Group Access Token_s, except for being limited to just one project.

But then continues:

To start, create either:

• a Personal Access Token for the bot account
• or a Group Access Token for the bot account
• or a Deploy Token for the bot account

which is wrong as Group Access Tokens and Deploy tokens are independent of user accounts (ref, ref), and thus can not be created for the bot account, while Personal Access Tokens can. However to be precise, creating a Group Access Tokens or a Project Access Tokens creates a bot account on-the-fly in the background.

Then the docs continue with the part I find misleading as this only works for Personal Access Token, Group Access Token and Project Access Tokens:

The bot account must have at least the Developer role in order to create issues and merge requests. If you are using automerge, the bot account must have the appropriate "Allowed to merge" permission on the protected branch of your projects. If merging is restricted to Maintainers, the bot account must have the Maintainer role.

I propose to:

• remove mentioning Deploy tokens in the above paragraph and mention them in the paragraph that starts with If you're using a private GitLab container registry, you must:
• mention Project Access Tokens in the above paragraph
• rephrase the wording as Group Access Tokens and Deploy Tokens are not related to user accounts

I volunteer to create a PR.

[HonkingGoose]

Please open a PR so we can review in context. 🙂

[skycaptain]

#30787

While writing, I also came across GitLab bot security, which has similar content that is largely outdated. I guess that requires another discussion/PR.

[HonkingGoose]

I'm thinking of getting permission from the author to get a better article into the docs:

• Pull in blog post about secure and scalable Renovate service on GitLab? #30446

Im waiting for the go-ahead from the Renovate maintainers to ask the author. 🙂

Do you want to read the article I'm thinking of pulling in? And tell me if the article is better than what we have now? 🙂