Yeah, when you choose an option that requires a workspace (i.e., the "Polling ignores commits in certain paths"), you're stuck needing a workspace, strangely enough. =) In freestyle-land, when this scenario is encountered, a new build will get kicked off to get a new workspace to poll in, but I guess that's not happening for Pipeline (and I'm not sure we'd want it to happen for Pipeline - I'd like to avoid spamming builds in these sorts of situations). I don't have a quick answer for this, but I'll think on it.

abayer Would it make sense to reclassify this as an improvement?

Either that or close as a won't fix.

abayer Executing discretion here... it feels like this ought to be do-able in some way with enough cleverness without checking out to a build agent, but it's definitely not a bug. So reclassifying and dropping priority because it's kind of edge-casey and potentially complex as well.

svanoort - fwiw, if there's any possible resolution, it'd be to do what freestyle does (if I remember correctly) and kick off a build if polling requires a workspace but there isn't one available. Some polling options do always require a workspace, so that's what we've got to play with. shrug

We're running into this issue, although we're using the "polling ignores commits with certain message" additional behavior. I'm wondering if disabling lightweight checkout might be a work around. My understanding is that will cause the repo to be cloned on the master in order to get the Jenkinsfile. We use spot instances heavily for build agents, but master should always be up, and we'd definitely be willing to take the performance hit and do the comparison on a clone on master to get the build trigger behavior we want.