Skip to content

Conversation

lacasseio
Copy link
Contributor

Context

See #2060.

Gradle Core Team Checklist

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation including proper use of @since and @Incubating annotations for all public APIs
  • Recognize contributor in release notes

eriwen and others added 2 commits May 26, 2017 14:51
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
@lacasseio lacasseio added this to the 4.0 RC1 milestone May 26, 2017
@lacasseio lacasseio self-assigned this May 26, 2017
@bmuschko bmuschko self-requested a review May 26, 2017 19:46
succeeds('baz')

then:
result.output.contains(":foo SKIPPED${EOL}:bar SKIPPED${EOL}:baz SKIPPED")
Copy link
Member

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")

Copy link
Contributor Author

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.*/
Copy link
Member

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@bmuschko bmuschko May 26, 2017

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) {}
Copy link
Member

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 noticed that too.

Copy link
Contributor Author

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.
*/
Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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));
Copy link
Member

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.

Copy link
Contributor Author

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;
Copy link
Member

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?

Copy link
Contributor Author

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) {}
Copy link
Contributor

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.*/
Copy link
Contributor

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.
*/
Copy link
Contributor

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;
Copy link
Contributor

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.

Copy link
Contributor

@adammurdoch adammurdoch left a 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.

@lacasseio
Copy link
Contributor Author

Using PR #2178 instead.

@lacasseio lacasseio closed this May 30, 2017
@lacasseio lacasseio deleted the dl/rich-dry-run branch May 31, 2017 22:13
@ov7a ov7a removed this from the 4.0 RC1 milestone Mar 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

a:feature A new functionality in:logging

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants