Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide a way to allow to run external tests on any container #5555

Open
judovana opened this issue Sep 5, 2024 · 0 comments · May be fixed by #5553
Open

provide a way to allow to run external tests on any container #5555

judovana opened this issue Sep 5, 2024 · 0 comments · May be fixed by #5553

Comments

@judovana
Copy link
Contributor

judovana commented Sep 5, 2024

Currently the runtime of containers supports some kind of lets say "default" image, which is temurin-jdk/jre image (so a custom jdk passed in have all deps), and that is based on ubuntu. As an option on openj9 images have several hardcoded occurences and are again based on ubuntu. In addition there is hardcoded version of openj9 on Red Hat UBI images -

image_name="docker.io/library/eclipse-temurin"
tag=""
if [[ "${package}" == "jre" ]]; then
tag="${version}-jre"
else
tag="${version}-jdk"
fi
if [[ "${vm}" == "openj9" ]]; then
if [[ "${os}" == "ubuntu" ]]; then
image_name="docker.io/ibm-semeru-runtimes"
tag=open-${tag}
elif [[ "${os}" == *"ubi"* && "${test}" != *"criu"* ]]; then
image_name="registry.access.redhat.com/$base_docker_registry_dir"
tag="latest"
else
# os is ubi, and test is criu
# temporarily all ubi based testing use internal base image
image_name="$DOCKER_REGISTRY_URL/$base_docker_registry_dir"
tag="latest"
. There are then several occurences of hardcoded ubi/ubuntu:, eg:
print_${os}_pkg ${file} "${!packages}";
(note also the !package expansion). Note, that the resulting image is jsut ARG in rsulting dockerfile. eg:

ARG IMAGE=docker.io/library/eclipse-temurin:21-jdk
ARG OS=ubuntu
ARG IMAGE_VERSION=nightly
ARG TAG=21-jdk
FROM $IMAGE

There are two ways how to run the tests:

The initial change should affect at least the second. To affect the build_all.sh on top of that, should be refactoring, which would remove all the for test in ${supported_tests} do for vm in ${supported_jvms} do for os in ${supported_os} do for package in ${supported_packages} do for build in ${supported_builds} do build_image.sh ${test} ${version} ${vm} ${os} ${package} ${build} to actually do all the looping through ${supported_jvms}, ${supported_os}, ${supported_packages}, ${supported_builds} first, to prepare set of (fully) qualified container IDs and then loop through them, via shortened for test in ${supported_tests} do build_image.sh ${test} ${image} I would probably like to addres it in different issue and different purpose as usage of build-all.sh is unclear to me.

Second part of this work is to properly adjust dependencies. Currently the test.properties have hardcoded ubuntu_packages and/or ubi_packages. This is to clumsy. A better way how to handle generic dependencies, and per os-family dependencies down to os dependencies and os:version dependencies must be done. It would be also nice to have some generic deps whcih are installed always, so unzip and curl are not repeated in each test.properties. Hoefully this is aligned also with one of the future goals, to have ability to run external tests on local machine without container.
The second part may sound separated, but is not. If it should go alone, it would need to go before all other, and without all other it would be change just for itself.

@judovana judovana linked a pull request Sep 5, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

Successfully merging a pull request may close this issue.

1 participant