Skip to content
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

Rationalize logging subsystem #400

Merged
merged 7 commits into from Jan 18, 2023
Merged

Rationalize logging subsystem #400

merged 7 commits into from Jan 18, 2023

Conversation

basil
Copy link
Member

@basil basil commented Jan 13, 2023

Problem

This component used Logback for logging, which is not wrong but just different from the rest of the Jenkins ecosystem, which uses JUL. Additionally, it used a mix of log statements and System.out or System.err for logging. Finally, many of the log statements were overly noisy or contained grammatical erors.

Solution

Get rid of Logback and use the standard JUL logging backend for printing logs. Convert all System.out or System.err statements to use logging APIs. Remove noisy logs and clean up grammatical errors.

Implementation

First I got rid of Logback. Then I added a new logging.properties file that references our project-wide standard SupportLogFormatter to format log files. For production this is enabled by a static initializer in PluginCompatTesterCli (I tried to find a way to add a MANIFEST.MF entry to do this, but there was none). For tests this is enabled by adding -Djava.util.logging.config.class=org.jenkins.tools.test.logging.LoggingConfiguration in the Surefire configuration.

Testing done

Tested in context in jenkinsci/bom.

basil added a commit to basil/bom that referenced this pull request Jan 14, 2023
@basil basil marked this pull request as ready for review January 14, 2023 16:08
@basil basil requested a review from a team as a code owner January 14, 2023 16:08
@basil basil requested a review from jtnord January 14, 2023 16:08
@@ -1,13 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
Copy link
Member Author

Choose a reason for hiding this comment

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

With the removal of Logback this is no longer needed and has therefore been deleted.

@@ -26,8 +26,8 @@
<properties>
<changelist>999999-SNAPSHOT</changelist>
<gitHubRepo>jenkinsci/plugin-compat-tester</gitHubRepo>
<logbackVersion>1.4.5</logbackVersion>
Copy link
Member Author

Choose a reason for hiding this comment

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

With the removal of Logback this is no longer needed and has therefore been deleted.

<maven.scm.providers.version>1.6</maven.scm.providers.version>
<slf4j.version>2.0.6</slf4j.version>
Copy link
Member Author

Choose a reason for hiding this comment

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

Since we now need to define this version for both slf4j-api and slf4j-jdk14, extracting it to a property to eliminate duplication. This matches what we do in Jenkins core.

@@ -46,27 +46,12 @@
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>2.0.6</version>
<version>${slf4j.version}</version>
Copy link
Member Author

Choose a reason for hiding this comment

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

Consuming the new property in the original consumer. It will also be consumed later on in a new consumer (slf4j-jdk14).

Comment on lines -55 to -69
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-access</artifactId>
<version>${logbackVersion}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logbackVersion}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>${logbackVersion}</version>
</dependency>
Copy link
Member Author

Choose a reason for hiding this comment

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

With the removal of Logback this is no longer needed and has therefore been deleted.

"Will try to ignore it (FTR https://issues.jenkins-ci.org/browse/JENKINS-55169). " +
"hpiRemoteUrl={1}, pomFile={2}",
new Object[] {artifactId, hpiRemoteUrl, pomFile});
LOGGER.log(Level.FINE, "No parent POM for {0}", artifactId);
Copy link
Member Author

Choose a reason for hiding this comment

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

Also downgrading this to fine: this is a common scenario, so no need to scare the user with a warning.

@@ -103,19 +107,18 @@ private Map<String, Object> runHooks(String stage, Map<String, Object> elements)
// Modifications build on each other, pertinent checks should be handled in the hook
for(PluginCompatTesterHook hook : beforeHooks) {
try {
System.out.println("Processing " + hook.getClass().getName());
Copy link
Member Author

Choose a reason for hiding this comment

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

This was printing a message for every hook, even hooks that we weren't executing. I think it makes more sense not to spam the user with hooks that are not running. This PR rather only prints INFO-level logs for hooks that actually do run.

if(!excludeHooks.contains(hook.getClass().getName()) && hook.check(elements)) {
LOGGER.log(Level.INFO, "Running hook: {0}", hook.getClass().getName());
Copy link
Member Author

Choose a reason for hiding this comment

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

Print the "running hook" message only for hooks that are actually running.

elements = hook.action(elements);
hook.validate(elements);
} else {
System.out.println("Hook not triggered. Continuing.");
LOGGER.log(Level.FINE, "Skipping hook: {0}", hook.getClass().getName());
Copy link
Member Author

Choose a reason for hiding this comment

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

We still print a message for skipped hooks but leave it to FINE level since this should typically only be relevant when debugging something while developing a hooks-related change.

@@ -179,7 +182,7 @@ private Map<String, Queue<PluginCompatTesterHook>> findHooks(String stage) {
// Ignore abstract hooks
if (!Modifier.isAbstract(c.getModifiers())) {
try {
System.out.println("Hook: " + c.getName());
LOGGER.log(Level.FINE, "Loading hook: {0}", c.getName());
Copy link
Member Author

Choose a reason for hiding this comment

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

Similarly, this was creating a lot of log noise, one statement for each hook, even if the hook never got executed. Lowering this to FINE level since the typical user shouldn't care about hooks that aren't running; rather, this is relevant when debugging something while developing a hooks-related change.

@basil basil mentioned this pull request Jan 14, 2023
basil and others added 4 commits January 17, 2023 11:12
….java

Co-authored-by: James Nord <jtnord@users.noreply.github.com>
….java

Co-authored-by: James Nord <jtnord@users.noreply.github.com>
Co-authored-by: James Nord <jtnord@users.noreply.github.com>
…8670fa437150c50b75d380fb25052319e774#r1072679293
@basil
Copy link
Member Author

basil commented Jan 17, 2023

All feedback addressed from my perspective

@jtnord jtnord self-requested a review January 18, 2023 13:35
@jtnord
Copy link
Member

jtnord commented Jan 18, 2023

downstream closed source build is passing - this is good to merge from my perspective.

@basil basil merged commit 076df70 into master Jan 18, 2023
@basil basil deleted the logging branch January 18, 2023 15:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants