-
Notifications
You must be signed in to change notification settings - Fork 619
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
Error while testing GitLab's Jenkins CI Integration with Jenkins' GitLab Plugin #272
Comments
I am seeing the same behavior with a local jenkins 2.0 install and Gitlab 8.5.5-ee. Same stacktrace. Plugin version 1.2.0 |
Downgraded the plugin to 1.1.32 in jenkins. Successfully works around this issue. |
Have same the problem. Downgraded to |
I tested the plugin in Jenkins 2 running in the bundled Jetty and a Tomcat 8 and for both I hadn't trouble that the |
I'm running Gitlab 8.6.4 and I'm not seeing any X-GitLab headers in the request sent from Gitlab -> Jenkins. On my gitlab server 127.0.0.1:8090 maps -> jenkin2.example.com:8080 which is the raw Jetty server that is bundled with Jenkins. Request
Response
|
I am actually using apache mod_proxy to deliver over port 80. If the root cause is indeed a missing header, maybe it is being stripped by apache. I won't be able to examine it until Monday. |
I just tested this at work with GitLab EE and the Jenkins CI service. In this case the |
Also experiencing this issue, had to downgrade to |
As stated earlier, I am using apache as a reverse proxy to allow access to jenkins on port 80 (for user convenience). To eliminate this as a variable, I modified my configuration in GitLab to point directly to the jenkins port. This bypasses apache entirely, but did not correct the issue. Latest test with plugin: v1.2.1 |
Recreated once again, this time with: Jenkins 2.1 I also updated my gitlab configuration to access Jenkins by IP (internal network) to take the internal DNS out of the equation. Like my earlier test, I used my Jenkins port instead of port I got the same results. So I ran tcpdump on my gitlab server as suggested by @coder-hugo.
The relevant portion of the output from the GitLab service's "Test Settings" button: (The IP has been changed to protect the innocent.)
This does seem to confirm the absence of a |
@crussell52 as mentioned here #272 (comment) this seems to be a bug in the GitLab EE Jenkins CI Service. If you add a webhook instead of the Jenkins CI Service the request should contain the |
Add link to GitLab EE issue |
@coder-hugo Thank you for the followup and for raising the issue with GitLab. :) |
Hi. Same issue on:
I have been using webhooks all along (have not used GitLab CI feature once), everything was fine until somewhere after 28 April 2016 (date of the last successful build on our Jenkins instance) I have builds triggered through a reverse proxy, and build triggers by-passing same said proxy (legacy...). |
@demaniak the oldest tested version of GitLab for this plugin is 7.14 and this definitely sends the |
@demaniak @coder-hugo I confirm the issue too using Gitlab CE 8.7.0. Also tried updating later the plugin and had to roll back due to all builds in Gitlab were in Skipped state. Edit: they answered in your request @coder-hugo ;) |
@apazga I openen an issue for the GitLab EE Jenkins CI service which doesn't send this header the normal webhook should send this header. I tested this with GitLab CE 8.7.0 and GitLab EE 8.7.0. If the header is missing for any GitLab CE installation this has to be related to your setup. |
@coder-hugo @apazga personally I am completely willing to explore and assist with any explanation/resolution for this issue.
As far as I can tell things broke while standing still - so it feels like there is a piece missing in this puzzle somewhere. I would believe the problem is completely on our internal setup...except that this issue exists (so other persons are also experiencing the problem). We are currently in the process of updating our Gitlab CE instance to see if that maybe solves anything. Will report on results. |
tldr; It looks like GitLab has put up a MR which will make sure the missing header is delivered (https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/374). Compatibility with GitLab versions before the patch is a question. The current version of this plugin (1.2.x) has a clear expectation of the In order to work around this, @coder-hugo would need to (at best) parse the message body, extract one element, then hand it off to be parsed again. It seems possible, but ugly and contrary to the clean architecture he has applied to it. Instead (respectably), he has engaged the GitLab devs and they appear to be patching it. The downside is that the new 1.2.x version of this plugin does not appear as though it will be compatible with builds of the @coder-hugo, I hope I'm interpreting this correctly... if not please correct me. :) Will you just be raising the minimum required version of GitLab for v1.2+ of this plugin? |
Looks like there is a lot of confusion about this issue so here are some insights: |
@coder-hugo Thank you for working on this and thank you for taking the time to clarify. :) It doesn't look like the GitLab
Is that accurate? |
@crussell52 yes this is correct |
Thanks @coder-hugo for the detailed explanation. I'm using now Gitlab CE 8.7.2 (just updated it) and captured the header from a Webhook, and it's ok like you said. So I'll re-try updating Gitlab Plugin to test it again, because using 1.1.32 worked and using 1.2.0 didn't (I also had to re-enable Gitlab Plugin in all jobs that use the plugin after updating from 1.1.32 to 1.2.0 due to the warning Jenkins shows like the screenshot I posted before).
|
Just some feedback here:
So the only logical conclusion I have for our particular case is that I must have been mistaken about gitlab plugin version up to 28 April 2016, and that somewhere after that, I must have allowed the plugin to upgrade. |
More feedback: After updating to plugin 1.2.1, Gitlab 8.7.2, it's working now. |
@coder-hugo should we update the documentation to explain this issue? It sounds like it will be a permanent problem for people using GitLab EE versions before the bug was fixed there. |
@omehegan yes, we should update the README. |
Still doesn't work for me. Jenkins 2.5 Even if I re-enable and reconfigure like @apazga noted. Also since there have been GUI updates in both Gitlab and Jenkins, the README documentation is out of date, so it's tough to follow the instructions. |
@timmolter this will be broken in GitLab EE until https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/374 is merged on their side. Can you specify which parts of the README need updating? Especially for things that have changed on the plugin configuration side. I'm trying to keep on top of that. |
I have referenced this issue in the README so that users will be aware of it. I don't see much benefit in keeping it open, given that the issue is on GitLab's side and we don't know when they will fix it. |
This seems to be merged on our side @omehegan, should it be removed from the README? |
I think the note is still relevant in case someone using an older GitLab EE runs into the problem, but I clarified in the README that the bug has been fixed. |
@coder-hugo where i can get old version of Gitlab Plugin? |
@omehegan what is best solution now? |
@mahdit83 old plugin versions are available here: https://updates.jenkins.io/download/plugins/gitlab-plugin/ But GitLab fixed this problem. You should probably upgrade if you are still on a version of GitLab that is almost two years old. |
@omehegan I using online gitlab that Enterprise Edition 10.4.0-ee. and Jnkeins 2.103 |
Merge jenkinsci into janinko
When the build is scheduled, add an extension that will go back and cancel queued builds, and abort running builds. Fixes jenkinsci#272 and fixes jenkinsci#241
Hello,
I'm trying to make GitLab 8.7 (using directly https://gitlab.com) and Jenkins 2.0 work together, but I got this error from Jenkins when I test (using the Test button of GitLab's Jenkins CI Service interface):
I looked at the source code and it seems that the
X-GitLab-Event
is missing from the HTTP request.Do you guys have an idea what going on?
The text was updated successfully, but these errors were encountered: