Currently, in order to trigger a pipeline for a project, I must generate a token. For each project a different token. If I have a big application that has a lot of dependencies and say make a script for auto triggering pipelines each developer should have acces to such a token for each project.
Couldn’t it be possible to trigger a pipeline through my Personal Authentication Token? So, every developer would manage a sinlge token, namely their own.
Looking at the history of the API, this look like technical debt. It was created in 7.14 and required creation of a token as an explicit action. In 9.3 usage of a manage token for CI was added, but still using the token parameter. In 11.5 they added the ability to get artifacts by this same job token while also allowing usage of a user’s private token (although in an annoying separate header).
I think the API here needs some probably easy updates to also allow a user’s private token for these actions.
As an enterprise customer of theirs, I’m in the process of creating a GO executable to wrap some common CI job actions for cross project pipelines. My first step was to implement the artifact fetching and it was very nice that normal users could also use the tool to fetch artifacts on their local machines with the same tool. When going to the trigger aspect though, it was pretty ridiculous to see a piece of API that doesn’t utilize a user’s personal access token for authorization. Again though, this seems to be a bit of easily resolvable technical debt since the feature was all the way back from 7 series of GitLab.
This just highlights one of my chief concerns when it comes to GitLab the company and product. They seem more focused on new features that making the features they have better or even on par with new functionality (as this case). This is creating a bad user experience and makes we wonder about investing any significant amount of effort into creating an ecosystem for my internal developers (or myself) around the product.