Rework addons

[qwerty287]

This is actually more a personal to-do-note instead of a discussion. Feel free to comment if you have ideas, but don't expect me to answer this.

It looks like there is no maintainer except me who supports the current system, which I can understand to some extent.
The current plugin system is based on Go's internal plugin system which has some issues:

• limited OS support
• they must be written in Go
• compiled addon files are pretty big as most of Woodpecker itself is compiled into them
• specific to Woodpecker version
• you must compile it directly from the same code (see How to setup a Woodpecker (forge) addon #3266 (reply in thread))

The only alternative to it that's mature enough is afaik https://github.com/hashicorp/go-plugin.
It fixes all these issues above if you use it correctly.
It's much harder to use it though cause you can't use it with complex types (it's hard already to use structs in returns and arguments) and you must specify gRPC interfaces manually.
I need to investigate more research here.

[zc-devs]

you must specify gRPC interfaces manually

RPC between addon and core or Agent-Server gRPC?

---

Suppose, mzampetakis built forge addon, clarfonthey built libvirt backend and someone built addon for encrypted secret store. I want to use all of them.
Can I make it with current go modules system? Can I make it with Hashicorp system?

[qwerty287]

RPC between addon and core or Agent-Server gRPC?

Addon <-> core (hashicorp go plugins support both RPC and gRPC)

Can I make it with current go modules system?

Yes.

Can I make it with Hashicorp system?

I didn't try, but I don't see a reason why it wouldn't work. Also, you can compile multiple Hashicorp plugins into one binary, so this should definitely allow your usecase (yes, I know this has a lot of downsides, but in theory it works).

[anbraten]

One thing I noticed when thinking about the config api again ist that we should probably decided how we allow admins & maybe users to use plugins. For forges I think this approach makes sense. The previous approach using go-plugins seemed to be already causing some issues, but using pure http seems a bit off for sth deeply integrated as forges are currently.

For sth like config, secrets & registries it would be nice to allow repo / org admins to use their own plugins. We could allow grpc for that as well, but I actually think the http approach similar to the config-api as I started it months ago in #915 could be better suited and would be easier for developers to implement?

[qwerty287]

deeply integrated as forges

Secrets, registries etc. are also deeply integrated, I don't really see a difference here.

similar to the config-api as I started it months ago in #915

For repos, I think this should be done with http as there isn't really another way.

For global config, I prefer RPC for all types.

it would be nice to allow repo / org admins to use their own plugins

Indeed, but what's the issue with this? It should be pretty easy to do this with RPC.

would be easier for developers to implement

I don't think so. You only need to implement the functions as RPC functions instead of http endpoints.

[anbraten]

Indeed, but what's the issue with this? It should be pretty easy to do this with RPC.

We used http-signatures to prevent malicious systems from accessing the config plugin. We would need sth similar for RPC. RPC often needs extra config for reverse-proxies making it harder to deploy such a plugin. For an instance like codeberg users would need to host their plugin with a public url accessible by the codeberg server somehow, but not usable by other systems.

For repos, I think this should be done with http as there isn't really another way.

In that case we would have to support both? What if we do /hashicorp/go-plugin for forges and similar as they will receive other possibilities / permissions and require a different trust factor.

And for config, registries and secrets we could use http for repo, org and global plugins?

[qwerty287]

For an instance like codeberg users would need to host their plugin with a public url accessible by the codeberg server somehow, but not usable by other systems.

Hashicorp plugins can only be used with locally available files. They should only be exposed to the woodpecker server.

And for config, registries and secrets we could use http for repo, org and global plugins?

This could be possible, but in this case it would be kind of "splitting" the whole approach again: We have RPC for forges, but http for everything else.

Also, hashicorp plugins can be used with bidirectional communication which can e really handy. It could be possible to e.g. remove native support of secret encryption and move it to a plugin instead.

I don't really know what the best way is.

I mainly don't want to have inconsistencies. The only way I currently see to merge the approaches is the following: Forges (and everything else that is implemented with RPC) are configured with env vars, while everything using http is done in the ui. This way, we differentiate between RPC and http plugins.

What do you think about this?

[anbraten]

Hashicorp plugins can only be used with locally available files. They should only be exposed to the woodpecker server.

Yip, then we can't use Hashicorp plugins for 3rd party plugins which could be configured on repo level?!

This could be possible, but in this case it would be kind of "splitting" the whole approach again: We have RPC for forges, but http for everything else.

For forges I see how they might need deep integration with 2 way communication. For supporting sth like #915 and https://github.com/drone/drone-vault, none of the alternatives before seemed possible?

For secrets and registries for example 1-way communication should be fine: list all secrets, get secret, create secret, update secret & delete secret. This is how drone seems to solve it: https://github.com/drone/drone-go/blob/master/plugin/secret/secret.go

I mainly don't want to have inconsistencies. The only way I currently see to merge the approaches is the following: Forges (and everything else that is implemented with RPC) are configured with env vars, while everything using http is done in the ui. This way, we differentiate between RPC and http plugins.

Yes, forges should be configured via env vars (at least for now til sth like #1417 would only admin allow to configure it via UI). For the (secrets, registry, config) I think the approach from #915 with the default implementation integrated in the binary and possibility to replace it using a http plugin configured via UI on repo or org level would work quite well.

[qwerty287]

For the (secrets, registry, config) I think the approach from #915 with the default implementation integrated in the binary and possibility to replace it using a http plugin configured via UI on repo or org level would work quite well.

Yes, this would work for me. We should remove global support for the http service in this case/move this config to the admin ui.

Would be nice if you could finish #915 if you have the time :)