-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Improvement usage of gradle task avoidance api #56627
Changes from 5 commits
7891b3c
460b9d8
389e729
ee40e99
85ee4b9
fdacb18
0e94641
fc0c73b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
jar { | ||
archiveName = "${project.name}.jar" | ||
archiveFileName = "${project.name}.jar" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. fix deprecation warning on the way |
||
manifest { | ||
attributes 'Main-Class': 'org.elasticsearch.gradle.reaper.Reaper' | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,6 +26,8 @@ import org.gradle.api.GradleException | |
import org.gradle.api.Task | ||
import org.gradle.api.tasks.Exec | ||
import org.gradle.api.tasks.Internal | ||
import org.gradle.api.tasks.TaskProvider | ||
|
||
/** | ||
* A fixture for integration tests which runs in a separate process launched by Ant. | ||
*/ | ||
|
@@ -79,7 +81,7 @@ class AntFixture extends AntTask implements Fixture { | |
return tmpFile.exists() | ||
} | ||
|
||
private final Task stopTask | ||
private final TaskProvider stopTask | ||
|
||
AntFixture() { | ||
stopTask = createStopTask() | ||
|
@@ -88,7 +90,7 @@ class AntFixture extends AntTask implements Fixture { | |
|
||
@Override | ||
@Internal | ||
Task getStopTask() { | ||
TaskProvider getStopTask() { | ||
return stopTask | ||
} | ||
|
||
|
@@ -222,24 +224,29 @@ class AntFixture extends AntTask implements Fixture { | |
} | ||
|
||
/** Adds a task to kill an elasticsearch node with the given pidfile */ | ||
private Task createStopTask() { | ||
private TaskProvider createStopTask() { | ||
final AntFixture fixture = this | ||
final Object pid = "${ -> fixture.pid }" | ||
Exec stop = project.tasks.create(name: "${name}#stop", type: LoggedExec) | ||
stop.onlyIf { fixture.pidFile.exists() } | ||
stop.doFirst { | ||
logger.info("Shutting down ${fixture.name} with pid ${pid}") | ||
} | ||
if (Os.isFamily(Os.FAMILY_WINDOWS)) { | ||
stop.executable = 'Taskkill' | ||
stop.args('/PID', pid, '/F') | ||
} else { | ||
stop.executable = 'kill' | ||
stop.args('-9', pid) | ||
} | ||
stop.doLast { | ||
project.delete(fixture.pidFile) | ||
TaskProvider<Exec> stop = project.tasks.register("${name}#stop", LoggedExec) | ||
stop.configure{ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: missing space There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. fixed |
||
onlyIf { fixture.pidFile.exists() } | ||
doFirst { | ||
logger.info("Shutting down ${fixture.name} with pid ${pid}") | ||
} | ||
|
||
if (Os.isFamily(Os.FAMILY_WINDOWS)) { | ||
executable = 'Taskkill' | ||
args('/PID', pid, '/F') | ||
} else { | ||
executable = 'kill' | ||
args('-9', pid) | ||
} | ||
doLast { | ||
project.delete(fixture.pidFile) | ||
} | ||
|
||
} | ||
|
||
return stop | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this strictly beneficial since this task rule should only run when it finds a task matching this naming convention, right? Granted, it doesn't hurt, just wondering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general I think we just should use register over create where possible. In a later step we need to revisit the actual behaviour and when they got materialised anyhow, but more on a per case fashion I think as thinks get complex there.
There are use cases where tasks in a rule would not be created but registered. You can depend on tasks that are created by a rule, e.g. you could have `myTask.dependsOn tasks.named("cleanCompileJava"). The rule would kick in so the task would be registered, but it doesn't need to be created.