-
Notifications
You must be signed in to change notification settings - Fork 5k
Support --dry-run
in rich console
#2164
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
Conversation
This moves parsing of the --dry-run option to the logging module so that logging can be configured differently when attached to a terminal or using --console=rich. Issue: #2060
succeeds('baz') | ||
|
||
then: | ||
result.output.contains(":foo SKIPPED${EOL}:bar SKIPPED${EOL}:baz SKIPPED") |
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.
couldn't this just use the built-in parsing we have in the result?
e.g., result.assertTasksSkipped(":foo", ":bar", ":baz")
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.
Good point, done.
succeeds('baz') | ||
|
||
then: | ||
output =~ /(?s).*> Task :foo.*> Task :bar.*> Task :baz.*/ |
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.
could we use the grouped output fixture?
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.
I think we could assert on getOutput()
being empty for that task grouping.
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.
The rich output isn't connected to the result from the plain console. So we can't use the normal fixture for asserting order. If we find them in the output, it also means the --dry-run
is working as expected since they aren't printing any output.
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.
Wouldn't we also want to assert the concrete status here? I'd expect SKIPPED.
buildFile << """ | ||
task foo {} | ||
task bar(dependsOn: foo) {} | ||
task baz(dependsOn: bar) {} |
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.
We should give these tasks actions so they're not skipped by default.
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.
+1 noticed that too.
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.
Done.
|
||
/** | ||
* Enables or disables dry-run (log but do not perform task actions) mode. | ||
*/ |
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 necessary? It seems really weird to me that dry-run would be a logging option.
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.
I'd agree that it wouldn't see this as being part of logging.
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.
I think too and the execution goes through in WithLogging
class. At this point. we aren't parsing the entire StartParameter
. I don't know what would be the best choice for this. We could do like the parallel configuration and extra it to its own configuration class if you like.
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.
Yes, I think the better option is to only have a new method setDryRun(boolean)
on LoggingManagerInternal
. If you go for the AbstractCommandLineConverter
model then we wouldn't have to expose the new method to LoggingConfiguration
which is preferable from my perspective.
if (didHaveOutput) { | ||
spans.add(EOL); | ||
} | ||
spans.addAll(headerFormatter.format(loggingHeader, description, shortDescription, status)); |
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.
I wonder if we need to be careful with the amount of garbage we may be creating now.
We create a 2 new lists here on every header and only sometimes need the second one.
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.
Good point, I will rewrite the logic.
listener.onOutput(header()); | ||
} | ||
|
||
didHaveOutput = bufferedLogs.size() > 0; |
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.
I think it might be easier to follow this if we marked didHaveOutput
when we buffer? WDYT?
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.
We want to know if the last forwarded output had any output (except for the header). I don't think it would give the same result.
buildFile << """ | ||
task foo {} | ||
task bar(dependsOn: foo) {} | ||
task baz(dependsOn: bar) {} |
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.
+1 noticed that too.
succeeds('baz') | ||
|
||
then: | ||
output =~ /(?s).*> Task :foo.*> Task :bar.*> Task :baz.*/ |
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.
I think we could assert on getOutput()
being empty for that task grouping.
|
||
/** | ||
* Enables or disables dry-run (log but do not perform task actions) mode. | ||
*/ |
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.
I'd agree that it wouldn't see this as being part of logging.
import org.gradle.api.logging.LogLevel; | ||
|
||
public class DryRunChangeEvent extends OutputEvent { | ||
private boolean dryRunEnabled; |
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.
Should become a immutable final
field that is being passed in through the constructor.
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.
The 'dry-run' setting shouldn't be part of the logging configuration. Instead, the task execution events that the renderers receives should indicate whether the task was executed or not.
Alternatively, we should make --dry-run
a report and not even pretend to run the tasks.
Using PR #2178 instead. |
Context
See #2060.
Gradle Core Team Checklist
@since
and@Incubating
annotations for all public APIs