Provide a separate WOODPECKER_GITEA_API_URL for easier local setup

[everflux]

Clear and concise description of the problem

When running inside kubernetes/docker without externally reachable domains, the .local and .localhost domains can be used for browser based access.
These point to 127.0.0.1 which does not work for inter-container connectivity.

Suggested solution

An optional, separate env for the API of gitea server for OAuth and API requests that is separate from the URL that is accessed by the browser of the user would fix that.

Alternative

No response

Additional context

No response

Validations

• Checked that the feature isn't part of the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[qwerty287]

There's a hidden flag https://github.com/woodpecker-ci/woodpecker/blob/main/cmd%2Fserver%2Fflags.go#L486-L492 which should work for you I think

[qwerty287]

@everflux did this solve your issue?

[everflux]

I looks promising, I did not have time for testing, though. If it indeed solves the issue it might be very helpful to add it to the documentation.

[everflux]

It does not seem to work for my environment. (Context: I want to give woodpecker/gitea based trainings using a minikube cluster with no external domains)

This is my setup:
WOODPECKER_HOST http://woodpecker.localhost
WOODPECKER_GITEA_URL http://gitea-http.gitea:3000
WOODPECKER_DEV_OAUTH_HOST http://gitea.localhost

The oauth redirect is performed to http://gitea-http.gitea:3000 it seems the dev setting is overridden by the gitea url.

[qwerty287]

Maybe I was wrong and the dev env sets the URL for oauth redirection... Not sure, I can try to take a look in the next days

[anbraten]

As a side note, we have a gitpod setup which we used quite successful for workshop purposes some time ago.