[JENKINS-42971] New API for SCMFileSystem to allow for lightweight checkout with build params

[MartinKosicky]

https://issues.jenkins.io/browse/JENKINS-42971

I added a new Builder class into the SCMFileSystem so that we have backward compatibility with current SCM implementations and with ability for a new implementation, so that they can make for example branch substitutions based on parameters in the build (environment).

[MartinKosicky]

I would fix the blockers ASAP but first I would like some feedback if this concept does make sence, or if you would prefer a different approach. I dont have problems doing it, but I dont want to do major fixes if I am not sure I am on the right track :)

[MartinKosicky]

I checked it working by updating workflow-cps plugin and done some local changes to git plugin, that can be only added for PR if this PR will be succesful

[jglick]

that can be only added for PR if this PR will be successful

FYI once you have a passing build of a PR up to date with its base branch, you will get an “Incrementals” check (here, https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/scm-api/619.vb_7498d1edb_18/) and it is possible to refer to that version in the <dependencyManagement> section of a POM in a downstream plugin (git or workflow-cps, say). Typically we would open draft PRs downstream like

<dependency>
  <groupId>…</groupId>
  <artifactId>…</artifactId>
  <version>123.vdeadbeef9999</version> <!-- TODO https://github.com/jenkinsci/upstream-plugin/pull/123 -->
</dependency>

representing the link and permitting CI to run a full test suite in advance.

[jglick]

Did you look at #78?

[MartinKosicky]

I added draft jenkinsci/workflow-cps-plugin#577 and jenkinsci/git-plugin#1305

[MartinKosicky]

Hello @jglick , I would just like to ask if the current flow is that multiple reviewers have to approve or if there are any improvements I can do here regarding this scm-api :)

[jglick]

if the current flow is that multiple reviewers have to approve

Not in general, though for significant changes and especially API additions (which cannot generally be reverted if they turn out to be misconceived) I prefer to have a second opinion.

[MartinKosicky]

if the current flow is that multiple reviewers have to approve

Not in general, though for significant changes and especially API additions (which cannot generally be reverted if they turn out to be misconceived) I prefer to have a second opinion.

Yes that sounds reasonable. I will wait :)

[dwnusbaum]

The new APIs seem fine to me.