Expose getVersionDetails() method on GitVersionPlugin

[palantir-sachin]

Summary

Expose getVersionDetails() method on GitVersionPlugin to allow programmatic access to version details.

Why

Previously, version details were only accessible through the gitVersion() closure or by running the printVersion task. This change enables other Gradle plugins and build scripts to programmatically access detailed version information (branch name, git hash, etc.) through the plugin instance itself

Example Use Case

# another plugin apply() method

        GitVersionPlugin gitVersionPlugin = project.getPlugins().apply(GitVersionPlugin.class);
        Provider<VersionDetails> versionDetails = gitVersionPlugin.getVersionDetails();

        Provider<String> originUrl = versionDetails.map(VersionDetails::getOriginUrl);
        Provider<String> branch = versionDetails.map(VersionDetails::getBranchName);

==COMMIT_MSG==
Expose getVersionDetails() method on GitVersionPlugin
==COMMIT_MSG==

[changelog-app]

Generate changelog in changelog/@unreleased

Type (Select exactly one)

• Feature (Adding new functionality)
• Improvement (Improving existing functionality)
• Fix (Fixing an issue with existing functionality)
• Break (Creating a new major version by breaking public APIs)
• Deprecation (Removing functionality in a non-breaking way)
• Migration (Automatically moving data/functionality to a new system)

Description

Expose getVersionDetails() method on GitVersionPlugin

Check the box to generate changelog(s)

• Generate changelog entry

[changelog-app]

✅ Successfully generated changelog entry!

Need to regenerate?

Simply interact with the changelog bot comment again to regenerate these entries.

---

📋Changelog Preview

💡 Improvements

• Expose getVersionDetails() method on GitVersionPlugin (#1156)

[Copilot]

Pull request overview

This PR exposes the getVersionDetails() method on GitVersionPlugin to enable programmatic access to version information. Previously, version details were only accessible through the gitVersion() closure or the printVersion task.

Changes:

• Added a public getVersionDetails() method to GitVersionPlugin that returns a Provider<VersionDetails>
• Refactored GitVersionPlugin to use constructor injection, storing Project and service provider as instance fields
• Removed IOException from getBranchName() method signature in VersionDetails interface

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/main/java/com/palantir/gradle/gitversion/VersionDetails.java	Removed IOException from getBranchName() signature for consistency
src/main/java/com/palantir/gradle/gitversion/GitVersionPlugin.java	Added constructor injection and exposed getVersionDetails() method

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Initializing the serviceProvider in the constructor before apply() is called may cause issues if the GitVersionRootPlugin hasn't been applied yet. The service provider initialization depends on the root plugin being applied first (which happens in apply() at line 41), but this constructor runs before that. Consider lazy initialization or moving the serviceProvider initialization to after the root plugin is applied.

Suggested change

	this.serviceProvider = GitVersionCacheService.getSharedGitVersionCacheService(project);
	}
	@Override
	@SuppressWarnings("HiddenField")
	public void apply(final Project project) {
	project.getRootProject().getPluginManager().apply(GitVersionRootPlugin.class);
	}
	@Override
	@SuppressWarnings("HiddenField")
	public void apply(final Project project) {
	project.getRootProject().getPluginManager().apply(GitVersionRootPlugin.class);
	this.serviceProvider = GitVersionCacheService.getSharedGitVersionCacheService(project);

[Copilot]

The @SuppressWarnings("HiddenField") suppresses a warning about the parameter hiding the instance field. Since the instance field is now stored in the constructor, consider using this.project instead of the parameter throughout the apply() method to avoid this suppression and potential confusion about which project reference is being used.

[felixdesouza]

I feel like it's sufficient to just get the build service from wherever you plan to use this no?

[felixdesouza]

final

[felixdesouza]

let's call this cacheService

[felixdesouza]

don't think this applies anymore?

[felixdesouza]

I think we have to be careful here. It's not clear what will be selected when being referenced from buildscripts as getVersionDetails will be accessible via versionDetails in buildscripts (potentially).

I think the number of places where this actually works is limited since you have to get the result of the plugin application.

But now you have two methods that look very similar, but one returns a realised VersionDetails and the other returns a Provider<VersionDetails> . If I were scanning the code to see how something worked, I would not be surprised if I landed on this method, and got confused at what looks like magic, despite it actually being the closure method.

To resolve this, I think we should either:

• change the name of the method
• just get what we need by using the cache service directly instead.

[felixdesouza]

also this method is not the same as what you get in the closure. You're always passing null to the details. IIRC this method was added for the internal frontend monorepo, so it's also not clear whether this gets you want you want.