2.5 Triggers every build on commit

[jravetch]

When we upgraded the plugin to 2.5, every commit on Stash causes Jenkins all builds to start. We did not see this happen with version 2.4, only on the upgrade. This is a big problem as it was causing even builds that should not be triggered by a commit to start.

Any idea what could be causing this?

[mikesir87]

Hmm... a little more info is needed. Is this triggering builds on Jenkins builds that reference still the same repo? What version of the Git Plugin (in Jenkins) do you have installed?

The only difference in the webhook notification is that we no longer supply ONLY the repo URL, but also the branch and sha1 hash now. When the sha1 is provided, the Git Plugin in Jenkins triggers the build immediately, skipping the poll that it normally does. Beyond that, there shouldn't be a huge change (but I could be mistaken).

[jravetch]

@mikesir87 Lightening speed! Yes this is triggering builds on the same repo. We use Git plugin 2.2.2. We are ignoring certain branches in the plugin, wondering if that logic changed. We use a very infrequent poll 0 0 1 1 0.

[mikesir87]

Haha... I try to be quick and responsive. Not bad for an open source plugin, eh? Haha...

Mk. To help me setup a similar environment to try and test it out, I think you're saying that you have a few Jenkins builds. Is each configured to watch a different branch? And in the Stash plugin, you're configuring the plugin to ignore certain branches. But, the webhook seems to be triggering builds that shouldn't be triggered, unless the plugin isn't actually ignoring?

[jravetch]

Yes our builds have a workflow, i.e. postcommit builds directly from each commit, then after they pass they go on to QA deployment build, then staging, then production. We saw the production builds get triggered from a commit, which obviously should not happen.

Also, the change in the new version is that builds were being triggered that don't have polling on.

[jravetch]

@mikesir87 So from your release notes, you state:

"No longer requires polling to be enabled for the git repository in Jenkins setup"

So you changed the logic and it means we can no longer use turning on polling as a flag to indicate that the webhook should fire.

How can I install the the previous release to confirm?

[mikesir87]

That's true because in the Jenkins Git Plugin, for the release notes for version 2.0.2, there's this statement:

"notifyCommit now accept a sha1 - make commit hook design simpler and more efficient (no poll required)"

We're now providing the sha1 in the webhook. That's the only thing that really changed with this new version. So, the not requiring the poll is only because the Git Plugin doesn't poll if the sha1 is provided. Maybe there's a bug there in their code?

I also see that there's an "Ignore post-commit hooks" checkbox under the poll setup. Does that affect anything? (Weird that the poll has to be enabled to see that checkbox)

[mikesir87]

And forgot to post a link to download previous versions...

https://marketplace.atlassian.com/plugins/com.nerdwin15.stash-stash-webhook-jenkins/versions

[jravetch]

@mikesir87 Thanks for the link. I successfully downgraded to 2.4.2 and my issues went away. So sending the hash by default is not really workable for us, since we have several things that point to the same branch and repo that we don't want to trigger.

Would it be possible to make this optional with a flag?

[mikesir87]

It'd be possible to make it optional with a flag. However, there is no global setting page (yet) and having a flag per repository might be overkill or require a lot of work to deselect all of the flags.

Did the "Ignore post-commit hooks" option on the Jenkins build not do anything?

[larrys]

My problem is I have some jobs that are manual, or are triggered by another job, so I do not want at all to poll SCM.

[vankap]

I'm having the exact same problem. The builds where I did not check the Poll SCM box also got triggered. plugin version: 2.5.0 Stash version: 3.2.0 Jenkins version: 1.574 Jenkins Git Plugin version: 2.2.4

Edit: I downgraded to version 2.4.2 and the problem went away.

[aspic]

We are experiencing this problem as well. We have only enabled 'poll scm' box for projects which should be triggered by push to branch (as suggested as a workaround earlier), and this build job further triggers deploy and test.

Our test framework is checked into the same code tree, so we also need the test-job in jenkins to be aware of git. This causes the test-job to be triggered once we push to git.

[ws-kimmo-helsing]

We have same problem. Too many builds triggered now after upgrade to 2.5.0. Stash doesn't allow downgrading the plugin but if we uninstall the 2.5.0 and then install 2.4.2 does it lose all the existing settings for the repositories?

[ws-kimmo-helsing]

We just decided that we will not take the 2.5.0 in use at all. Not only does it cause builds to be started on jobs that are only meant to be run manually, it also schedules a new build even if there was already one build waiting in a queue. Normally, if a build is running and another one is in a queue, the waiting job will eventually cover all code changes done while the first build was running.

[qianalan]

I have a question. It is common to have a repo with many jobs configured to run various tests as well as builds against it. Let's say some jobs should run on a fixed schedule, some poll on a fixed schedule, some get triggered by code push, and some triggered by updates to pull requests. I am not sure how to configure things to make them all work. So we have to specify something in Branch Options that is not "build all", since "build all" would cause every polling job to poll right away. But then how would we trigger a job that is supposed to run when new commits are pushed to master, for example, without making it poll every minute? If we specify "master' in "Build from", then all polling jobs against master would start to poll, including the ones we only want periodically. It seems as though we cannot get away from bad practices like polling every minutes.

[bigethan]

This issue is still an issue after upgrading to 2.6 - will this ever be fixed? To be clear:

• jobs that are not Poll SCM are triggered on every merge
• jobs with a quiet period stack up instead of merging

It'd be nice to know whether we should move on or wait for something. I realize this is free software, just trying to figure out my course of action.

[rhajek]

I think this issue is serious blocker and it caused big troubles to us. We are using jenkins also for deployment to production systems and after i updated jenkins hook plugin in Stash, jenkins automatically deploys untested code to our customer, performs mvn release to nexus...

[mrudel]

Has anyone figured our a solution from this? This has kept us from upgrading for a while and it's becoming a thing.