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

Cannot disable logstream (in the obvious way) #4065

Open
rrjjvv opened this issue Apr 26, 2024 · 0 comments
Open

Cannot disable logstream (in the obvious way) #4065

rrjjvv opened this issue Apr 26, 2024 · 0 comments
Labels
type:bug Something isn't working

Comments

@rrjjvv
Copy link
Contributor

rrjjvv commented Apr 26, 2024

What went wrong?

While trying to diagnose #4063, I was unable to disable logstream via earthly --logstream=false as I would expect.

I realize this is a hidden flag, thus "unsupported", and may be more of a UX thing than a true bug.

What should have happened?

The workaround is to use earthly --logstream=false --logstream-upload=false.

if app.BaseCLI.Flags().LogstreamUpload {
app.BaseCLI.Flags().Logstream = true
}

I think the 'problem' is that the booleans don't allow a distinction of set vs. unset. It makes sense that uploads requires the local functionality to be enabled... when I want uploads. I didn't request uploads though; the default value for uploads shouldn't trump my explicit request to disable.

Ideally, in pseudocode, it would be something like:

LogstreamUpload := LogstreamUpload && (LogstreamUploadWasSet || (! Logstream && LogstreamWasSet))
// existing code

In other words, enable upload (thus local) if the user explicitly asked for it, or if the user did not explicitly opt-out of local.

I'm not knowledgeable about logstream, neither what it really does, or the relationship between those two modes; the proper solution may be more nuanced that just distinguishing between values that came from defaults vs. from users. I just know that logstream is a cause or contributor to #4063 and it was confusing why my initial attempts to disable it did not work.

It actually looks like you may have run into this as well in 5812dec#diff-f9982f795fe7027eb275c129ce300d01d3eeacfe77549152a9ab23cb8e18c95b, but I can't tell if that was a workaround for this 'bug', or if you consider this 'bug' a feature...

What earthly version?

This is in 0.8.9 and probably every version going back to 0.7.19

Buildkit Logs

No response

Other Helpful Information

No response

@rrjjvv rrjjvv added the type:bug Something isn't working label Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Something isn't working
Projects
Status: No status
Development

No branches or pull requests

1 participant