Warn when 'Check out to a sub-directory' is used with Pipeline jobs (fixes #3068)

[Nimbusprogrammer]

Context

Using "Check out to a sub-directory" (RelativeTargetDirectory) in Pipeline jobs is confusing because Jenkins expects the Jenkinsfile in the workspace root, but this extension moves it to a subdirectory. The recommended approach for Pipelines is to use dir('subdir') { checkout scm }.

Changes

• Added a runtime check in RelativeTargetDirectory.java.
• If the current job is a Pipeline (WorkflowJob), a warning is now printed to the build log advising the user to use the dir step instead.

Testing

• Verified manually by creating a Pipeline job with the "Check out to a sub-directory" behavior.
• Confirmed the warning appears in the console output:
  [Warning] 'Check out to a sub-directory' is not intended for use with Pipeline jobs. Please use the 'dir' step instead.

Fixes #3068

[MarkEWaite]

Thanks for your interest in fixing issue:

• #3068

It needs a much broader approach, since there are many cases where an argument is available in Pipeline that should be replaced with a better alternative provided by other Pipeline steps.

Please use the contents of my previously closed pull request as a starting point for your change:

• #1639

It provides the broader approach and addresses many more areas.

That broader approach needs tests to be added that verify the expected message is inserted into the console log. Look at the usages of assertLogContains in src/test/java/hudson/plugins/git/GitHooksTest.java and src/test/java/jenkins/plugins/git/GitUsernamePasswordBindingTest.java for examples of the technique that is needed.

I think that I closed that earlier pull request by accident. I'd love to have you use that pull request as your starting point, add tests to confirm the change works as expected, then it can be checked in the plugin Bill of Materials and in the acceptance test harness to confirm that the changes do not break other plugins or other use cases.

[Nimbusprogrammer]

Thanks for the review. Summary of updates:

• Added an automated JUnit 5 test confirming that the warning is logged when RelativeTargetDirectory is used in a Pipeline job.
• Test located at: src/test/java/hudson/plugins/git/RelativeTargetDirectoryPipelineTest.java
• Verified the test passes locally.

Next steps:
• Reviewing PR #1639 to understand the broader approach.
• Will extend this fix incrementally based on that structure.

Appreciate the guidance.

[MarkEWaite]

Can you explain why you thought this was necessary? None of the other unit tests use this pattern of explicitly calling the before and after methods.

Suggested change

	@BeforeEach
	public void setupRepo() throws Throwable {
	sampleRepo.before();
	}
	@AfterEach
	public void tearDownRepo() {
	sampleRepo.after();
	}

[Nimbusprogrammer]

The manual before() / after() calls were needed because:

• GitSampleRepoRule is a JUnit 4 TestRule, but this plugin enforces JUnit 5 (via the “ban JUnit4 imports” Maven Enforcer rule).
• Since JUnit 4 @rule cannot be used, the rule does not auto-initialize in JUnit 5 tests.
• Without manual lifecycle calls, the test fails with:
IllegalStateException: the temporary folder has not yet been created
• Other tests using GitSampleRepoRule rely on a JUnit 4 runner to invoke the lifecycle automatically; this JUnit 5 test does not.
• Calling before() and after() manually is currently the only working method under JUnit 5.
• If there is a JUnit 5-native replacement for GitSampleRepoRule, I’m happy to migrate.

[MarkEWaite]

Thanks. I had missed that you are mixing JUnit 4 rules in a JUnit 5 test. There is a JUnit 5 annotation that can be used instead. Refer to https://github.com/jenkinsci/git-plugin/blob/master/src/test/java/hudson/plugins/git/CredentialsUserRemoteConfigTest.java for an example that uses WithGitSampleRepo in a JUnit 5 test

[MarkEWaite]

@strangelookingnerd is the most fluent on JUnit 5 transition. He may have other insights to offer

[strangelookingnerd]

To use GitSampleRepoRule with JUnit Jupiter you need to annotate the class with @WithGitSampleRepo. The object will be injected automatically once you define it as parameter for a @BeforeEach annotated method or the test method itself. There is no need to explicitly call before() and after().

The example linked by @MarkEWaite is just what you need to do.