I believe your concern is that when using the UI to define the top level pipeline project (in a pipeline project that gets its Jenkinsfile from a git repository, or in a multi-branch pipeline), there are options displayed which will prevent the pipeline code from finding Jenkinsfile in the ...@script directory. I think you're right that we should disable presenting those options to the user when they are defining the top level pipeline project.

I think your statement:

As far as I can see, Additional Behaviors > Check out to a sub-directory is never appropriate with Pipeline.

is too broad, at least for my use case. I use checkout to a subdirectory to allow me to bring multiple repositories into a single workspace with simple calls to checkout. I could certainly replace those calls to checkout by nesting them inside a dir(), but I don't see why we should disallow my use of checkout to a subdirectory from inside a Jenkinsfile. I don't see how that would help users who (like me) can use "Pipeline Syntax" to show the options in that context, and use them.

Refer to the 35475 verification check Jenkinsfile for an example of how I use checkout to a subdirectory inside a Jenkinsfile.

However, I'm certainly open to further knowledge from jglick. I would rather not break compatibility with existing uses of the checkout command, unless there is a compelling reason to do so.

Since there is a generic way to select the base directory in Pipeline—dir—any historical SCM plugin options created for the benefit of freestyle projects are obsolete and should be considered deprecated in the context of Pipeline.

Maybe some more–or all–of these options should be removed when the project type is Pipeline.

jglick, perhaps you meant, "...are obsolete and should be considered..."

Thanks jglick, I've removed the remoteTargetDir setting from my pipeline test jobs. It will take a while before I have time to take any more active measures to hide that option from a pipeline user.

I stumpled upon the same issue.
We specified to checkout the git repository that contains the Jenkinsfile in a subdirectory.
All jobs failed because Jenkins failed to find the Jenkinsfile in the wrong directory.
Either:

• it must be ensured that 'Script Path' is relative to the specified checkout subdirectory or
• the option should be removed for specifying the repository for the Jenkinsfile

I would suggest making the behavior runtime print a warning to the build log if it is working on a non-AbstractBuild noting that it should not be used.

I agree that we should print a runtime warning. It would also be nice to add telemetry for some limited time (a month?) that would report when such a call was made. I believe the Jenkins project has the ability to define telemetry and this might be a good place to use that telemetry to decide if we can do more than warn users that they are using a deprecated feature in their PIpeline.

Hello jmcgeheeiv 
I am new to open source and Mark Waite asked me to look in this issue.
https://github.com/jenkinsci/jenkins
Is this the correct repo to work on? 

udit_damare sorry that you didn't receive a reply sooner. If you're interested in seeing an initial attempt at an implementation, refer to PR-1639. That implementation needs automated tests to confirm that the messages are written to the build log as expected, but my interactive testing confirmed that it works.

I'm not sure if the location of the warning is most convenient for the person reading the console log, but it does provide the warning message in the log.