Support Gitlab without requiring Personal/Project Access Tokens

Goals

As a Gitlab user who wants to use Pipelines as Code, I currently have to create an access token to enable PaC to operate on my repo. This is less convenient than the Github flow, where my cluster administrator can provide a Github app for me that I just install in my repo. No access tokens involved. One slightly larger inconvenience is that gitlab now requires an expiry date on all tokens and doesn't allow more than one year of validity. This means I have to rotate the token regularly.

The goal would be for PaC to support a token-less workflow for Gitlab, ideally similar to the Github workflow.

Requirements

• • (Optional) Use Cases

• • Konflux administrators will be able to set up something that will then allow...
  • Konflux users to onboard Gitlab-based components without having to create (and regularly rotate) PATs
  • (same for other PaC users, but the request is coming from Konflux)

Out of scope

<Defines what is not included in this story>

Dependencies

< Link or at least explain any known dependencies. >

Background, and strategic fit

< What does the person writing code, testing, documenting need to know? >

Assumptions

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Customer Considerations

< Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

Documentation Considerations

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

What does success look like?

< Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

QE Contact

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Impact

< If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

<links>

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment