Delete no longer needed artifact_linux dockerfiles#25542
Delete no longer needed artifact_linux dockerfiles#25542jtattermusch merged 2 commits intogrpc:masterfrom
Conversation
|
adhoc distribtest run: https://fusion2.corp.google.com/invocations/592493a5-5a79-46af-b431-a9de224bd052/targets |
|
Another adhoc distribtest run: https://fusion2.corp.google.com/invocations/68ca8ac1-97e8-43fb-9576-4f1dd2819a12/targets |
|
This might be a problem: |
a0c12d5 to
88fe51d
Compare
|
CC @lidizheng please review, @apolcyn owners approval please |
|
Another invocation of the adhoc artifact - packages - distribtests build |
lidizheng
left a comment
There was a problem hiding this comment.
Great improvement! Two Docker images less.
jtattermusch
left a comment
There was a problem hiding this comment.
Forgot to send my clarification on some of the changes. Doing that now.
| cp -r "${EXTERNAL_GIT_ROOT}"/input_artifacts/python_*/* artifacts/ || true | ||
|
|
||
| apt-get install -y python-pip | ||
| python -m pip install -U pip==19.3.1 |
There was a problem hiding this comment.
note that pinning the pip version was needed only when running under python2 (since pip has removed python2 support). the manylinux2014 image has a new enough version of pip (and wheel) that we can use.
FTR #25277
| python -m pip install -U wheel | ||
| export PYTHON=${PYTHON:-python} | ||
|
|
||
| strip_binary_wheel() { |
There was a problem hiding this comment.
@lidizheng is there a reason why the symbol stripping is being done in the "build_packages" step (and it's the only step there) and not in the "build_artifacts" step (where a few other wheel transformations are already being performed). Should we move "strip_binary_wheel" to the build_artifacts step for consistency?
There was a problem hiding this comment.
Well, I would in favor of that. The stripping step in done in "build_packages", because the name of this step.
There was a problem hiding this comment.
Sg, I will look into moving the stripping into the artifact build once I have some time (or free to do that yourself).
I checked the results and there seems to be an unrelated issue with the artifact build on windows (https://source.cloud.google.com/results/invocations/1e3c02cd-719c-46cd-9329-f6678810bc5f) but both the package build tasks and the distribtests are passing, so it should be safe to merge this. |
|
Known failures: The C# failure is b/158826903 and unrelated to this PR. |
grpc_artifact_centos6 is now used for most of the artifact building and the "build_packages" script actually doesn't do much.