Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Env var run summary data generation #4529
Env var run summary data generation #4529
Changes from all commits
94e7806
07aab05
ea6592c
bc86c30
bb04a01
5ad4d22
c4f701d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that it's unnecessary if you're
rm -rf
'ing right before., but all the other tests explicitly get the first one withhead -n1
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mentioned that this didn't guarantee ordering in some other test so I took this strategy.
Why was the ksuid ordering not guaranteed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't remember the details to dig it up again, but I'm 99% sure that was an incorrect statement and I solved the issue I was seeing a different way. I think it's still safe to rely on ksuid ordering. (That said, it's not a requirement since
rm && cat
already does what we need).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine since we're still experimental, but I was under the impression that the value of pass through vars is not part of the hash. If that's still the case, the run summary could also probably omit the values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that your concern is unnecessarily conflating "is part of run summary" with "is part of hash". There are lots of things in the output that aren't (intentionally) included in the hash so this doesn't strike me as a problem. We can address this in any UI: "highlight the hash inputs".
I explicitly went through to add this because being able to unmask that value in the future if you can guess the input to the hash is super-valuable to discover why the run outputs are what they are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't intend it as that. My view is that the summary is a good way to understand what the tool did. If it's not doing anything with a thing, it doesn't need to be reflected back to the user. In this case, my earlier comment is promoted by the fact that we do something with the env var keys, but nothing with their values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But we are doing something with it! We're passing that KV env pair into the environment! And it's going to be different on different people's boxes, but the hash will still be the same!
Of all the places where we decide whether or not to capture this information I believe this is the most important one to capture.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure we're doing something with it. But said a different way, turbo doesn't care about the values of those env vars. Turbo is concerned with the list of keys. For
globalEnv
, Turbo cares about both the keys and the values. That's the difference I'm trying to point to.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's really my distinction too:
turbo
may not care other than shuffling the correct things into the environment, but the user definitely cares what actually ended up there.We should be doing things for the user.