https://gradle.com/ logo
Join Slack
Powered by
`./gradlew clean build` is running clean first gu...
# community-support
v
./gradlew clean build
is running clean first guaranteed? I always though this "single gradlew invocation with multiple tasks" syntax means to merge the tasks graphs and run as it makes sense - i.e. the exactly same thing as if I created a explicit task which 
dependsOn clean, build
but this doesn't seem to be the case as I'm trying it is it guaranteed?
t
https://docs.gradle.org/current/userguide/command_line_interface.html#:~:text=Although%20Gradle%20will%20execute%20the,when%20specified%20in%20that%20order.
Gradle will execute the build as quickly as possible, it will also respect the safety of the order of tasks specified on the command line and ensure that 
clean
runs before 
build
when specified in that order.
v
hmm what does that mean? will it merge subtasks if shared between the two explicit tasks? (if 
gradlew a b
, where a and b depend on c) i.e. youre saying it will execute c first then a before b because order - and if it were a plain task, a-b ordering is undeterministic?)
t
The doc is rather clear: if it's OK to execute 
a
before 
b
then that's what Gradle will do; otherwise it will execute 
b
first.
v
I understand, but im not clear on the shared stuff, will it run 
c
twice?
v
Nothing will ever run twice.
Gradle tries to maintain the order you specify on the commandline if dependencies allow
v
okay good to know, I always though its just cli level syntax for 
dependsOn
list
v
clean
should actually run before most other tasks automatically anyway, as it has a 
@Destroys
or what it was called for the stuff other tasks generate so should run first.
But anway, doing 
clean build
is a bad habit you bring over from Maven and that you should never do with Gradle.
➕ 2
If it is necessary to get a correct build result (like it often is with Maven builds), then you have a build bug you should fix.
If you don't have a build bug and use it, you just waste time as you disturb one of the most significant features of Gradle, which is to avoid unnecessary work.
But if you do 
clean
then you eradicate current outputs, so all work needs to be redone.
v
isnt this contrary what you said in the incremental cicd thread?
v
On CI/CD just use a clean checkout, then calling 
clean
is just wasting time
But not much, so it doesn't really matter
t
okay good to know, I always though its just cli level syntax for 
dependsOn
list
More or less yes, with an additional 
b.shouldRunAfter(a)
to maintain order if possible
👍 1
v
My comments I made just here were if you do that locally during daily work
v
well depends what the cicd looks like, i have mine running in container and the build folders are git ignores so they could leak from job to job
but yes sorry the context to this is a cicd pipeline creating release build
v
Better make them not to
Just use clean checkouts is much better
v
by clean checkouts you mean some gradle/git feature? or a docker level thing?
v
On your CI/CD you somehow get the code. This "somehow get" should simply be a fresh clean checkout / clone, then there is nothing stale lying around.
Or middle-ground, do a 
git clean -fdx
to remove everything not checked in.
A 
clean
could still not clean everything, depending on the build, unless you know for sure 
clean
does throw everything away. But actually it typically does not, but only throws away the 
build
directory.
v
I see thank you both!
r
I often run 
git clean -fdx
, but I always review the output of 
git clean -ndx
first. 
git clean -fdx
is one of the most destructive 
git
invocations, since it can delete untracked files. A slightly safer alternative is 
git clean -fdX
, which deletes ignored files only
v
For local builds, yeah, we were talking mainly about CI/CD and how to do a clean build there. 😉 Locally, also 
-i
to clean is nice as you can then filter some things out manually that should not be cleaned.
Or you switch to Jujutsu with having Git as backend (anyway the only public production ready one), then you also almost never loose untracked files, as there are no untracked (unignored) files, as the working-copy is a commit in itself and thus the untracked files are not untracked anymore as soon as some 
jj
command was run.
Open in Slack
PreviousNext
Powered by