Do not run Jenkins KG build when commit is made to main

[caufieldjh]

See Knowledge-Graph-Hub/kg-alzheimers#19

Currently, most KG-Hub KGs run their Jenkins build pipeline upon any commit to main.
This isn't entirely necessary.

[justaddcoffee]

+1 for disabling the triggering of builds on commit to main

[kltm]

I believe I have made the change to make this happen for all projects in "Knowledge Graph Hub". Testing would be appreciated.
If this works, Knowledge-Graph-Hub/kg-alzheimers#19 would be fixed as well.

[justaddcoffee]

@kltm confirming that merging a trivial PR on kg-alzheimers does not trigger a build, as expected.

Probably we should confirm that automated monthly builds are still working

[caufieldjh]

I am a bit worried about the monthly builds since Jenkins now marks main branches as Disabled (first column):

[justaddcoffee]

@caufieldjh yeah I noticed that too, the main with a strikethrough looks a little worrisome

[kltm]

Noting Knowledge-Graph-Hub/kg-alzheimers#19 (comment)

Okay, I think we need to clarify the desired behavior here. Currently, the settings are such the Jenkins will:

1. within Knowledge-Graph-Hub
2. look at all branches
3. ignore anything that doesn't match .*_run_jenkins

With this ruleset, what you see above would be the expected behavior.

Within the current plugin set, the options for "2" are:

Exclude branches that are also filed as PRs
    If you are discovering origin pull requests, you may not want to also build the source branches for those pull requests. 
Only branches that are also filed as PRs
    Similar to discovering origin pull requests, but discovers the branch rather than the pull request. This means env.GIT_BRANCH will be set to the branch name rather than PR-#. Also, status notifications for these builds will only be applied to the commit and not to the pull request. 
All branches
    Ignores whether the branch is also filed as a pull request and instead discovers all branches on the origin repository. 

For "3" we have a lot more options, such as looking at tags, PRs, etc.

It may be that the exact effect you want is not going to be easily had without changing plugins with our current setup. Another option would be to code some of what you want into the Jenkinsfile itself (e.g. skipping under certain circumstances).

[caufieldjh]

Another option would be to code some of what you want into the Jenkinsfile itself (e.g. skipping under certain circumstances).

I like this option best because it makes for clearer documentation vs. having the setting hidden in the Jenkins configs.
It would be more convenient to have a global setting in Jenkins but I'm not seeing a clear way to set is as "only do scheduled builds on main but only build on push with specifically-named branches"

[kltm]

I agree with you there @caufieldjh . I would point out another "workaround" solution would be to change your workflow and SOP, such that when you apply PRs and commits to different branches is more in line with the effect that you want. That may not be possible if you would have to "retrain" people, but if it's just a couple of people, it's a possibility. (From experience, this kind of strategy can only be stretched so far.)