Skip to content

[FLINK-39181 ][ci] Reduce Verbose DEBUG Logging in CI#27722

Open
MartijnVisser wants to merge 2 commits intoapache:masterfrom
MartijnVisser:worktree-disable-debug-logging
Open

[FLINK-39181 ][ci] Reduce Verbose DEBUG Logging in CI#27722
MartijnVisser wants to merge 2 commits intoapache:masterfrom
MartijnVisser:worktree-disable-debug-logging

Conversation

@MartijnVisser
Copy link
Contributor

What is the purpose of the change

CI test runs produce excessive DEBUG log output in the GitHub Actions console. The primary source is Maven Shade Plugin bytecode rewriting messages (Keeping original class bytecode, Rewrote class bytecode) that appear during test runs. The shade DEBUG flag (-Dorg.slf4j.simpleLogger.log.org.apache.maven.plugins.shade=DEBUG) was added globally in FLINK-38711 for the license checker, but it only needs to be active during the compile/deploy step. Additionally, log4j.properties enables DEBUG for ZooKeeper FinalRequestProcessor and leader election/retrieval packages, adding unnecessary noise to test log files.

Brief change log

  • Scope the shade plugin DEBUG logging flag from global Maven options to the specific compile.sh deploy invocation where ShadeParser/NoticeFileChecker needs it
  • Change ZooKeeper FinalRequestProcessor logger from DEBUG to INFO
  • Remove DEBUG-level logging for org.apache.flink.runtime.leaderretrieval and org.apache.flink.runtime.leaderelection

Verifying this change

This change is a trivial rework / code cleanup without any test coverage.

Full validation requires a CI run: the packaging/licensing job should pass (ShadeParser still sees DEBUG output from compile.sh), and test job console output should no longer contain shade plugin bytecode rewriting noise.

Does this pull request potentially affect one of the following parts:

  • Dependencies (does it add or upgrade a dependency): no
  • The public API, i.e., is any changed class annotated with @Public(Evolving): no
  • The serializers: no
  • The runtime per-record code paths (performance sensitive): no
  • Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
  • The S3 file system connector: no

Documentation

  • Does this pull request introduce a new feature? no

…in tests

Reduce verbose DEBUG log output in CI test runs by changing the
ZooKeeper FinalRequestProcessor logger from DEBUG to INFO and removing
DEBUG-level logging for leader election/retrieval packages.
Move the shade plugin DEBUG log flag from global Maven options to the
specific compile.sh deploy invocation where it is needed by the
ShadeParser and NoticeFileChecker. This prevents verbose bytecode
rewriting messages from flooding test run console output.
@flinkbot
Copy link
Collaborator

flinkbot commented Mar 2, 2026

CI report:

Bot commands The @flinkbot bot supports the following commands:
  • @flinkbot run azure re-run the last Azure build

logger.shaded_zookeeper.additivity = false
logger.shaded_zookeeper.appenderRef.zk.ref = ZooKeeperClientAppender

logger.leaderretrieval.name = org.apache.flink.runtime.leaderretrieval
Copy link
Contributor

Choose a reason for hiding this comment

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

I looked at the code in this package - the log.debugs in ZooKeeperLeaderRetrievalDriver are not enclosed with if (LOG.isDebugEnabled()) { . I suggest adding if (LOG.isDebugEnabled()) { around the 3 log.debugs. The one I am most concerned about is

# run with -T1 because our maven output parsers don't support multi-threaded builds
$MVN clean deploy -DaltDeploymentRepository=validation_repository::default::file:$MVN_VALIDATION_DIR -Dflink.convergence.phase=install -Pcheck-convergence \
-Dmaven.javadoc.skip=true -U -DskipTests "${@}" -T1 | tee $MVN_CLEAN_COMPILE_OUT
-Dmaven.javadoc.skip=true -U -DskipTests -Dorg.slf4j.simpleLogger.log.org.apache.maven.plugins.shade=DEBUG "${@}" -T1 | tee $MVN_CLEAN_COMPILE_OUT
Copy link
Contributor

Choose a reason for hiding this comment

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

can we check that LicenseChecker still works after that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Definitely, but I needed a CI run first to see it, then deliberately mess it up somewhere to trigger it, and then fix it afterwards again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants