New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Webhooks not arriving to webservice #9407

Closed
smetj opened this Issue Mar 29, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@smetj

smetj commented Mar 29, 2018

Hi,

It seems that (at least in my case) web hooks are not arriving in the defined web service.

I can't see a failing incoming request on the web service on my side.
I believe the SSL cipher in use on https://events.smetj.net/travis are supported by the travis "client" but I can't confirm that entirely.

Since there is no customer insight into failing web hook requests I was wondering if there's a list available of library versions used by the code doing the web hook service request so I could try to replicate the problem locally?

@BanzaiMan

This comment has been minimized.

Member

BanzaiMan commented Mar 29, 2018

This is a common mistake with notification configuration. Notifications are configured before any job is executed, so they do not have access to any of the environment variables that your jobs may define. (Consider a case with many jobs, some of which may not define the environment variables necessary for the notifications, or they may not all agree on the same values.)

We have this bit in the documentation, but perhaps we can improve it still:

Note: These webhooks are executed at the end of a build, and not by individual jobs (see builds vs jobs). This means that environment variables from the build are not available in this section.

@BanzaiMan BanzaiMan added the docs label Mar 29, 2018

@smetj

This comment has been minimized.

smetj commented Mar 29, 2018

ok got it. Long story short no custom variables available in the notifications section.

So I figured to use encrypted values instead which works.

However, ... it seems that an URI including basic authentication information isn't supported ??

https://username:password@events.smetj.net/travis

If I omit the username:password@ part I can see the request coming in on my end. When I leave the username and password the request never reaches the api on my end.

So it seems to me that there's a bug on the Travis side related to URI's including basic authentication not being processed.

@BanzaiMan

This comment has been minimized.

Member

BanzaiMan commented Mar 29, 2018

@smetj That is a separate issue. Please open a new ticket.

@smetj

This comment has been minimized.

smetj commented Mar 30, 2018

@BanzaiMan You're right, ... I will do that.
#9415

@smetj smetj closed this Mar 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment