After debugging I think the problem here is that it also checks for BranchEventCause which drops all post-commit hooks. Would it be an issue to remove this? As the primary reason is to suppress indexing triggered builds...

Functioning as designed.

Suppress SCM Triggers is intended to prevent any builds being triggered if there is a change detected in SCM. It does not matter whether the change is detected by indexing or by an event.

Looks like this bug was introduced with JENKINS-41980

The reason the original code only suppressed indexing was because at the time event support could only trigger indexing. When we added event support, that exposed the bug in the original code which was then fixed by suppressing event triggered builds too

What about separating those into two different settings? Like suppress only indexing triggers or all scm triggers? 

Maybe as a background: we run stateless jenkins instances that are fully configured by code. On starting it detects all branches and would start building them all, which does not make sense. But if somebody pushes a new branch or a change to an existing branch he would expect it to build.

Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/jenkins/branch/NoTriggerBranchProperty.java
http://jenkins-ci.org/commit/branch-api-plugin/22c8d12a5ad3b523042343bb769b15affb11d1a6
Log:
JENKINS-45814 Fix javadoc to reflect intended purpose of class

What about separating those into two different settings?

Some SCMSource implementations may not be able to provide sufficient event details to inform an event based trigger and consequently have to fall back to triggering a reindex. (see MultiBranchProject.onSourceUpdated(SCMSource) )

Maybe as a background: we run stateless jenkins instances that are fully configured by code. On starting it detects all branches and would start building them all, which does not make sense. But if somebody pushes a new branch or a change to an existing branch he would expect it to build.

Sounds like the best option for you is to write an extension plugin and implement the property you want in that extension plugin.

I am going to give you the freedom you need by stating:

We will not be adding infinite customizability to the core logic.

In other words, while I recognise your need, I am stating for the record, that the core logic will never meet your need... but I encourage you to write an extension plugin that does meet your need.

I will consider pull requests that enable third parties to write extension plugins and deliver functionality that they need, but the core logic is exposed to everyone and infinite options does not make life easy for the majority of users

The extension plugin that you would need would seem fairly easy to write (just a copy and paste of the NoTrigger property with some renaming and removal of the BranchEventCause check)

Fair enough. I wasn't aware of that fallback thing, since from git point of view it kinda does not make much sense and I saw the patch was done for github hooks. 

Anyway, I got your point and for our products I tend to share to same opinion to keep core things simple. For now I just patched the plugin on our jenkins, since it is same (or even less) effort as doing our own plugin.

Once I find the time and urge, I'll create one. 

Thanks for your support.

since it is same (or even less) effort as doing our own plugin

I think you'll quickly find that updating your patched version is more work than just creating a simple plugin that has your impl...

I experience this with the GitHub branch source plugin within multibranch pipelines. I nearly created a new issue but then found this.

So, what's the best course of action here? "Suppress automatic scm triggering" blocks GitHub push triggers. Should I create a new plugin, add to an existing plugin (like the scm-filter-branch-pr plugin), or file a new bug report for this plugin?

sag47 Good question.  I am in the same boat here.  If we restart our stateless jenkins server - I dont like the idea of scanning for all branches, and everything being rebuilt.

We have the exact same issue. (Stateless jenkins server)

Did anyone find a solution for this? We try to avoid writing and maintaining our own plugins.

Hi,

it's not entirely w/o maintenance but we kinda hotfixed the plugin by adding this class (which basically globally suppresses the build on BranchIndexingCause):

/*
 * The MIT License
 *
 * Copyright 2016 CloudBees, Inc.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to deal
 * in the Software without restriction, including without limitation the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 * copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
 * THE SOFTWARE.
 */

package jenkins.branch;

import hudson.Extension;
import hudson.model.*;
import org.kohsuke.accmod.Restricted;
import org.kohsuke.accmod.restrictions.NoExternalUse;
import org.kohsuke.stapler.DataBoundConstructor;

import java.util.List;

/**
 * Suppresses builds due to {@link BranchIndexingCause}
 */
@Restricted(NoExternalUse.class)
public class SuppressIndexingBuildsBranchProperty extends BranchProperty {

    @DataBoundConstructor
    public SuppressIndexingBuildsBranchProperty() {}

    @Override
    public <P extends Job<P, B>, B extends Run<P, B>> JobDecorator<P, B> jobDecorator(Class<P> clazz) {
        return null;
    }

    @Extension
    public static class DescriptorImpl extends BranchPropertyDescriptor {

        @Override
        public String getDisplayName() {
            return Messages.NoTriggerBranchProperty_suppress_automatic_scm_triggering();
        }

    }

    @Extension
    public static class Dispatcher extends Queue.QueueDecisionHandler {

        @SuppressWarnings({"unchecked", "rawtypes"}) // untypable
        @Override
        public boolean shouldSchedule(Queue.Task p, List<Action> actions) {
            for (Action action :  actions) {
                if (action instanceof CauseAction) {
                    for (Cause c : ((CauseAction) action).getCauses()) {
                        if (c instanceof BranchIndexingCause) {
                            return false;
                        }
                    }
                }
            }
            return true;
        }

    }

}

We added these steps in our jenkins master rollout process:

curl -sfL https://github.com/jenkinsci/branch-api-plugin/archive/branch-api-${branchApiVersion}.tar.gz | tar xvz
cd branch-api-plugin-branch-api-${branchApiVersion}
cp ../SuppressIndexingBuildsBranchProperty.java src/main/java/jenkins/branch/SuppressIndexingBuildsBranchProperty.java
mvn -V -B compile hpi:hpi
cp -v target/branch-api.hpi ${jenkinsPluginDirectory}

Hope this helps,

Thomas