Renovate: GitLab Hosted Oauth App

[rarkins]

• Users will register for the hosted App by signing in with GitLab OAuth to https://renovatebot.com/dashboard

• Users will be able to enable (one by one) any repo they have write access to (see below re: webhooks though)

• Logs/status will be viewable via Dashboard like with GitHub

Differences:

• In the GitHub App, Renovate can use its own "bot" account/token to perform all actions, but in GitLab there is no concept of a bot account

• If using the OAuth token exclusively, it means all actions look like they come from the own user's account (could be confusing).

Ideas:

• Users could optionally add the GitLab @renovate-bot account as a Developer to projects to enable it to create each commit/branch/PR itself

• Need to consider webhooks. Probably could be done if a Maintainer or Owner enables the repo

[Jamesking56]

Users could optionally add the GitLab @renovate-bot account as a Developer to projects to enable it to create each commit/branch/PR itself

This is what I do currently, I made another user which I add to each project I want renovate to use.

[rarkins]

I've been thinking about using renovate-bot for all repos over the weekend and it seems like the better way to go. If you didn't support adding renovate-bot directly then either:

(a) You would use your own token and then branches and PRs would confusingly look like they came from you (person) and not the bot. Also this increases the chance of confusing the bot, e.g. if you (person) make edits to the bot's branch then how can it tell which were bot-created and which not?

(b) You would need to create a dedicated bot account like you've done and use it instead, so we end up with 100s of separate Renovate Bots on gitlab.com

Also GitLab have confirmed that there is no per-user rate limiting and only per-IP, so it doesn't make a difference whether the hosted app is rotating user tokens or just using its own.

[hutson]

You would use your own token and then branches and PRs would confusingly look like they came from you (person) and not the bot. - @rarkins

This is what I have done in the past. I haven't found it too confusing, but then I am the only maintainer on my projects. On large, shared, projects, yes, I imagine this being an issue. People will assume you filed the PR. They will expect you to merge it. They may even post comments asking for your clarification, which will distract from your other work.

[rarkins]

FYI here is the progress so far:

• [x] GitLab's @renovate-bot has been set up as the dedicated bot account for the app. This way we never need to store user OAuth2 tokens on our server side.
• [x] Renovate will run hourly on any repo it has Developer access to
• [x] The Dashboard supports logging in with GitLab now and viewing logs for any repository you have Developer or greater access to
• [x] Updates from npm about newly upgraded packages should trigger an immediate job like is done for the GitHub App
• [x] Create webhook handler to receive/parse webhooks from GitLab.com and queue jobs
• [x] Add dashboard code so that webhooks are automatically created/sync'd (requires Maintainer privileges)
• [x] Add dashboard UI + code to support administering installed repos (installing/uninstalling)

In other words, if you manually invite @renovate-bot to be a Developer on your project today, your repo will be checked hourly as well as whenever any of your npm dependencies receive an update on npmjs.org. You just won't see "interactive" updates yet such as immediate rebases if you rename a PR or apply the "rebase" label.

[rarkins]

@hbetts I noticed that you added Renovate Bot and it's discovering your repos however I think the extended naming is probably throwing it off, e.g. hyper-expanse/open-source/configuration-packages/eslint-config. Previously everything has assumed owner/repo terminology so I probably need an enhancement to get it to work.

[hutson]

@hbetts I noticed that you added Renovate Bot and it's discovering your repos

I thought I'd give it a try since your check list seemed to indicate support was good enough for my particular needs.

it's discovering your repos however I think the extended naming is probably throwing it off

I'm sorry. Should I remove renovate-bot from my repository for the time being? (On a related note, renovate, the package, does correctly work with multiple GitLab sub-groups in the path, which is why I assumed it would work through the bot as well)

I am encountering one _minor_ issue. I have several merge requests created by the renovate tool using my personal access token. The renovate-bot service does not seem to like that. It keeps posting that the merge request has changed.. I think I can just close my merge requests and let the bot open its own.

[rarkins]

@hbetts it's totally fine/ready for you to use, and in fact it's preferred for me to get some real use on GitLab.

And yes Renovate itself works fine with the sub-groups: the problem was actually in my "next job" SQL call which I fixed in the backend.

Finally, I noticed the comment bug and fixing it now. It's actually because of how we massage PR to MR in GitLab PR and comment bodies. Unfortunately it's comparing unmassaged to massaged right now, so it keeps missing the old ones and creating new ones. Nothing to do with different users and will be addressed soon.

[hutson]

Add dashboard code so that webhooks are automatically created/sync'd (requires Maintainer privileges)

This particular item is on my mind since I use _Maintainer_ as a requirement to access protected branches and tags. It provides some measure of protection from providing a bot account full permissions over projects within my GitLab group.

Are there any outstanding GitLab issues looking into how to created scoped access where a user or token can be added that limits API permissions to specific actions, similar to GitHub Apps or tokens?

[rarkins]

@hbetts it's possible I confused you with how I described it. You won't ever need to add Renovate Bot as a maintainer to projects - only as a developer. But as a maintainer yourself, you will need to log in/access the dashboard so that your OAuth2 token can be used to set the webhook for the project. It's still my intention that:

• Renovate Bot needs only be a Developer
• User Oauth2 tokens are never stored/cached on the server, just used transactionally to prove you are who you say you are

[hutson]

@hbetts it's possible I confused you with how I described it.

I definitely misunderstood what you were saying :sweat_smile: , so I really appreciate you clarifying your points with me. :smile:

In that case, I don't have any concerns, or feedback, on the current approach :+1:

[rarkins]

The hosted GitLab app can now be considered to be in "full beta" as features are complete. For details, see https://renovatebot.com/docs/install-gitlab-app/

[renovate-bot]

:tada: This issue has been resolved in version 13.123.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: