Git Plugin Triggering Build Inaccurately

[Erik Cokeley]

My git is calling Jenkins in it's post-receive hook exactly how it says to here: https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-Pushnotificationfromrepository

It is kicking off builds and doing the Poll SCM (which I checked).

My git is huge (I mean HUGE) and I need to leverage the Included Regions.

It seems like I get mixed results for pushes.  I might push to folderA/folderB/project1 and folderA/folderC/project2 will be triggered along with project1's job.  And my Included Region will look like folderA/folderB/.*

Is this a known bug or can anyone point me to why builds are being triggered wrong?

I'm also making my branch */master is the * in that effecting anything (I only have 1 git setup for anything as of now)

[Mark Waite]

You may be suffering from:

https://issues.jenkins-ci.org/browse/JENKINS-20569 - excluded regions not honored by Git plugin 2.0

I believe there is also a bug report that include regions do not behave as expected.  It is probably worth a search through Jira to see what it will tell you about include and exclude regions.

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Erik Cokeley]

Thanks I'm going to downgrade my git plugin.  I think that is what I'm running into.

[Mark Waite]

Nicolas DeLoof just posted a hint that the issue may be related to the change in the default state of "fast remote polling".  Fast remote polling allows the master Jenkins instance to check for changes on a git repository, without cloning that git repository.  That technique makes commit detection much lighter and faster.  However, that technique cannot process inclusion and exclusion conditions.

If you have not already downgraded your Git plugin, you might try adding the Advanced Behavior, "Force polling using workspace".

Mark Waite

[nicolas de loof]

yes, I'm looking into possible changes in jenkins-core that would allow such a remote-polling to be used to detect potential changes, then use workspace to "confirm" changes actually have to get handled by a build.

2013/11/22 Mark Waite <mark.ea...@gmail.com>

[Erik Cokeley]

Thanks I'm going to try the Force polling using workspace option.

[Erik Cokeley]

I downgraded my git plugin to 1.5xx and Included Regions work.... Now I'm getting hanging SCM Polling threads though.  Found this jira ticket (which is kinda old but still has chatter): https://issues.jenkins-ci.org/browse/JENKINS-5413

I'm trying to clean up the threads with the script in the discussion but I'd rather have a cleaner solution.  Any help?

Thanks!

[Mark Waite]

You mentioned that you would try enabling "Force polling using workspace" with git plugin 2.0, but then said that you had downgraded to 1.5.  Did the "Force polling using workspace" option not work?

[Kalyan K]

Hello All,

This one is a follow-up for builds getting triggered for the changes not specified in "Include regions". We also added "force polling using workspace" option, but no luck.

We ran into Jenkins Git plugin merge issue, and wanted to know if this can be addressed, and here is our scenario:

1. Branches A and B are created from master.

2. Jenkins Job_A is created with included regions to look for sub-directories pertaining to changes committed through Branch A.

3.  Jenkins Job_B is created with included regions to look for sub-directories pertaining to changes committed through Branch B.

4. Jenkins Job_A, and Job_B are mutually exclusive, as the included regions for triggering builds are only pertaining to their respective sub-directories.

5. Branch A is merged with the master triggering a Jenkins build defined in "Job_A".

6. Branch B is merged with the master triggering a Jenkins build defined in "Job_B". 

7. However, when the Branch B code is merged, Jenkins build for "Job_A" is also triggered which is not a part of included region. 

8. Seems that this issue can be mitigated if we add "first-parent" option in method showRevision() in "CliGitAPIImpl.java". "first-parent" logic was implemented subsequently with commit#: 777c306e433e7de58702a3fd1e45512a47c0d33a

Please find below the comment referred to extra builds getting triggered.

https://github.com/jenkinsci/git-client-plugin/commit/340da905666600a18866ebba27376c7f1874d673

"The output of "git show" included commits that were not introduced since

the last build, so could falsely trigger build in the presence of
"includedRegions".

A benefit of not including extraneous commits is the size of the output
is reduced, and therefore less heap required.

This can still trigger extra builds as "-m" means the changes between all
legs of a merge commit are displayed.  However, without this, conflict 

resolution changed as part of the merge commit would be skipped."

Please let us know your thoughts/suggestions.

Thanks,

Kalyan