Summary

Runner is registered using both API Token/User Password and registration token currently. But token can be queried via API + Project/Group (id or path). Using the already provided fields (+ maybe one extra field to allow/disallow querying the token automatically) nothing needs to be changed at interface/task level.

Pros:

• Easier to use and enhances readability as it specifies to which group/project the runner belongs
• Avoids redundancy for something that can be retrieved automatically
• Avoids specifying and storing an extra secret

Cons:

• Do not see any

Issue Type

Feature Idea

Component Name

gitlab_runner

Additional Information

Gitlab allows registering runners via API (+ queried token) or just the token. Querying information, updating or deleting runners only works via the API, afaik. Since we have to check presence before doing any modifications, we need the API access anyway.
Currently (according to the doc) the id/path is only used for filtering runners, but can be used for querying the token as well.

Querying https://gitlab.example.com/api/v4/groups/my%2Fsample%2Fgroup https://gitlab.example.com/api/v4/proejcts/my%2Fsample%2Fproject may return (special json chars omitted for readability):

id: 1337
....
runners_token: secretToken

In the case the token is not specified in the task the new flow would be:

• Query runners and check presence/need to create or update
• Since token is not specified query token via group (if not disabled)
• Register runner with retrieved token

In the case the token was specified the flow remains the same and it need not be queried.

Maybe I have time to take a shot at implementing it, whoever is faster be my guest.

Best Regards

Code of Conduct

• I agree to follow the Ansible Code of Conduct