[dev qa test] test //... in buildbuddy_dev_qa_test
#10811
Conversation
sluongng
left a comment
sluongng
left a comment
There was a problem hiding this comment.
This brings the coverage of this test on par with the existing dev_qa.py test
The current dev_qa.py has this
"repo_url": "https://github.com/buildbuddy-io/buildbuddy",
"commit_sha": "a97d4303c9485db089a33a1049fe480d0122687d",
"command": """
bazel test //... \
...
--test_tag_filters=-docker,-bare,-performance \
So we are not quite on par?
| build:dev_qa_test --compilation_mode=fastbuild | ||
| build:dev_qa_test --host_compilation_mode=fastbuild |
There was a problem hiding this comment.
These should already be the default mode? any reason to set them explicitly?
There was a problem hiding this comment.
I added this flags while trying to get builds to work over different targets. Perhaps I can take them out now and things will just work! 🤞
There was a problem hiding this comment.
Keeping these fastbuild flags in allows test //... to run successfully.
Removing the flags yields failures. I'm not sure why. Doesn't seem awful to leave them in for now?
There was a problem hiding this comment.
Could you share an invocation with such failures? They are mildly concerning
There was a problem hiding this comment.
I found the (a?) problem: https://buildbuddy.buildbuddy.dev/invocation/9ae0f20d-61d8-48b0-be09-2be6b2b46800
That invocation does not pass --host_compilation_mode or --compilation_mode flags.
//server/version:populate_version tries to grep for STABLE_VERSION_TAG from bazel-out/stable-status.txt. I'm assuming that when building a release tarball, that file does not exist?
The populate_version target will simply touch $@ for fastbuild builds.
There was a problem hiding this comment.
One way to fix this would be to provide a default (such as dev) in case the grep fails.
Not quite. I'll try |
| build:dev_qa_test --workspace_status_command= | ||
| build:dev_qa_test --compilation_mode=fastbuild | ||
| build:dev_qa_test --host_compilation_mode=fastbuild | ||
| build:dev_qa_test --test_tag_filters=-block-network,-performance,-webdriver,-docker,-bare |
There was a problem hiding this comment.
why filter out tests with block-network?
There was a problem hiding this comment.
It was an attempt to avoid tests that caused the fetching of all the bazel binaries under //server/util/bazel.
Let me clear that filter and re-run.
There was a problem hiding this comment.
Running test //... without -block-network succeeds!
dan-stowell
changed the title
test //... in buildbuddy_dev_qa_test
This change allows the
buildbuddy_dev_qa_testtarget to run tests across the server, app, and enterprise directory trees. This brings the coverage of this test on par with the existingdev_qa.pytest (and on a much more recent version of the codebase, to boot). Once we have cut a release that includes this change, I'll point the dev qa workflow at the //tools/dev_qa_test/... targets.