Outstanding merge requests in GitLab all link to the latest Jenkins build about gitlab-plugin HOT 33 CLOSED

Jenkins 1.580 and GitLab 7.2

from gitlab-plugin.

Same for me

from gitlab-plugin.

This is most likely because of https://github.com/DABSquared/gitlab-plugin/blob/master/src/main/java/com/dabsquared/gitlabjenkins/GitLabWebHook.java#L358

Here we kind of "hack" a way to determine if the build was merge request build or a regular build. Open to any suggestions on a better way for this.

from gitlab-plugin.

@bassrock, I'd like to help out with this but I have lots of questions. Do you have an email or IRC I can reach you at?

from gitlab-plugin.

@jchristi we are using gitter.im for communicating on this project. https://gitter.im/DABSquared/gitlab-plugin

from gitlab-plugin.

@bassrock I'm not a fan of this tool. It requires signing over my private email addresses to their app. IRC seems alot more convenient since thats what all the larger OSS projects use. In any case, I figured out most of the issues I was having getting a dev environment set up. I'll work on this issue when I have the time but for the next 3 weeks, work won't allow me to commit much.

from gitlab-plugin.

One thing I have discovered is with merge request builds, the SHA hash is not enough to determine the corresponding jenkins build. For example, say I have a branch featureXYZ and then I have a branch for dev and qa. If I create a merge request to both branches, featureXYZ => dev and featureXYZ => qa, they will both have the same last commit in the MR and hence the same SHA hash. The most recent Jenkins build with that SHA hash will be referenced for both those merge requests.

from gitlab-plugin.

Yea that would make sense. Do you know of any way within jenkins to detect merge request builds like this?

from gitlab-plugin.

Since I'm not totally familiar with the GItLab API or your codebase yet, the next step for me is to run Jenkins with eclipse debugger and step through the whole process of receiving a request from GitLab and Jenkins/GitLab Plugin processing it. If the SHA hash is the only piece of information available, then that is trouble. If there is other information though then there are options.

from gitlab-plugin.

Yea thats the issue i encountered. It seemed there was really no good way to get a build other than the SHA1 and GitLab requires the CI handle storing the information regarding builds, so the GitlLab request only has the branches and the sha1

from gitlab-plugin.

bassrock, if the two branches are provided in addition to the SHA1, then that should be enough (or at least better). While its possible there might be multiple identical merge requests, that is very rare.

from gitlab-plugin.

Yea i thought that but couldn't find a way to get the branches from jenkins if I remember right. Because it technically gets merged before hand and is actually a detached build. If i remember right. It's been a bit since I wrote this and I haven't been actively maintaining it, @xaniasd has.

from gitlab-plugin.

If what you said is still true, then yeah, the current methods wouldn't be enough. I haven't written Jenkins plugins but it seems like it would be trivial to persist the necessary information for each build. There would need to be an additional step to fetch that information for each build, but it would be doable. That might not be the most efficient way, but it should work. If that is the direction you want to go, then where would that info be persisted? Inside log console output? Inside build.xml? Or a new file?

from gitlab-plugin.

Now that I think about it, that information IS persisted already via the job parameters. Those can be accessed inside build.xml.

from gitlab-plugin.

Yea they are job parameters. I think i couldn't figure out how to access them. That may have been the issue.

from gitlab-plugin.

For future reference, the Webhook API of Gitlab is defined here: https://github.com/gitlabhq/gitlabhq/blob/master/doc/web_hooks/web_hooks.md

And the GitLab CI integration code can be found here: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/models/project_services/gitlab_ci_service.rb

I'll have a look as well, see if I can help out.

from gitlab-plugin.

@bassrock, wouldn't getBuildByBranch do the trick?

The problem is that Gitlab sends no branch information. In order to determine the build result, the request is of the form "/builds/sha1/status.json", the link to the build page is accordingly "/builds/sha". So that's the only input we get and based on this information we can't tell whether it's a build for a push event we're looking for or an MR. And in the case it's an MR, we can't tell which branches are involved, if several MRs contain the same sha hash.

from gitlab-plugin.

Wouldn't that have the same problem as the the sha1? I wonder how does gitlabci sends the right one. Maybe possible using the api?

On Oct 25, 2014, at 7:19 AM, xaniasd [email protected] wrote:

@bassrock, wouldn't getBuildByBranch do the trick?

—
Reply to this email directly or view it on GitHub.

from gitlab-plugin.

when mentioning getBuildByBranch, I was just referring to "getting the branches from jenkins" part . It wouldn't solve our problem indeed. Unfortunately I don't have GitlabCi set up in order to see what it really does.

To your knowledge, is "/builds/sha1/status.json" called anywhere else other than the MR page?

from gitlab-plugin.

I don't believe so. We could add a query Parma to it that defaults to return only merge request builds and another the other value could make it operate to return only push builds?

On Oct 25, 2014, at 10:02 AM, xaniasd [email protected] wrote:

when mentioning getBuildByBranch, I was just referring to "getting the branches from jenkins" part . It wouldn't solve our problem indeed. Unfortunately I don't have GitlabCi set up in order to see what it really does.

To your knowledge, is "/builds/sha1/status.json" called anywhere else other than the MR page?

—
Reply to this email directly or view it on GitHub.

from gitlab-plugin.

how do we add a query param? I thought these calls are fixed from the gitlab side?

we could determine MR builds as the ones where target branch and source branch differ and return the latest one with the sha in it

from gitlab-plugin.

yea they are, but if we don't have it we can assume merge request from gitlabci.

from gitlab-plugin.

I believe the corresponding controller of gitlabci is here: https://github.com/gitlabhq/gitlab-ci/blob/35ab3d8bdc7c25654e0ffaabc1f3cf42bac730f4/app/controllers/builds_controller.rb

I don't see any special treatment for MRs or push builds to be honest.

However, I can confirm that this call is only sent out for MRs by looking at the Gitlab code. The sha passed to the request is that of the last commit in the request. So the only tricky part is when there are multiple MRs for the same source branch to different target branches.

from gitlab-plugin.

In that case, a "build status unknown" state would be helpful

from gitlab-plugin.

and the link to the build?

from gitlab-plugin.

No link, because it can't be accurately determined. I don't know that GitLab has a "build state unknown" status though, so that would be a prerequisite.

from gitlab-plugin.

hm, maybe we're not talking about the same thing. When you go to a Merge request page, you see a (textual) notification about the build result (passed/failed/pending) and a link to the build page. So when you follow that link, it should lead somewhere meaningful, right?

from gitlab-plugin.

That's exactly what I'm talking about. For times when no link can be determined, you want a fourth state: passed/failed/pending/unknown. As I mentioned, that probably requires a patch to GitLab. This is a small corner case though so no need to get too hung up on it.

from gitlab-plugin.

ah ok. Yes, GitLab does not support unknown status so for now this is out of scope.

from gitlab-plugin.

@xaniasd and @jchristi the unknown link is out of scope but what about the original issue of the link always linking to the latest build?

from gitlab-plugin.

Solved, to some extend: Now links to an MR build, but can't distinguish between two merge request builds from the same commit as described here. I guess that's a corner case though.

from gitlab-plugin.

I'll try to test @xaniasd 's patch when I get the chance

from gitlab-plugin.

@jchristi please wait. Found some more bugs and working on them atm.

from gitlab-plugin.