Add support for multiple forges

[JensHeinrich]

Add support for running with GitHub and gitea for example

Idea:

• check if multiple providers are defined
• if so, use the solution for OAuth support for Gitea #136 to supply a login with $PROVIDER button and namespace the repositories $PROVIDER/ORG/REPO
• could even be extended with a $PROVIDER_PROVIDERS List, eg GITEA_PROVIDERS="DEVGITEA,PRODGITEA" and using these as new variable names DEVGITEA_OAUTHID=...

TODO

• add forges table Use forge from db #1417
• add id of forge to repo Use forge from db #1417
• use forge of repo Use forge from db #1417
• find repos based on id (slugs could be the same across forges) Access repos by their IDs #1691
• allow to login with all configured forges Allow login using multiple forges #3822
• add admin ui to add / edit / remove forges Set gitea-client and gitea-secret in web UI #425
• allow user to connect with multiple forges

[jdoubleu]

There are a few questions which came into mind, that also need to be addressed. To be fair, they slightly address an edge case where one user would like to connect multiple vcs servers (I think that's what they are called in the documentation).

• Going forward, how are the repositories displayed when the user is logged in? At the moment, the repository list only names org/repo. What if an repository exists with the same hierarchy on a different vcs server? Sure, internally it uses the $provider/org/repo structure, but how is that communicated with the user?
• How does repository synchronization work? Woodpecker would have to go through all remotes, the user is currently authenticated with, and fetch the repository list. How is the user shown which remotes were synced? Maybe the user forgot to login with some vcs server or their authorization token expired.

could even be extended with a $PROVIDER_PROVIDERS List, eg GITEA_PROVIDERS="DEVGITEA,PRODGITEA" and using these as new variable names DEVGITEA_OAUTHID=...

I fear that it introduces complexity on the configuration (env variables). It also introduces config "keys" (e.g. with DEVGITEA_ prefix), which are only valid in a special context, i.e. when GITEA_PROVIDERS="DEVGITEA" was given prior.

The alternative would be to store these information in the database and have the admin configure it through the web interface, right? One benefit of that approach I can think of would be to also have the flexibility to customize the given integration. The admin could add a name/title and maybe links to their privacy policy. The admin could also customize the "Login with Gitea" button to show e.g. "Login with Development Gitea @ Woodpecker Next".

However, I'm not sure what implications this might have, besides being harder to implement.

[anbraten]

I have started to get this feature in by changing the code in small steps #1418 #1417. First of all I will try to load the forges config from the database. The env vars will simply add a signle entry to the database if none with that url exists. To be able to load the forge from the database I will also add a forge-id to each repo.

Next step would be to load repositories via their woodpecker internal id and not by their slug.

After that we need to check how to use multiple forges at once. For the beginning we could say a user authenticates with a specific forge and that user is by that only seeing repos of a specific forge as well.

Later we could check if a user could do some kind of re-authentication with another forge to be able to see repos from multiple forges at once.

[wyatt-herkamp]

Instead of having an account for each forge. What about allowing an account to be connected to multiple forges?

Have a table of user_forges

type UserForge struct {
	ID int64
	// References a user
	USER_ID int64
	FORGE_ID: inti64
	// Other OAUTH Token Parameters
} 

For my purposes in woodpecker this would be easier to manage so I only have user account and don't have to swap accounts to change the pipeline in a different forge.

[anbraten]

That will be absolutely possible in the long term. For the beginning it however will be much easier to have 1user<=>1forge as a lot of api endpoints are not compatible with for example fetching repo details from multiple forges. I almost finished the login part (#3695 & main...anbraten:woodpecker:forge-login)