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

Add bazel command to explicit command line for workflows #8383

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

maggie-lou
Copy link
Contributor

Now the explicit command line will look like this (before it didn't include the bazelisk command):
Screenshot 2025-02-11 at 3 59 06 PM

The primary intention for this change is that the bb explain button assumes that the explicit command line includes the bazel binary. Currently we get errors like this

This will also make it more obvious which bazel binary is running for workflows

Copy link
Member

@bduffany bduffany left a comment

Choose a reason for hiding this comment

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

I feel like explicit command line might not be the right thing to use for the bb explain button. The explicit command line is sort of like "the raw text that the user entered into the terminal" and it doesn't feel like there's a strong guarantee that the command should be runnable outside that particular user's terminal environment? e.g. the user might have custom bazelrcs, env vars etc. and we can't guarantee that those will be set the same when we try to explain their invocation, if we're just using the explicit command line.

@maggie-lou
Copy link
Contributor Author

I feel like explicit command line might not be the right thing to use for the bb explain button. The explicit command line is sort of like "the raw text that the user entered into the terminal" and it doesn't feel like there's a strong guarantee that the command should be runnable outside that particular user's terminal environment? e.g. the user might have custom bazelrcs, env vars etc. and we can't guarantee that those will be set the same when we try to explain their invocation, if we're just using the explicit command line.

Maybe we should use effective command line then? Another additional consideration that both approaches fail at is if there's a redacted value

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.

2 participants