Verigreen / verigreen

Verigreen is a lightweight, server side solution for verification of git commits. It is a gated check-in process which will not allow any failed CI commit to go into an integration/release/any protected branch. We keep it green (hence the name).

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Issue with commits verification

litalk opened this issue · comments

Hey Guys,
We have an issue which is on the battle line between verigreen and Jenkins, not sure where it should be handled but currently I think it can only be on verigreen so hear me out :)

Lets say I have 3 commits in my push:
a - belongs to common module
b - belongs to server module
c - belongs to some-service module

Verigreen sends to Jenkins only commit c, and Jenkins in its routing job only triggers some-service verification job, and the previous 2 commits remains unverified :(
The routing job cannot know that, it is not reasonable for it to try and find out on its own.
I think verigreen should send Jenkins a list of commits, not just the last one but all commits that are not on master, including the ones it merges.

WDUT?

Hey Lital, thank you for your feedback.
From my point of view, the job is running base on the code and not base on the commit - I already witness some groups that trigger a job base on the changes in the repo.
In that case, one push with 3 commits should shown a difference that include all 3 changes - therefore a "larger" commit should be run.

WDYT?

I agree, an I also remember it use to work. Not sure what went wrong but from what I see in the router job logs, it only looks on the commit ID it gets from verigreen to understand what jobs it needs to trigger.

see here for example:
https://mydtbld0048.isr.hp.com:8888/jenkins/job/PreFlight-ALM-Master-Router/2054/console

I had about 6 commits on that push, the job only took the changes from the last commit, therefore some changes were not covered.
This is the commit id:
35a0f235eac82b70160a7131a406968207f21198

@litalk - this is the sub job and not the job that VG is triggering - as you recall, VG is sending temp branch that include all of the changes in your push (merge between all 3 commits).
If your job wants to determine which sub job it want to execute then it should look at the differences between old rev(of the protected branch) and current rev (of the temp branch).
Your master job is doing something like that:
15:54:43 *********************** GIT INFORMATION ***********************
15:54:43 - GIT_PREVIOUS_COMMIT=
15:54:43 - GIT_COMMIT=68e5c4ea7351225ce74458f7f0b1efdd1f79f8d7
15:54:43 - ParentBuildNumber=2158
15:54:43 - ParentJobName=PreFlight-ALM-Master
15:54:43 ***************************************************************

If the router job is responsible on the decision which test to run then it should be informed not just in the commit id but also in the differences, or the router job can check it by itself.
FMHO, it is related to the job configuration unless you can tell me that the tmp branch that was sent is not including all of the commits - if that is the case let us know and we will fix it accordingly.

@litalk, I close this issue with Ronen. he will do the adjustments in the Jenkins job.
Closing this issue.