Expose the resolved commit ID through GitSCMFileSystem.getRevision() when constructed via SCMFileSystem.of(Item, SCM)

[SalehAhmadi]

What feature do you want to see added?

Summary

GitSCMFileSystem resolves the head commit ID during construction and stores it in a private commitId field, but getRevision() returns null whenever the filesystem is created via the two-argument SCMFileSystem.of(Item, SCM) overload, even though the resolved commit is sitting in the object.
This makes it impossible for callers using that overload to obtain the exact commit a file (e.g. a Jenkinsfile) was read from, despite the data being available internally.

Current behaviour

In GitSCMFileSystem:

    protected GitSCMFileSystem(GitClient client, String remote, final String head, @CheckForNull
            AbstractGitSCMSource.SCMRevisionImpl rev) throws IOException, InterruptedException {
        super(rev);
        /// ...
        commitId = rev == null ? 
          invoke((Repository repository) -> repository.findRef(head).getObjectId()) : 
          ObjectId.fromString(rev.getHash());
    }

When BuilderImpl.build(Item owner, SCM scm, SCMRevision rev) is invoked through SCMFileSystem.of(Item, SCM), rev is null. The constructor resolves a real ObjectId via findRef(head) and stores it in commitId, but passes null to super(rev). Consequently getRevision() (inherited from SCMFileSystem) returns null and the resolved commit is unreachable from outside the class.

Proposed change

• After resolving commitId, construct an AbstractGitSCMSource.SCMRevisionImpl from it and pass that into super(...) (or assign it to the inherited revision field), so that getRevision() returns a non-null value reflecting the actually-resolved commit.
  Or
• keep the current constructor body and add a public getResolvedHead() (or override getRevision() directly) that returns an SCMRevisionImpl built from the existing private commitId field.

Why this matters

Downstream code needs to know the exact commit from which a Jenkinsfile or other repository file was loaded. The standard, SCM-agnostic API for that is SCMFileSystem.getRevision(). Subversion and Mercurial implementations return real revisions through this method; GitSCMFileSystem is the outlier in returning null for the (Item, SCM) path despite having the data.

AC

• SCMFileSystem.of(item, gitScm) returns a GitSCMFileSystem whose getRevision() is non-null and reflects the commit commitId resolves to.
• Behaviour is unchanged when the three-argument overload SCMFileSystem.of(scmSource, head, rev) is used with an explicit non-null rev.

Related

• The standalone CpsScmFlowDefinition build path in workflow-cps-plugin calls SCMFileSystem.of(build.getParent(), scm) to load the Jenkinsfile lightweight. With this change, that call site (and any equivalent in third-party plugins) gains visibility of the resolved commit through the standard API.
• The comment in workflow-multibranch-plugin/SCMVar.java refers to this same gap from a consumer's perspective.
• Related JIRA: JENKINS-31386, JENKINS-33273, JENKINS-42971.

Upstream changes

No response

Are you interested in contributing this feature?

No response