Disable SCMTrigger(s) in a pipeline job with a system property

Using Jenkins
,
1

Hi,

I am using jenkins-test-harness and to omit the scm scanning / triggering in the test case I can set:

jenkins.branch.MultiBranchProject.fireSCMSourceBuildsAfterSave to false, see [0].

I would like to do the same for standard pipeline job definitions, to omit the SCMTrigger in the test case (I don’t want to modify the pipeline DSL definition itself - just to disable the trigger like for the multibranch pipeline).

I had a look in [0] but did not find a property - did I miss it - is it maybe undocumented, anyone an idea?

Thanks.

[0] Jenkins Features Controlled with System Properties

2

Maybe calling yourjob.setTriggers([]) (API reference) immediately once the job gets created might help?
I don’t think regular pipelines have the same “scan SCM changes immediately upon XML reload/save” behavior as multibranch ones do, so just nuking the triggers after a successful deployment sounds like a reasonable approach to me.

On unrelated note: thank you so much for the linked property! Jenkins running the scans upon CASC redeployments (and consequently rebuilding multibranch jobs configured with “merge PR with target branch”) have been plaguing us for quite some time. I believe this might a solution for us

3

I don’t have the Job in my hand, they are created by the Job-DSL test(s) - so I am unable to modify them, a property to disable the trigger like you can do for the MultibranchPipeline DSL tests would be nice.
The code just has this:

    @Unroll
	def 'test script #file.parentFile.name / #file.name'(File file) {
		given:
		def jobManagement = new JenkinsJobManagement(System.out, [:], new File('.'))

		when:
		new DslScriptLoader(jobManagement).runScript(file.text)

		then:
		noExceptionThrown()

		where:
		file << new FileNameFinder().getFileNames('src/main/groovy', '**/*.groovy').collect { new File(it) }
	}

On the unrelated note: Your welcome :wink:

4

I am unsure if it exists :person_shrugging:

From what I see in the plugin code:

  • DslScriptLoader extends AbstractDslScriptLoader<JobParent, GeneratedItems>
  • AbstractDslScriptLoader’s runScripts() returns an instance of generic type G
  • The class itself has <S extends JobParent, G extends GeneratedItems>
  • GeneratedItems has final Set<GeneratedJob> jobs
  • GeneratedJob unfortunately only stores jobName string
  • But JenkinsRule (you should have one since you’re using Harness) has jenkins public field
  • Jenkins in turn can get items by name
  • And finally WorkflowJob – which defines a pipeline – implements the TopLevelItem returned by getItme()

So I believe your code can be transformed to this (pseudocode, not tested):

		when:
		new DslScriptLoader(jobManagement).runScript(file.text)
		    .jobs.collect { it.jobName }
		    .collect {
		        jenkinsRule.jenkins.getItem(it) as WorkflowJob
		    }
		    .each { it.setTriggers([]) }

		then:
		noExceptionThrown()

Messy, but I could not think of a better solution assuming we did not find any property to handle this.
You might want to extract all this into a helper function to be used across test classes and methods.

5

Nice idea, could try that - but that would all happen after runScript already ran and the Trigger could have “triggered” already, right?
But I may have another idea, looking at ScmTrigger it asks SCMDecisionHandler for a decision on polling for changes - so in theory, I could just write a handler which does:

    @Override
	public boolean shouldPoll(@NonNull Item item) {
		return false;
	}

And it should never poll anything and trigger a build from that - I need to find time to setup [0], build an extension just for my testcase with that Handler and it should work - untested yet though.

Update: Did test it, works like expected.

[0] GitHub - jenkinsci/gradle-jpi-plugin: Build Jenkins Plugins with Gradle

1 Like
6

I had to confirm that theory and I can confirm, that just works like expected. Thanks @Artalus for the push to dig through the code again :wink: .

1 Like