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

[#502] experimental test harness using a single container #508

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

d-w-moore
Copy link
Collaborator

Automatic launch of specific test scripts in their own container.

@d-w-moore d-w-moore marked this pull request as draft January 30, 2024 16:11
Comment on lines 18 to 19
RUN /root/ubuntu_irods_installer/install.sh --w="add-package-repo" 0
RUN /root/ubuntu_irods_installer/install.sh --i=${irods_vsn} -r 4
Copy link
Collaborator Author

@d-w-moore d-w-moore Jan 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these need to be brought local. and, they'll be replaced eventually , probably by the minimal irods install commands.

Copy link
Contributor

@korydraughn korydraughn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please explain what this PR does?

Are there plans to leverage the consortium test hook and the testing environment?

@@ -0,0 +1,24 @@
ARG linux_vsn="ubuntu:18.04"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

18.04 is EOL.

Please bump to 20.04 or 22.04.

@@ -0,0 +1 @@
../../../..
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this used for?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To figure out relative paths when generating the execute line for the docker container

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This no longer exists. The purpose is now fulfilled by print_repo_root_location, a script which prints the absolute path of the repo regardless the current working directory when it's launched. That absolute result is useful within docker_container_driver.sh especially when calculating the paths of things relative to that root.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me know if this seems an adequate explanation, and I'll resolve. But, of course, I will understand if the truth of the matter is otherwise. It was confusing to write, probably more confusing to read. The end purpose is calculating container-internal paths using those container-external paths as input, which was less trivial than I'd first imagined.

RUN apt update
RUN apt install -y sudo git
WORKDIR /root
RUN git clone http://github.com/d-w-moore/ubuntu_irods_installer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this temporary?
What does this offer?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of this could be considered temporary. We really just need a stand_it_up equivalent tbh

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're now doing the "install and stand up" thing for the iRODS server running within each container, and with no dependencies on the ubuntu_irods_installer repo.

@d-w-moore
Copy link
Collaborator Author

d-w-moore commented Jan 30, 2024

Please explain what this PR does?

Are there plans to leverage the consortium test hook and the testing environment?

[....] I wanted to get a start on this issue and get comments in but do not believe this will be merged for the next prc release.

Seems this PR is part of the 2.0.0 milestone after all, so maybe we try to leverage those somewhere in a later release?

@d-w-moore d-w-moore force-pushed the 502.m branch 2 times, most recently from fedbf73 to 858374b Compare March 7, 2024 11:05
@d-w-moore
Copy link
Collaborator Author

Rebasing atop 518.m , and I may leave it that way to save time. After un-drafting, we'll decide if #518 gets its own pull request

@d-w-moore d-w-moore force-pushed the 502.m branch 3 times, most recently from 8109fec to 00e9cc2 Compare March 14, 2024 12:21
@trel
Copy link
Member

trel commented Mar 14, 2024

let's not mention 281 in the first part of the commit lines, we can reference it in the body if helpful/needed.

@d-w-moore
Copy link
Collaborator Author

let's not mention 281 in the first part of the commit lines, we can reference it in the body if helpful/needed.

Yes, will correct that.

@d-w-moore d-w-moore force-pushed the 502.m branch 2 times, most recently from 2d19eac to bc07343 Compare March 24, 2024 08:36
@d-w-moore d-w-moore force-pushed the 502.m branch 2 times, most recently from 65a4bee to a9c2d75 Compare April 5, 2024 09:04
@d-w-moore d-w-moore changed the title [_502] experimental test harness using containers [#502] experimental test harness using containers May 14, 2024
@d-w-moore
Copy link
Collaborator Author

Please explain what this PR does?

Are there plans to leverage the consortium test hook and the testing environment?

Basically there are a bunch of tests which demand unique setup or otherwise unique running conditions. This PR is part of a plan to run each of those - automatically is the hope. Inclusion is the idea, preventing regression. And it's easy to set up conditions for such tests within a Dockerfile.

@d-w-moore d-w-moore changed the title [#502] experimental test harness using containers [#502] experimental test harness using a single container Jun 14, 2024
setupssl chgs -q

[_502] fixes/enhancements to test harness (inclusive misc__ commits)

misc__ pre:

make irods install simpler, independent of other repos

run the test script using exec

(The docker run command initiates an iRODS startup process via CMD).

now able to define the irods version to be installed.

fix relative paths; sample BATS test

setupssl changes

pam and ssl setup funcs

build target version of Python (will parameterize version later)

refactor of test containers

experiment.sh -- call setupssl.py in container

tighter checking in driver/test-runner

corrections

enable ageing out pam pw (postgresql only)

misc__:

add/refine options - workdir etc

options

include dummy_script called from experiment.sh

move to test-script-parameters

more utility funcs

directory name change

misc__ post:

update json files for test

restore

correction to update json funcs

chmod +x login_auth_test.py

failing/script-to-script call demo

implement wrapping

virtual env

provide path to original script; allow args (testnames)

delete script not used

include overlooked ssl-and-pam Dockerfile

wrap/args demo

get rid of troublesome recursive symlink

abspath for orig script; -t better for early docker versions

username is now param for setting up pam with iinit

setup conditions properly for tests

adjustments to keys.

arglist is now affected by symlink basename of argument if any.

changes to login_auth test

changes for login_auth_test nr 2

allow different irods versions

include symlink

change to test script params only

separate container run for env-modifying test

test001 working

include the other symlink

In testing don't depend on strong primes for DH param generation.

362-test-harness

setupssl-q-nr2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants