https://gradle.com/ logo
Join Slack
Powered by
if I'm depending on a 3rd party file like ```.git...
# community-support
c
if I'm depending on a 3rd party file like
Copy code
.git/config
that I never need to read in the task (it's just for change detection to decide with the task needs to be run
Copy code
@Input
  val gitConfig = project.layout.projectDirectory.dir(".git").file("config")
is right? I don't ever need 
filename
so this feels unintitive in a way. Also since the task technically mutates it, should it have both input and output on the same property? basically I want to run 
git config core.hooksPath .config/git/hooks
but only if it hasn't been run
v
No, that will fail with an error as you cannot use 
@Input
on a file input. 
@InputFile
(and probably with path sensitivity relative and normalize line endings too) would be to declare the file as input.
A task that modifies a file in-place is mostly always not a too good idea though. But yeah, you probably would want the file as input and output, and only on the 3rd run it will be up-to-date unless the task modifies the file on each and every run.
c
only on 3rd? why not 2nd? also would I extend the 
Exec
task? Obviously I never write tasks 😕
concurrently googling and hunting docs I promise 😉
v
Well, if the first run does not change the file then on 2nd, yes. But if on 1st run you change the file, then on 2nd run the input file has changed, so the task reruns. If the 2nd run does not further modify the file, it can be up-to-date on 3rd run.
That's one of the main problems with tasks that modify files in-place
You should seldomly extend built-in tasks. If you want to do 
Exec
and some more, it most often is better to use a custom task that uses 
ExecOperations#exec
in its action and does the additional work before or after that.
c
how do I get exec operations in my task 😕
v
Let Gradle inject it
c
ugh, ok, well it's partially working... I need to write a bug asking gradle to expose git stuff someday
because now I need to get the gitdir
this is turning into a fully fledged plugin
v
I don't think they will or should expose Git information. Gradle has nothing to do with Git. Otherwise it should also expose SVN information and BZR information and Perforce information and HG information, and ... 🙂
Also there are plugins or libraries that can give you Git information
c
and yet they do a whole lot of git stuff 😉
I know, I wrote one because they suck 😉
v
Well, yeah, indeed the source dependencies work with Git, that's right
c
I see no reason gradle couldn't expose the libraries that do this
yes, but most, if not all of those plugins are not configuration cache friendly
hence, I wrote my own
anyways, I have to go to work, problem for later
👋 1
v
Which probably is partly because JGit which most use does one native executable call while initializing and that even on a separate thread which even makes it hard to use properly in a value source
c
yep
but gradle already uses jgit, and so it could expose it
because gradle must already deal with that itself
anyways, wark! I'm late 😉
well... last question on this, if the output file changes external to the task, would that invalidate the task?
v
because gradle must already deal with that itself
It does not have to, source dependencies are still experimental and also not CC-compatible: https://github.com/gradle/gradle/issues/13506 🙂
well... last question on this, if the output file changes external to the task, would that invalidate the task?
Of course even if you would not have it as task input it should make the task out-of-date iirc, but as you even have it declared as input, external change will definitely make it out-of-date.
4 Views
Open in Slack
PreviousNext
Powered by