Callback Endpoint for workflow environments

[6543]

as noted in #2935 (comment)
#2291 (comment)
and in lot of other issue/pull comments.

we need an other way beside the stdout to communicate with the agent to send/recive optional information:

• create optional UI
• expose in/outputs
• get additional infos

so I propose to expose an api via some socket (unix socet or udp/tcp ...)

And indicate that via some env var

a brain dump can be found here: #2953

[lafriks]

I like the idea, probably Rest API to be more easily usable even from curl etc?

This could be potentially used also to upload pipeline files as build artifacts

[6543]

well as for Unix Sockets curl can do so too :D
so I would let it be a backend specific dessision if it's a tcp or unix socket

[6543]

-> for docker we can easily create a unix-socket and mount it via volume option into a container, so we dont have to worry about the network setup.
-> for local backend a tcp server might be best (works on windows too) and workflow-network == host-network (localhost)

[lafriks]

But that would not work if the pipeline is run on a different server than woodpecker server 🤔

[6543]

well that's the whole point ... I proposed that the agent is doing that server and forward it to the server via grpc

as you could have setups where the agent can only reach the server via grpc (is an edgecase but doing so streamlines the responsibility)
and for other optional features the token is proposed to be also valid for the server api

[zc-devs]

How the socket supposed to be working on Kubernetes?

I'm lost, what connection you are trying to achieve?
Container/step -> Server? There are REST and gRPC already. I vote for REST as it's simpler for client: "Rest API to be more easily usable even from curl".
Container -> Agent? There is gRPC already.