you are my only hope. I'm pulling my hair out. I try to do an incredibly simple thing, pair Woodpecker CI
instance with Gitea
instance.
- I have a running Gitea on a separate host.
- I have an oauth2 application for Woodpecker created in my user's configuration in Gitea.
- I have an
Woodpecker CI
instance configured for Gitea, actually accessible through the https. It works, there is a "Login" button. - I click it. It redirects me to Gitea. I log in into Gitea and authorize Woodpecker in the Gitea.
- Then I get redirected back to the Woodpecker through the Redirect URI in Gitea's application configuration, and suddenly, I get
HTTP ERROR 502
from Woodpecker instance and cannot proceed from there.
Some information about the setup. I run a binary of Woodpecker server
in an LXD/LXC container. It is behind the reverse proxy: Caddy
. This 503
error leaves trace in Caddy's logs:
Jun 19 23:01:37 woodpecker-server caddy[158]: {"level":"error","ts":1687208497.326067,"logger":"http.handlers.reverse_proxy","msg":"reading from backend","error":"unexpected EOF"}
Jun 19 23:01:37 woodpecker-server caddy[158]: {"level":"error","ts":1687208497.326134,"logger":"http.handlers.reverse_proxy","msg":"aborting with incomplete response","error":"unexpected EOF"}
There is nothing in the Woodpecker's logs.
This is my Woodpecker's configuration:
WOODPECKER_HOST=[REDACTED]
WOODPECKER_ADMIN=[REDACTED]
WOODPECKER_LOG_LEVEL=warn
WOODPECKER_LETS_ENCRYPT=false
WOODPECKER_GITEA=true
WOODPECKER_GITEA_URL=[REDACTED]
WOODPECKER_GITEA_CLIENT=[REDACTED]
WOODPECKER_GITEA_SECRET=[REDACTED]
WOODPECKER_GITEA_SKIP_VERIFY=false
Caddyfile
[REDACTED] {
reverse_proxy localhost:8000
}
# caddy version
v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=
# woodpecker-server --version
woodpecker-server version 0.15.9
What boggles my mind is that Woodpecker server login page seems to work. It redirects me to my Gitea which allows me to authorize the Woodpecker and redirects me back to the Woodpecker's https://[HOST]/authorize
page. So, it looks like all the data is correct. But for some reason, after this step it fails to provide the correct response.
I'm certain that Gitea+Woodpecker setup is very common. Does anyone have any idea what could possibly be the cause of this? What to look at?
More info: Gitea is behind the nginx, its configuration is:
server {
listen 80;
listen 443 ssl;
server_name [REDACTED];
ssl_certificate /etc/letsencrypt/live/[REDACTED]/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/[REDACTED]/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
location / {
client_max_body_size 512M;
proxy_pass http://unix:/run/gitea/gitea.sock;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# Redirect non-https traffic to https
if ($scheme != "https") {
return 301 https://$host$request_uri;
}
}
I guess the issue is that WP can not talk to Gitea and therefore can not exchange the code for an access-token. I am not quite sure why though. Maybe you can give the next version a try which will be released soon anyways.
It appears that it's the bug in the Woodpecker that is related to https://github.com/woodpecker-ci/woodpecker/issues/1576 . Like in this reported issue, changing Gitea's URL from domain into IP seems to avoid any problems. One need also to set
WOODPECKER_GITEA_SKIP_VERIFY
environment variable value totrue
. It's a workaround but seems to work.