GitLab Token Permissions and Expirations Gotchas

NEVER AGAIN. NO MORE EXPIRED TOKENS.

Here’s a hypothetical senario: Suppose one repository you own only has 2 project access tokens. You might think it’s a simple task to update them when they expire once a year.

But with 6 or more repositories, you would have to take care of the expiration date every single month on average. It’s quite annoying, isn’t it? That’s what got me looking for a better alternative.

The Goal & The Problem

The flow goes like:

0. Developer pushes modification.
1. if codebase isn’t formatted yet, it’ll get formatted, pushed and fired another pipeline.
2. build & test.

As mentioned, the group access token expires every single year. We need an alternative token that:

• able to push codes
• won’t expire
• can trigger another pipeline

No Project Access Token, then What Would be Next?

Sadly, there’s no any token meets the three conditions at once. [1] Nevertheless, I still came up with a tricky solution: use ci job token and pipeline trigger token together. Features for each of them are listed below:

• ci job token: [2]

  • Its lifetime is as long as a ci job, so never worry about expirations.
  • Can push codes to repo.
  • Cannot trigger another pipeline (even when pushing to the repo).

• pipeline trigger token: [3]

  • Literally trigger a pipeline.

With careful selection, a better cooperation looks like:

So far, we have a nice non-expiring CI mechanism.

Not Really. And that’s not even the worst part.

What if we have to work with a GitLab whose version is lower than v18.3 [4] ? ci job token won’t be able to push codes at that time. In that case, we would have no choice but expirable tokens (ex. project access token, personal access token, etc.).

Hell no! The only thing we can do would be listing critical CVE of old GitLab versions and urging IT to upgrade 😆