Closed ky4n closed 1 year ago
Can you check that the woodpecker container canconnect to https://gitea.my.fancy.domain/?
The log indicates that this is not the case and woodpecker cannot verify the token provided in the URL. May be related to your VPN setup and you will have to provide a DNS entry to the woodpecker container for gitea.
Here's the hacky way I just managed to solve this issue:
woodpecker-server:
environment:
WOODPECKER_HOST: https://ci.example.com
WOODPECKER_GITEA_URL: https://git.example.com
Make sure to use the correct network name. Mine is web
caddy:
networks:
web:
aliases:
- ci.example.com
- git.example.com
OK, after taking a break and coming back to it with a fresh mind, I've solved it on my own. TL;DR: firewall
I will add some more information in case someone finds it useful in the future.
First, clarification: MY_IP_ADDRESS
was the IP address of the host running Docker containers, not the client (my browser).
Second, I did not assume it was a firewall because the error was happening during Oauth authorization phase and I assumed the only communication then is browser <-> Gitea and browser <-> Woodpecker. That part worked fine all the way.
Small note, Woodpecker server Docker image builds FROM scratch
so @smainz comment won't actually work directly. I did use a different container connected the same way as Woodpecker server to test the connectivity (and spot the root cause).
Regarding @Admicos comment](https://github.com/woodpecker-ci/woodpecker/issues/1560#issuecomment-1399327364) and general Woodpecker - Gitea connectivity it took me a while to build a valid mental model of the communication. There was another issue I stumbled upon earlier which basically said Woodpecker uses only 1 URL for Gitea, so no way to have two: one for feeding to the users (browser) directly and another for communication between Woodpecker and Gitea. Side note: this might be a good idea, if Docker is one of the "blessed" ways of setting up Woodpecker.
I've actually addressed the potential DNS issue by having domains for both Woodpecker & Gitea resolve to the same IP address for containers and users (browsers). This allowed me to use the same HTTPS URL in Woodpecker configuration and in the browser. Basically, both gitea.my.fancy.domain
& woodpecker.my.fancy.domain
pointing to MY_IP_ADDRESS
(port 443 covered by Nginx with a publicly valid TLS certificate).
At the time I was troubleshooting this, the firewall however was only allowing connections to `MY_IP_ADDRESS
on the VPN network interface, not on the (bridge) network interface to which both containers were plugged.
To sum up:
Running Gitea & Woodpecker on the same host in Docker containers can be problematic. Official docs don't cover all possible setups (K8s, Docker compose, other orchestrators), but I don't good improvement suggestions here, sorry. I needed to make sure I use the same domain & port for internal (Gitea-Woodpecker) and external (browser to both) communication, as well as making sure the containers can talk with each other directly (firewall in my case) and do it over the same URL as the browser does.
I 'll close this issue, thanks for your time spent on this.
Component
server
Describe the bug
Short version: Issues with oauth setup between Gitea and Woodpecker -
/authorize?code
endpoint times out on response from Gitea.Long version: I've set up Gitea and Woodpecker in Docker containers and I cannot get the authorization to work. Both services run in Docker on the same instance (VM). Both services are accessible via HTTPS through Nginx proxy, with valid TLS certificates. The domain is "internal", resolving to VPN interface of the instance.
Gitea:
ALLOWED_HOST_LIST
added during troubleshooting, but probably unnecessaryRelevant (?) configuration part:
Woodpecker:
I'm logged into Gitea in the same browser window.
When I open Woodpecker main page and click on the log in button, the following happens:
/authorize?code...
request which times out after 60 secondsWeb server (Nginx) logs show properly passing the request to Woodpecker and (with
trace
logging) there's a log line acknowledging it reached the Woodpecker service itself, but the service is not giving any reply. After ~ 60 seconds the the request times out giving HTTP/504.I've attached some parsed logs too.
System Info
Additional context
Browser networking logs:
Parsed web server logs, mainly for timestamp correlation (they match browser times):
Gitea log:
Woodpecker trace log:
While there are no seconds in Woodpecker timestamp this line is logged shortly after all the other requests:
TRC ...:38 > [GET] /authorize?code=gta_SOME_RANDOM_CHARACTERS&state=woodpecker
Afterwards the request hangs for about a minute in the browser and times out.
Validations