feat: Add DRIFT region tag parser to CI#4506
Conversation
|
python-3.7 build has a failure, and the new script is throwing an error: Seems like the script needs to be little bit more robust. Also, since you have changes in the Dockerfile, all the CI builds are full build. You can emulate the Kokoro full build with the following command: Full build takes long time, so you may prefer: This command only runs tests for directories that has changes from master. You can change some tests so that You can commit your Dockerfile changes into your local master, then you can deceive the test script. Anyways, full builds on Kokoro consume resources and interfere other PRs, so please be considerable. |
|
|
||
| # Inject region tag data into the test log | ||
| XUNIT_PATH="$PWD/sponge_log.xml" | ||
| XUNIT_TMP_PATH="$PWD/drift_tmp.xml" |
There was a problem hiding this comment.
Can you use temp directory for XUNIT_TMP_PATH?
There was a problem hiding this comment.
Done for XUNIT_TMP_PATH, though I think XUNIT_PATH needs to stay in $PWD.
|
|
||
| # install PyYaml (used by the DRIFT region tag parsing system) | ||
| pip install --user -q pyyaml | ||
|
|
There was a problem hiding this comment.
If we introduce an envvar, can we only install pyyaml if the envvar is set to true? Also I think it is ok to install the parser alongside of pyyaml.
Or even, how about to have requirements.txt in the parser repo and run pip install --user -r ${PARSER_DIR}/requirements.txt or sth?
There was a problem hiding this comment.
I got this working by installing pyyaml in a specific directory and adding that to the PYTHONPATH. (I think there are some virtualenv issues here that prevent the usual "pip install and go" approach, and this was the easiest workaround to implement.)
tmatsuo
left a comment
There was a problem hiding this comment.
You need to add INJECT_REGION_TAGS to pass_down_envvars in .trampolinerc
tmatsuo
left a comment
There was a problem hiding this comment.
Code looks good. Maybe we should run py-3.7 periodic build manually against the drift-parser-2 branch before merge. I'll start the build once the presubmit builds finish.
|
I run py37 periodic build against your branch: I think we have little more to fix. |
| # Setup DRIFT region tag parser | ||
| # (only run on *some* builds) | ||
| if [ "${INJECT_REGION_TAGS:-}" == "true" ]]; then | ||
| # install PyYaml (used by the DRIFT region tag parsing system) |
There was a problem hiding this comment.
Ditto for missing bracket.
It's not obvious from the log, so can you add info log?
echo "Downloading region tag parser"
or something?
Also, do you prefer always installing it from HEAD?
If you install with a SHA1 hash or release tag, can you also log the hash or the release tag?
There was a problem hiding this comment.
- Fixed missing bracket
- Added debug log statements
- Yes - installing from
HEADis the intent here (esp. since we don't need to use a commit hash to bust Docker caches!)
There was a problem hiding this comment.
Ok, this raises another question. How is the parser script tested?
There was a problem hiding this comment.
The Python script itself is fetched from this repo; there are tests in that folder.
(There aren't any [new] tests for the .sh testing scripts.)
There was a problem hiding this comment.
Do you have CI builds setup?
There was a problem hiding this comment.
Not yet - though we plan to add them in the coming months.
(If you'd prefer to do that immediately after merging this PR though, that can be done.)
There was a problem hiding this comment.
Well, then the script might be not tested. We'll need extra caution because the script might fail.
There was a problem hiding this comment.
Also, the script might empty the xml file. If that happens, we'll lost all the reporting capabilities including build cop bot issues.
I'd like you to setup CI on your repo before merging this.
Also, I don't think we should use redirect (>) here. Because if the script exit 0, but produces no output, then we'll loose all the test logs.
|
Reran the |
| # Setup DRIFT region tag parser | ||
| # (only run on *some* builds) | ||
| if [ "${INJECT_REGION_TAGS:-}" == "true" ]]; then | ||
| # install PyYaml (used by the DRIFT region tag parsing system) |
There was a problem hiding this comment.
Ok, this raises another question. How is the parser script tested?
| if [[ -f "$XUNIT_PATH" ]]; then | ||
| echo "=== Injecting region tags into XUnit output ===" | ||
| echo "Processing XUnit output file: $XUNIT_PATH" | ||
| cat "$XUNIT_PATH" | python3.7 "$PARSER_PATH" inject-snippet-mapping "$PWD" > "$XUNIT_TMP_PATH" |
There was a problem hiding this comment.
What happens when we remove python 3.7 from the docker image?
There was a problem hiding this comment.
Would it be better to use python3 here?
| # Setup DRIFT region tag parser | ||
| # (only run on *some* builds) | ||
| if [ "${INJECT_REGION_TAGS:-}" == "true" ]]; then | ||
| # install PyYaml (used by the DRIFT region tag parsing system) |
There was a problem hiding this comment.
Also, the script might empty the xml file. If that happens, we'll lost all the reporting capabilities including build cop bot issues.
I'd like you to setup CI on your repo before merging this.
Also, I don't think we should use redirect (>) here. Because if the script exit 0, but produces no output, then we'll loose all the test logs.
|
New periodic build |
tmatsuo
left a comment
There was a problem hiding this comment.
Also let me know once CI build is set up in the upstream repo.
|
|
||
| cat "$XUNIT_PATH" | python3.7 "$PARSER_PATH" inject-snippet-mapping --output_file "$XUNIT_TMP_PATH" "$PWD" | ||
| if [[ $? -eq 0 ]]; then | ||
| mv $XUNIT_TMP_PATH $XUNIT_PATH |
There was a problem hiding this comment.
Are you 100% sure that there is a file when the script exit with 0?
If not, please check the file existance.
Also, does it make sense to log something here as well?
There was a problem hiding this comment.
If the file at $XUNIT_TMP_PATH doesn't exist, then the mv command should fail.
IMO, logging something here would be overkill. 🙂
There was a problem hiding this comment.
So if mv fails, the test is marked as failed even if just the injection here failed?
I don't like it.
There was a problem hiding this comment.
Well, actually, there's no -e flag set in this file. So it may keep running.
I still like the explicit check, but I think I can live with the current code.
|
|
||
| export REGION_TAG_PARSER_DIR="/tmp/region-tag-parser" | ||
| export PARSER_PATH="${REGION_TAG_PARSER_DIR}/wizard-py/cli.py" | ||
| export PIP_PATH=/tmp/pyyaml |
There was a problem hiding this comment.
Why did you need PIP_PATH again?
Did you try:
pip install --user pyyaml -q
?
There was a problem hiding this comment.
IIRC, I did (and it didn't work).
There was a problem hiding this comment.
If memory serves, it couldn't find the package (so probably something like cannot find module 'yaml')
There was a problem hiding this comment.
I think --user flag should work.
Can you try this locally and paste the error log?
There was a problem hiding this comment.
If I use that line and remove the PYTHONPATH modification:
Processing XUnit output file: /workspace/functions/env_vars/sponge_log.xml (saving output to /tmp/tmp.I0Hx5IhTZh)
Traceback (most recent call last):
File "/tmp/region-tag-parser/wizard-py/cli.py", line 17, in <module>
import analyze
File "/tmp/region-tag-parser/wizard-py/analyze.py", line 19, in <module>
import yaml_utils
File "/tmp/region-tag-parser/wizard-py/yaml_utils.py", line 19, in <module>
import yaml
ModuleNotFoundError: No module named 'yaml'
If we're going to use --user instead of specifying a target directory, we'll probably need to tell Python what directory --user corresponds to (via PYTHONPATH).
There was a problem hiding this comment.
Hmm maybe the package is being installed to a pip associated with a different Python version. Could you try something like python3.7 -m pip install ...?
|
|
||
| cat "$XUNIT_PATH" | python3.7 "$PARSER_PATH" inject-snippet-mapping --output_file "$XUNIT_TMP_PATH" "$PWD" | ||
| if [[ $? -eq 0 ]]; then | ||
| mv $XUNIT_TMP_PATH $XUNIT_PATH |
There was a problem hiding this comment.
So if mv fails, the test is marked as failed even if just the injection here failed?
I don't like it.
Maybe the cleaner answer here (instead of including a bunch of checks) is to wrap this section like this? |
|
@ace-n |
I'm not entirely against it, but explicitly checking for every edge case makes this more complex (and in my view, harder to maintain). Personally, I think the |
|
@ace-n However, I think being explicit and verbose logging will help us debug things if something wrong happens. I still recommend my approach. |
|
@tmatsuo I went ahead and added a file existence check. I also added |
busunkim96
left a comment
There was a problem hiding this comment.
LGTM if @tmatsuo approves.
(Stamping to make this auto-mergeable once Takashi approves the changes)
|
FYI @tmatsuo build failures are unrelated to this PR. |
| if [[ "${INJECT_REGION_TAGS:-}" == "true" ]]; then | ||
| export REGION_TAG_PARSER_DIR="/tmp/region-tag-parser" | ||
| export PARSER_PATH="${REGION_TAG_PARSER_DIR}/wizard-py/cli.py" | ||
| export PIP_PATH=/tmp/pyyaml |
|
Test failures are known ones, let's merge this. |
Cleaned-up version of #4402
@jmdobry FYI