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

printlns interfere with show during first time setup #2811

Closed
ghostbuster91 opened this issue Oct 2, 2023 · 4 comments · Fixed by #2839
Closed

printlns interfere with show during first time setup #2811

ghostbuster91 opened this issue Oct 2, 2023 · 4 comments · Fixed by #2839
Labels
bug The issue represents an bug
Milestone

Comments

@ghostbuster91
Copy link

ghostbuster91 commented Oct 2, 2023

Hi,

When calling ./mill show version for the very first time on a new machine mill will print on stdout:

Preparing Java 17.0.8.1 runtime; this may take a minute or two ...
"0.1.1"

Expected behavior

Stdout should only contain the result of the show command nothing besides that.

Actual behavior

Stdout contains information about preparing java together with results of the show command.

Reproduction steps

Use following docker file:

FROM ubuntu:22.04

# Install OpenJDK-8
RUN apt-get update && \
    apt-get install -y openjdk-17-jdk curl jq && \
    apt-get clean;

COPY . /src/
WORKDIR /src
RUN ./mill show version > output
RUN cat output

mill-version: 0.11.4

The offending line is here

s"Preparing Java ${System.getProperty("java.version")} runtime; this may take a minute or two ..."

Somehow related to #2680

@lefou
Copy link
Member

lefou commented Oct 2, 2023

Looks reasonable. Instead, we should use the logger in scope, as it's using output streams that get properly redirected by show.

@lefou lefou added the bug The issue represents an bug label Oct 2, 2023
@kubukoz
Copy link
Contributor

kubukoz commented Oct 2, 2023

@lefou any idea why it wasn't ultimately solved by #2689 ?

@lihaoyi
Copy link
Member

lihaoyi commented Oct 3, 2023

The setting up of the Java runtime happens pretty early; it might possibly happen before we set up the stream redirection

@lefou
Copy link
Member

lefou commented Oct 6, 2023

@lefou any idea why it wasn't ultimately solved by #2689 ?

No, not really. The code location you linked is already inside a SystemStreams.withStreams block, so any configured redirections to System.{in,out,err} and Console.{in,out,err} should be in place. Some debugging might be necessary to better understand what's going on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue represents an bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants