Circle uses java-library-oss template #596
Conversation
|
I don't think this image has |
schlosna
force-pushed
the
ds/circle
branch
4 times, most recently
from
c7064d9 to
9225634
Compare
.circleci/config.yml
Outdated
| sudo ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /usr/lib/ssl/libcrypto.so | ||
| sudo ln -s /usr/lib/x86_64-linux-gnu/libssl.so.1.1 /usr/lib/ssl/libssl.so | ||
| sudo ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /usr/lib/libcrypto.so | ||
| sudo ln -s /usr/lib/x86_64-linux-gnu/libssl.so.1.1 /usr/lib/libssl.so |
There was a problem hiding this comment.
Should this move to the unit-test: section?
|
I'm mainly interested in unblocking the excavators and ensuring things can build on recent JDK 11+ and gradle tooling while I had some cycles. Looks like it may be easier to hold off on this until #588 merges
Yeah, these are currently using @ellisjoe 's |
schlosna
force-pushed
the
ds/circle
branch
2 times, most recently
from
8abf624 to
88bcdfb
Compare
There was a problem hiding this comment.
@carterkozak builds are green now, but would you prefer I hold off on this until after #592 & #588 merge?
| - run: | ||
| name: link_openssl | ||
| command: | | ||
| sudo apt-get update -q && sudo apt-get install -qy libssl-dev | ||
| sudo ln -s /lib/x86_64-linux-gnu/libcrypt.so /usr/lib/libcrypto.so | ||
| sudo ln -s /lib/x86_64-linux-gnu/libcrypt.so /usr/lib64/libcrypto.so | ||
| echo "Linked openssl /usr/lib/libcrypto.so" | ||
| ls -al /lib/libcrypto* /usr/lib/libcrypto* /usr/lib64/libcrypto* /usr/lib/x86_64-linux-gnu/libcrypto* |
There was a problem hiding this comment.
This is the section we'll need to figure out how we want to fold into circle template so that it doesn't immediately get removed by excavator though unit tests should block that from merging, but that also means the excavator won't be updating everything else including CI images.
For future reference, see https://issues.apache.org/jira/browse/HADOOP-12845 & https://issues.apache.org/jira/browse/HADOOP-11216
Resulting libcrypto symlinks (we need /usr/lib64/libcrypto.so)
lrwxrwxrwx 1 root root 33 Jan 6 20:36 /lib/libcrypto.so -> /lib/x86_64-linux-gnu/libcrypt.so
lrwxrwxrwx 1 root root 33 Jan 6 20:36 /usr/lib64/libcrypto.so -> /lib/x86_64-linux-gnu/libcrypt.so
lrwxrwxrwx 1 root root 33 Jan 6 20:36 /usr/lib/libcrypto.so -> /lib/x86_64-linux-gnu/libcrypt.so
-rw-r--r-- 1 root root 5541876 Nov 24 13:20 /usr/lib/x86_64-linux-gnu/libcrypto.a
lrwxrwxrwx 1 root root 16 Nov 24 13:20 /usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.1.1
-rw-r--r-- 1 root root 2954080 Nov 24 13:20 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
| markdown: | ||
| docker: [{ image: 'raviqqe/liche:0.1.1' }] |
There was a problem hiding this comment.
I thought we'd opted out of this check by default in our templates due to the issues with links to other github projects?
|
@schlosna Ordering doesn't make any difference to me, doesn't impact the other PRs that are up and gives us more modern testing. Was there a reason we tested on ibm jdks? Is that something we need to retain? |
| - checkout | ||
| - restore_cache: { key: 'gradle-wrapper-{{ checksum "gradle/wrapper/gradle-wrapper.properties" }}' } | ||
| - restore_cache: { key: 'gradle-cache-{{ checksum "versions.props" }}-{{ checksum "build.gradle" }}' } | ||
| - run: ./gradlew --no-daemon --parallel --continue crypto-core:test |
There was a problem hiding this comment.
@carterkozak Some consumers of hadoop-crypto may use J9 for JVM runtime so this was running the tests using IBM's J9 JVM via https://github.com/ellisjoe/ibm-java-openssl/blob/develop/Dockerfile
Defer to you & @ellisjoe if you'd want to keep these J9 CI tests
|
Before we merge this, we'll need to adjust the Github expected checks:
|
|
closing as this was updated via #619 . will rerun excavator |
Before this PR
Circle CI config was unmanaged, blocking many excavators using JDK 11+ gradle plugins
After this PR
==COMMIT_MSG==
Circle uses java-library-oss template
==COMMIT_MSG==
Possible downsides?