Build links ignore DRONE_HOST server setting

Development
1

We have a Drone instance set up with DRONE_HOST=http://ci.foo.bar. Everything works - triggers come from GitHub, builds happen, and everyone can log in.

We recently added a reverse proxy in front of drone, to ensure that it’s only accessible by employees of the company.

On the same machine where we run the Drone server and agents, we have a cron job that kicks off some deployments regularly. It used DRONE_SERVER=http://ci.foo.bar, which worked fine. Now that we have the extra security layer, I’ve switched it to use DRONE_SERVER=http://127.0.0.1:8000, to bypass this layer of security from the internet.

Now the regular deployments work again, I’ve discovered a little bug. We have notifications set up, and they use {{build.link}} as part of the message. The links are now like http://127.0.0.1:8000/$user/$repo/$id, which isn’t useful. It seems to me like those links should always use DRONE_HOST as configured in the server.

Otherwise, is there a better way to kick off builds locally without messing with the links?

2

In Drone 0.8 the hostname is ascertained from the incoming HTTP request. It does not use the DRONE_HOST environment variable for this purpose. The plan was to eventually use DRONE_HOST throughout Drone, which is what we are now doing in 1.0.0.

In this case, I think the best workaround for 0.8.0 is something like this:

curl -X POST \
  -H "X-Forwarded-For: ci.foo.bar" \
  -H "X-Forwarded-Proto: https" \
  http://127.0.0.1:8000?access_token=xxxxxx
3

Thanks for the quick reply! Sounds good if this will be fixed as part of the 1.0 refactor.