Handle expired GitLab Group Access Token

[JuJup]

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

GitLab

Please tell us more about your question or problem

It's clearly said in the docs:

To keep using the same GitLab-generated bot account you must rotate/refresh the Group Access Token before the token's expiry date.

Lesson learned, next time I will rotate the token before it expires, but now it happened and I need to create a new token. So far no problem.
But as far as I understand, this will lead to new Dashboard Issues in all Repos and some problems with already existing MRs.

There was a detailed discussion when optimizing the docs. However, no info about that handling was added to the docs and I can't draw any recommendations for action out of the discussion.

As stated there, the ignorePrAuthor option could help, but that's not clear to me either. I don't want this option to be enabled to avoid pulling all MRs, but will a one-time run with the option enabled solve the problem of a new botname? In my understanding, it will respect the MRs from the previous bot, but can't change the author there..

What do you think is the suggested way here? And maybe it's worth putting the results of this discussion into the docs as well? :)

Logs (if relevant)

No response

[adam-moss]

You can still rotate a token that has been expired, it is only when it is revoked you can't.

[JuJup]

Do you know, how long expired tokens can be rotated before they will be deleted by GitLab?
I listed my group tokens via API, but can't find the expired token..

[JuJup]

However, our GAT seems to be gone, so I guess the associated Bot User is lost as well.
And I guess it would be nice for Users to have some information on how to migrate to a new Token. I think it would be the same way for users that e.g. used PAT before and want to change to GAT.

[adam-moss]

I'm not sure how long they're retained for, but on the api you need to include state=inactive to see them.

https://gitlab.example.com/groups/:id/access_tokens?state=inactive

[JuJup]

Yes I know, I tried that of course. But no, can't find the token anymore :(

[JuJup]

@adam-moss, you got any recommendations for a token migration?

[rarkins]

There's a couple of approaches to migration which Renovate could take:

1. Support a limited number of different identities, e.g. current-bot, old-bot, oldest-bot. This way we'll never get it wrong, but it could increase API use/slow down Renovate having to query 2 or 3 times instead of 1
2. Support "unlimited" identities where we don't filter Issues or MRs at all based on author. This increases the chance we get something wrong (e.g. autoclose a Developer MR) but is less complex/slow

We already have the config option ignorePrAuthor which does (2) above. For GitLab specifically it means:

• We fetch all MRs from the API, instead of only those "created by me". We'll autoclose only those with the 1branchPrefix set
• We fetch all Issues from the API, instead of only those "created by me". It usually doesn't cause a problem but if a user created an Issue called "Dependency Dashboard" then we'd potentially take it over

[JuJup]

Thanks for the clarification.
However, this would mean, we'd need to leave the ignorePrAuthor option on forever, as the author of an issue can't be changed, correct?

So a valid migration path would be:
-> Enable ignorePrAuthor for some weeks, until all open MRs from the old Bot are merged or closed
-> Then disable the option
-> a new dashboard issue in each repo will be opened
-> manually close the old dashboard

Only downside would be, that Renovate wouldn't be able to detect closed MRs that should ignore or block certain updates. Am I missing something?

Not perfect, but I guess that's something one has to live with when the token was forgotten to rotate.

[rarkins]

Thanks for the clarification. However, this would mean, we'd need to leave the ignorePrAuthor option on forever, as the author of an issue can't be changed, correct?

Forever, correct.

So a valid migration path would be: -> Enable ignorePrAuthor for some weeks, until all open MRs from the old Bot are merged or closed -> Then disable the option -> a new dashboard issue in each repo will be opened -> manually close the old dashboard

Only downside would be, that Renovate wouldn't be able to detect closed MRs that should ignore or block certain updates. Am I missing something?

Yes that's right. If you removed the setting then you'd immediately see closed/ignored MRs reopened.

Also don't forget that any existing issues would now get duplicated. The existing ones created by the old bot would be frozen in time, while the new bot would then create and keep updating duplicates.

[rarkins]

You could perhaps run a script which closes all the issues by the old bot identity. The new bot will recreate them anyway.