-
Notifications
You must be signed in to change notification settings - Fork 391
Update unset environment variables PR check #1269
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
Conversation
dc17b28
to
ab921b6
Compare
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.
This looks good. We could also consider removing support for earlier versions of the CLI — these are quite old now — but I'm happy with this approach.
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.
It's safer to quote all of the bash variables. I did it for cpp, and you should do the same for all the other languages.
Also, it might be nicer to include the expected location in the error message.
TEST_MODE: true | ||
- shell: bash | ||
run: | | ||
CPP_DB=${{ fromJson(steps.analysis.outputs.db-locations).cpp }} |
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.
CPP_DB=${{ fromJson(steps.analysis.outputs.db-locations).cpp }} | |
CPP_DB="${{ fromJson(steps.analysis.outputs.db-locations).cpp }}" |
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.
Have done this!
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'm curious — why does CPP_DB
not need the quotes here, but you've added them to its usage later on? Is it because it shouldn't be added while it's being assigned 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.
When you are defining a bash variable, you don't need quotes around its name, only its value. When you are using a bash variable, it should always be quoted.
If you don't quote at the appropriate times, whitespace will be considered separate arguments.
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.
Thank you!
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.
Here's an example. Let's say ${{ fromJson(steps.analysis.outputs.db-locations).cpp }}
resolves to /path/with a space
.
This command:
CPP_DB=${{ fromJson(steps.analysis.outputs.db-locations).cpp }}
will be interpreted as setting the variable CPP_DB/path/with
and apply this to a command a
with an argument space
.
CPP_DB="${{ fromJson(steps.analysis.outputs.db-locations).cpp }}"
Will simply set the CPP_DB
variable to /path/with a space
. Bash is arcane and learning all these rules takes a long time.
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.
Thanks for the example, that helps! I didn't realize that. Makes sense as to why the variable doesn't need quotes when it's being defined, then.
run: | | ||
CPP_DB=${{ fromJson(steps.analysis.outputs.db-locations).cpp }} | ||
if [[ ! -d $CPP_DB ]] || [[ ! $CPP_DB == ${{ runner.temp }}/customDbLocation/* ]]; then | ||
echo "Did not create a database for CPP, or created it in the wrong location." |
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.
echo "Did not create a database for CPP, or created it in the wrong location." | |
echo "Did not create a database for CPP, or created it in the wrong location. Expected it in $CPP_DB." |
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.
Interesting, I actually read the test differently — I thought expected would be at ${{ runner.temp }}/customDbLocation/*
and actual would be $CPP_DB
.
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.
Ah...apologies. You might be right here.
99cf52d
to
2bdcdfe
Compare
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.
Nice!
Hm.. the test is failing with
On the bright side, got to test the error message. Print debugging now |
JAVASCRIPT_DB="${{ fromJson(steps.analysis.outputs.db-locations).javascript }}" | ||
if [[ ! -d "$JAVASCRIPT_DB" ]] || [[ ! "$JAVASCRIPT_DB" == "${RUNNER_TEMP}/customDbLocation/*" ]]; then | ||
echo "Did not create a database for Javascript, or created it in the wrong location." \ | ||
if [[ ! -d "$JAVASCRIPT_DB" ]] || [[ ! "$JAVASCRIPT_DB" == "${RUNNER_TEMP}/customDbLocation/"* ]]; then |
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.
Is there a reason why *
is outside of the quotes? I don't think it changes the meaning. Also, does $JAVASCRIPT_DB
end in *
? I guess so, or else the workflow would be failing.
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.
Yes, it's a wildcard character when outside quotes. @adityasharad and I debugged the reason it failed just now and it was because *
was in the quotes and not considered a wildcard 😄
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.
Just looked at this one together -- you need the *
outside the quotes so that Bash glob-expands it, otherwise it gets treated as a literal *
character.
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.
Bash is awesome. :) Thanks for explaining.
Co-authored-by: Andrew Eisenberg <[email protected]>
There were some flaky runner tests that I had to re-run, but it's ready for review again. |
matrix: | ||
include: | ||
- os: ubuntu-latest | ||
version: stable-20210809 |
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.
Not much we can do about this, but we will need to remember to change this when we no longer support CLI v2.5.9.
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.
Yes, agreed (it's also present in all the other PR checks so we can change them all at once).
- shell: bash | ||
run: | | ||
CPP_DB="${{ fromJson(steps.analysis.outputs.db-locations).cpp }}" | ||
if [[ ! -d "$CPP_DB" ]] || [[ ! "$CPP_DB" == "${RUNNER_TEMP}/customDbLocation/"* ]]; then |
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.
So, why exactly do we need to glob here? Is it because we are not sure what the last segement of the directory will be named? And presumably, if there are two entries in the directory, this test will always fail? What if there is a whitespace in this directory segment? I think the test wuld fail, but can this conceivably happen?
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.
So, why exactly do we need to glob here? Is it because we are not sure what the last segement of the directory will be named?
I'm not exactly sure (I didn't write this test originally) — I think we could remove the *
and replace it with the name of the directory, which AFAIK is just the language (cpp
for example)
And presumably, if there are two entries in the directory, this test will always fail?
I don't think this is true, because currently the ${RUNNER_TEMP}/customDbLocation/
directory should have all the subdirectories named by each language in them.
What if there is a whitespace in this directory segment? I think the test wuld fail, but can this conceivably happen?
Which directory segment do you mean — the very last one that is just the language? I don't think it can happen, but if it did happen, I think it would fail too. Maybe it would just be better to explicitly write out the language rather than use the *
at all.
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.
Wild...I didn't know that. Just tried it out. if [[ "$var" == * ]];
will match if any file in the current directory matches $var
.
It would definitely be clearer if you replaced *
with the language name, but I don't think it's a blocker.
* Only test Java for CLI v2.5+ * Improve bash code style * Set Actions error messages Co-authored-by: Andrew Eisenberg <[email protected]>
The updated Go reconciliation changes surfaced a failing PR check that, upon closer look, was meant to fail previously due to a bug in the CLI in versions < 2.5.1 that didn't propagate environment variables needed by the tracer. This was fixed in v2.5.1.
Therefore this change splits the PR check into two:
stable-20210308
which was v2.4.5 orstable-20210319
which was v2.4.6).Merge / deployment checklist