Support for generic git servers

[mmlanger]

Most CI systems limit their use to very specific platforms (e.g. GitHub), while the setup (probably always using webhooks?) can be "easy" but is very specific and maybe even different from forge to forge.
In Concourse I discovered that there is another way that is more generic, their git resource clones the repo and pulls for updates in a regular time interval. The access can be easily set up with a Deploy Key or account credentials, which makes concourse extremely accessible to all kinds of forges.

For one of my projects, I managed to make a setup that deploys a whole functional CI pipeline on kubernetes from a repository (which could be on any forge that provides a Deploy Key feature) where I just have to provide the key file and the address of the repository.

Could a similar feature be integrated into Woodpecker? This could mark a significant advancement by offering a more generic, forge-agnostic method for CI capabilities, setting it apart from other modern CI systems that often overlook this flexibility. While I understand that such a method might not support certain features like pull request triggers via webhooks (potentially diverging from the traditional Woodpecker workflow) I believe the trade-off for increased accessibility and simplicity could be worthwhile.

This approach could significantly lower the barriers to entry for projects looking to adopt CI practices, making Woodpecker an even more attractive option for a wider range of development workflows.

[qwerty287]

We had that question multiple times before (ex. #2651).

The short answer is: No, we won't add support for it, but there's an add-on feature that allows you to integrate whichever "forge" you want.

Woodpecker does not only use the forge as git hosting and to trigger webhooks, there's more. If the forge's tasks are that simple, you dont need that much specific code except webhook handling. If you don't want to have webhooks you could also ignore them - pipelines can be started manually or with cron tasks. If you're fine with the missing features that's not a big problem.

However, the core problem is authentication. We use the forge for OAuth2. If you don't have a problem with that missing too or if you have a good alternative, nothing stops you from developing your own forge.

We won't add that to our core though to have some "quality" of the forges we support out of the box. They should provide an all-in-one solution without much configuration effort. But add-on forges should be able to support the same features as core forges would.

If you understand this and would go with the add-on approach (if you would need help implementing just ask): There's a reason why I don't link you to the docs for addons, as we/I currently have a complete refactoring of the add-on feature (see #3268). This should hopefully land in 2.5.0.

What do you think about this?

[mmlanger]

Thank you very much for the explanation, I'll continue to watch Woodpecker and will get in touch again If I see some oppurtiny.