Many-to-one account map

[cmelone]

Problem/Opportunity Statement

Hubcast users/admins may want the capability to perform actions as a bot user on behalf of contributors. For example, a spackbot user on the destination forge would be responsible for pushing new changes, managing webhooks, etc. For large projects and infrastructure that do not require strict checks to execute new code (ie the Spack CI farm), this is an alternative to using an account map.

There are a couple ways to go about this:

1. a bot user is designated for the entire Hubcast instance; all repository actions on the destination forge are performed by the bot. account map functionality would be effectively disabled.
2. individual projects get to choose the scheme. ex: project A wants to use an OAuth account map between Github and Gitlab, but project B is fine using a bot user. This would be a bit more difficult to implement, and I don't know if this feature would be useful. The bot user in option (1) is intended as a safe keeper of the infrastructure available on the source forge, and that dynamic doesn't change on a per-project basis.

Implementation nuances for option (1):

• the bot user would need to be granted "maintainer" access to each repository; otherwise, the initial webhook setup for a repo won't work. this can be done on an Gitlab instance basis, but just needs to be documented.
• admins of the Hubcast instance should create a PAT for the bot user with r/w access to all repos. this will be stored as an env variable HC_GL_TOKEN, with the admin being responsible for rotating.
• downscoping/impersonation tokens should not be used in combination with this feature (there is only one user to impersonate, and better to have one token defined than one being created for every use).

something else I want to do:

• rename the single token type to service_account

[cmelone]

https://docs.gitlab.com/user/profile/service_accounts/

[cmelone]

some notes I had on the service user approach:

if you are attempting use hubcast to sync to GL forges without admin access, a service account with sufficient permissions will work

---

1. Service account: without admin access to the destination forge, a service account is the only way to ensure consistent access to multiple repositories.

Create a new account on the destination and generate a personal access token with the api, read_repository, and write_repository scopes. When adding this account to repositories and groups, ensure that the user has the Maintainer role (needed to manage webhooks).

Be aware that the service account will have complete access to the repositories it is added to. This means that any user in the account map will be trusted by Hubcast to perform changes to the repositories. This can be mitigated by strictly limiting the members in the account map or managing a Hubcast instance (and service account) for each logical repository scope.

• if service user approach, account map will map to the service user rather than a user identity