axion-release-plugin
axion-release-plugin copied to clipboard
Plugin won't work if not in the root of git repository
$ git describe
1.2.3-1-gc18d12c
When executed from subdirectory I expect
$ ./gradlew cV -q
Project version: 1.2.3-SNAPSHOT
But actually I get
$ ./gradlew cV -s
> Configure project :
Failed to open repository, trying to work without it org.eclipse.jgit.errors.RepositoryNotFoundException: repository not found: ********
Could not resolve current position on uninitialized repository, returning default
Couldn't perform check uncommitted changes command on uninitialized repository
> Task :currentVersion
Project version: 0.1.0-SNAPSHOT
Plugin version: 1.9.1
Tested environments environments
JVM: 1.8.0_171 (Oracle Corporation 25.171-b11)
OS: Mac OS X 10.13.4 x86_64
JVM: 1.8.0_171 (Oracle Corporation 25.171-b10)
OS: Linux 3.10.0-862.3.2.el7.x86_64 amd64
Looked briefly through the source and I'm not familiar with JGit at all, but seems that plugin doesn't even intend to support my use-case. Please clarify if that's the case.
class RepositoryConfigFactory {
...
static RepositoryConfig create(Project project) {
RepositoryConfig config = new RepositoryConfig()
config.directory = project.rootDir // <- this
Eventually this value is passed to Git.open, and its javadoc says, that the directory is expected to contain .git directory in it.
My directory structure is like this:
.
|-- .git/
`-- my-project/
`-- build.gradle
axion-release supports setting arbitrary path as git root via:
scmVersion {
repository {
directory = project.rootProject.file('../')
}
}
Did you try it? You can find more in docs.
Ooops. Missed that. Thanks for pointing out.
Setting it explicitly is for sure more flexible, than detecting automatically as I tried to do in the pr.
What if two approaches are combined? If the directory is not set explicitly, try to detect it, not just fallback to project root.
It's not even a proposal or feature request, merely a question. I see a benefit for my case, but there may be downsides to this approach, which I'm missing.
By autodetect you mean go up the directory tree? This is actually how Gradle project detection works (or used to work). It traverses directories until it finds settings.gradle file, which describes the project and it becomes project root.
This could work, but i'm afraid it has quite a lot of potentially hard-to-debug side effects for the ones not aware of it, like creating release or reading version from some other repo? I think i would like to keep this simple and explicit for now.
Yes by autodetect I mean go up the tree (JGit does this for us). The only difference would be, that it could go farther, than settings.gradle. So behavior won't change if
- a project already has
.gitandsettings.gradlein same directoryA/. Autodetection result will beproject.rootDir, which isA/. - a project is correctly configured, and has
.gitinA/, andsettings.gradleinA/**/N/. Such project must havedirectoryexplicitly set (otherwise it wouldn't work). And since it's set, autodetection shouldn't be used.
Behavior will be different only for new projects, that have .git in A/, and settings.gradle in A/**/N/ and do not set directory explicitly. In this case autodetection result will be A/.
I agree, though, that this is a complication of the code base, and the benefit is purely cosmetic. Hence, probably, it doesn't justify the effort.
In any case, thanks for help and for an amazing plugin.
Thanks for the kind words ;)
I'm not saying that this feature is not useful and if i see some more demand in the future I might get back to this, but i'm glad that you understand that for now it might not be worth the effort (including future maintenance & debugging) since there is an explicit way to do this.
Hi. I'm reopening this issue because I've found a use case where autodetection of the .git/ directory is a valid use-case and codebase complication is justified (to my belief).
If a project with axion-release plugin is cloned as a git submodule, the plugin will fail to detect .git/ correctly. Setting it explicitly the way you offered before is not an option as we can't possibly know, how exactly the project will be cloned.
Here's the repo that demonstrates the issue https://github.com/edio/axion-release_issue249
Would be amazing to have this fixed. I can't offer a PR atm, but may have some free time in September.