Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error getting GitPublishCommit.repoDirectory #60

Closed
grv87 opened this issue Oct 13, 2018 · 4 comments
Closed

Error getting GitPublishCommit.repoDirectory #60

grv87 opened this issue Oct 13, 2018 · 4 comments

Comments

@grv87
Copy link

grv87 commented Oct 13, 2018

I have custom diagnostic task that creates report about inputs and outputs of each task.

Unfortunately, I can't use it with this plugin:

Caused by: java.lang.IllegalStateException: No value has been specified for this provider.
        at org.gradle.api.internal.provider.Providers$1.get(Providers.java:32)
        at org.gradle.api.internal.provider.DefaultPropertyState.get(DefaultPropertyState.java:90)
        at org.gradle.api.internal.provider.DefaultPropertyState.get(DefaultPropertyState.java:90)
        at org.ajoberstar.gradle.git.publish.tasks.GitPublishCommit.getRepoDirectory(GitPublishCommit.java:40)
        at org.ajoberstar.gradle.git.publish.tasks.GitPublishCommit_Decorated.getRepoDirectory(Unknown Source)

I see that the problem is that grgit value is set during GitPublishReset task execution only:

Grgit git = findExistingRepo().orElseGet(() -> freshRepo());
grgit.set(git);

Maybe I don't understand something, but why it is not set just after property creation? It could still be lazy (maybe with additional provider).

@ajoberstar
Copy link
Owner

You can see the background in this commit. There may be some other ways to do it, but I'd like to keep up no providers and also avoid the logic happening multiple times.

@grv87
Copy link
Author

grv87 commented Oct 25, 2018

Hit this again in tests trying to disable all tasks via tasks*.enabled = false.

I see there is a logic error in current implementation.
GitPublishReset.grgit is a Property but its value is completely ignored and is overridden in reset.
What's the reason then to store it as a Property and to expose it publicly?

@ajoberstar
Copy link
Owner

Does making it a Provider instead of a Property (from a public perspective) improve the situation for you?

I basically need three things:

  • To only try to clone/open the repo once
  • To clone/open it only if you intend to use it (i.e. running the gitPublishReset task)
  • To share that repo instance across all tasks

In the current state of providers, setting it at task runtime is the cleanest way for me to handle this, though the current option does have the side effect that the Property's value would be ignored if already set.

Thinking about your input/output report use case, you may want to support Property/Providers that aren't set anyway. It doesn't seem invalid for a property to have no value.

@ysb33r
Copy link

ysb33r commented Jul 1, 2019

I ran into the same thing today. I put this seemingly innocent code in the the build script and it causes the issue.

['Reset','Push','Commit'].each {
    tasks.named("gitPublish${it}") {
        enabled = pushDocs
    }
}

Take the code out and it works.

Same thing happens with

['Reset','Push','Commit'].each {
    tasks.named("gitPublish${it}") {
        onlyIf {pushDocs}
    }
}

My only workaround is not to call gitPublishPush directly, but rather have a lifecycle publish task which will only depend on the gitPublish* tasks if my variable pushDocs is set.

@ajoberstar You might be better off if the project extension creates the GrGit object rather that the task. You can still have it created on demand. It is also better in my experience to use Provider rather than Property.

ajoberstar added a commit that referenced this issue Feb 10, 2022
Fixes #60
Fixes #70
Fixes #79
Fixes #85
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants