run basic C++ aarch64 tests under qemu emulator#8391
Conversation
jtattermusch
changed the title
|
CC @janaknat |
|
@dlj-NaN can you please reassign as needed? |
jtattermusch
force-pushed
the
cpp_aarch64_emulated_tests
branch
from
68a062f to
c3ab9b2
Compare
jtattermusch
force-pushed
the
cpp_aarch64_emulated_tests
branch
from
c3ab9b2 to
2893e49
Compare
jtattermusch
force-pushed
the
cpp_aarch64_emulated_tests
branch
from
2893e49 to
1d22218
Compare
jtattermusch
force-pushed
the
cpp_aarch64_emulated_tests
branch
from
1d22218 to
779144d
Compare
|
@dlj-NaN I verified that the tests are passing if run on kokoro CI. Please review. |
jtattermusch
force-pushed
the
cpp_aarch64_emulated_tests
branch
from
779144d to
64d0b29
Compare
|
@fowles please also review this PR. |
|
|
||
| # the wrapper script has CRLF line endings and bash doesn't like that | ||
| # so we change CRLF line endings into LF. | ||
| sed -i 's/\r//g' dockcross-linux-arm64.sh |
There was a problem hiding this comment.
does windows require this, or can we buy the gnome and fix the wrapper script?
There was a problem hiding this comment.
the "dockcross-linux-arm64.sh" is distributed as part of the dockcross/linux-arm64 image, so "fixing" the wrapper script would required opening a pull request against https://github.com/dockcross/dockcross, getting it accepted (maybe it does, maybe it doesn't) and then waiting for a new release of dockcross/linux-arm64 to actually get a fix. That seems as a way to lengthy process (and with uncertain outcome) to be able to rely on it.
Let's keep the sed command as is. I'll look into filing an issue with https://github.com/dockcross/dockcross so that hopefully this will get fixed in the future. But I really don't want to delay this PR because of it.
There was a problem hiding this comment.
the "dockcross-linux-arm64.sh" is distributed as part of the dockcross/linux-arm64 image, so "fixing" the wrapper script would required opening a pull request against https://github.com/dockcross/dockcross, getting it accepted (maybe it does, maybe it doesn't) and then waiting for a new release of dockcross/linux-arm64 to actually get a fix. That seems as a way to lengthy process (and with uncertain outcome) to be able to rely on it.
Let's keep the sed command as is. I'll look into filing an issue with https://github.com/dockcross/dockcross so that hopefully this will get fixed in the future. But I really don't want to delay this PR because of it.
|
|
||
| # Location of the build script in repository | ||
| build_file: "protobuf/kokoro/linux/cpp_aarch64/build.sh" | ||
| timeout_mins: 120 |
There was a problem hiding this comment.
2 hours is a really long time... Can we tighten this?
There was a problem hiding this comment.
Actually, 120 is the lowest value that protobuf's kokoro .cfg files use (and it's used by many jobs including python, ruby etc.) and it's the most commonly used timeout value, so I simply reused it. (Btw, for some jobs, the timeout value is even much higher)
I can reduce this to e.g. 60 (in reality it takes only about 10mins, but it's useful to have some buffer) if you want, but basically I feel this should be done in a separate effort to set all the protobuf's kokoro jobs to a reasonable timeout (which is unrelated to this PR).
jtattermusch
left a comment
jtattermusch
left a comment
There was a problem hiding this comment.
Responded to all the concerns.
|
|
||
| # the wrapper script has CRLF line endings and bash doesn't like that | ||
| # so we change CRLF line endings into LF. | ||
| sed -i 's/\r//g' dockcross-linux-arm64.sh |
There was a problem hiding this comment.
the "dockcross-linux-arm64.sh" is distributed as part of the dockcross/linux-arm64 image, so "fixing" the wrapper script would required opening a pull request against https://github.com/dockcross/dockcross, getting it accepted (maybe it does, maybe it doesn't) and then waiting for a new release of dockcross/linux-arm64 to actually get a fix. That seems as a way to lengthy process (and with uncertain outcome) to be able to rely on it.
Let's keep the sed command as is. I'll look into filing an issue with https://github.com/dockcross/dockcross so that hopefully this will get fixed in the future. But I really don't want to delay this PR because of it.
|
|
||
| # Location of the build script in repository | ||
| build_file: "protobuf/kokoro/linux/cpp_aarch64/build.sh" | ||
| timeout_mins: 120 |
There was a problem hiding this comment.
Actually, 120 is the lowest value that protobuf's kokoro .cfg files use (and it's used by many jobs including python, ruby etc.) and it's the most commonly used timeout value, so I simply reused it. (Btw, for some jobs, the timeout value is even much higher)
I can reduce this to e.g. 60 (in reality it takes only about 10mins, but it's useful to have some buffer) if you want, but basically I feel this should be done in a separate effort to set all the protobuf's kokoro jobs to a reasonable timeout (which is unrelated to this PR).
|
|
||
| # the wrapper script has CRLF line endings and bash doesn't like that | ||
| # so we change CRLF line endings into LF. | ||
| sed -i 's/\r//g' dockcross-linux-arm64.sh |
There was a problem hiding this comment.
the "dockcross-linux-arm64.sh" is distributed as part of the dockcross/linux-arm64 image, so "fixing" the wrapper script would required opening a pull request against https://github.com/dockcross/dockcross, getting it accepted (maybe it does, maybe it doesn't) and then waiting for a new release of dockcross/linux-arm64 to actually get a fix. That seems as a way to lengthy process (and with uncertain outcome) to be able to rely on it.
Let's keep the sed command as is. I'll look into filing an issue with https://github.com/dockcross/dockcross so that hopefully this will get fixed in the future. But I really don't want to delay this PR because of it.
4 participants
Add a script that crosscompiles C++ under a crosscompiler (and uses dockcross docker image for that) and then runs C++ test suite under QEMU emulator.
kokoro/linux/aarch64/test_cpp_aarch64.shWhat the kokoro test output would look like if the kokoro job was already created (I used a hack to obtain an adhoc run):
sponge/988880f9-7e8f-465b-8ff9-9483d6ce2f0d