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.

Sign up for GitHub

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

Add runtime instructions #680

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add runtime instructions #680

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 43 additions & 3 deletions README.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,12 +28,31 @@ How can I contribute?
What do I need to contribute?
-----------------------------

* A host with python 3.6+, gcc and the python development header files
dcermak marked this conversation as resolved.
Show resolved Hide resolved
* tox
* go
* A host with `python` 3.6+ and `tox`
* docker and/or podman+buildah
* vagrant (optional, can be used to test FIPS mode and registered hosts)

Test setup on openSUSE
^^^^^^^^^^^^^^^^^^^^^^

It is recommended to run BCI tests in its own virtual environment by doing the following:

.. code-block:: shell-session

$ sudo zypper in python3-virtualenv
$ virtualenv .bci_tester
$ source .bci_tester/bin/activate

Once the virtual environment `.bci_tester` has been setup, you only need to run `source .bci_tester/bin/activate` again to activate it.
Comment on lines +38 to +46
Copy link
Collaborator

Choose a reason for hiding this comment

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

Tbh, I think this whole section is obsolete. I haven't activated a virtualenv in bci-tests since we introduced the venv toxenv.

Copy link
Member

Choose a reason for hiding this comment

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

True, tox should run its own virtual env AFAIK

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But tox itself would be on the system itself, and currently the way to go is via pip, no?

Copy link
Collaborator

Choose a reason for hiding this comment

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

It shouldn't matter where you get tox from

Copy link
Contributor Author

@grisu48 grisu48 Jan 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

This virtualenv is for tox itself and therefore I consider it still relevant.

Especially on older SLES versions pip is the only way how to get this running and there it might be a good idea to contain it in it's own virtualenv.

Or am I wrong?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I have never installed pip into a virtualenv, I'd go with pipx or use pip install --user.

Copy link
Member

Choose a reason for hiding this comment

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

Not sure if there's anything older than py3.6 on SLE15, and in theory the tests work on that, I have no issues on Leap, but I often use venv if I want a new python version and to not install any packages on my system/user.

Most python users should be aware of poetry, venv, pipx, and so on, and might not want to use one option over another. Perhaps it is ok to ignore this step as it could be a user preference.


To setup the test environment on openSUSE Leap 15.6 and Tumbleweed, run the following commands:

.. code-block:: shell-session

$ sudo zypper -n in podman buildah docker git-core python3 python3-pip
Copy link
Member

Choose a reason for hiding this comment

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

so is this supposed to be run inside the venv or outside? if it's inside the venv, you don't need to install python3-pip anymore, it is provided by the venv.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True only if running in a venv. I phrased the previous block as optional so in cases where people run this outside a venv (for whatever reasons) it would still be needed.

$ pip3 --quiet install --upgrade pip
Copy link
Member

Choose a reason for hiding this comment

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

why not simply install python3-pip (or python311-pip) instead? seems simpler than this process imho.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But python3-pip is installed just in the line before. This is there to update pip, which we do, but I'm not sure if that's really needed.

Copy link
Member

@dirkmueller dirkmueller Dec 5, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

It's not needed. but you should be installing python311 instead which is 3.11 rather than 3.6.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This also needs to work on older versions, so this is the most generic version that will work at least on Leap and Tumbleweed.

If we advance to specifying python311 it will not work on Leap and require us to update the documentation every time there is a Leap release or Tumbleweed updates the major python version in use.

For the sake of making the document age better, I would stay with the generic version.

$ pip3 --quiet install tox --ignore-installed six
Comment on lines +53 to +54
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe add a --user flag here?

Suggested change
$ pip3 --quiet install --upgrade pip
$ pip3 --quiet install tox --ignore-installed six
$ pip3 --quiet install --user --upgrade pip
$ pip3 --quiet install --user tox --ignore-installed six

Copy link
Member

Choose a reason for hiding this comment

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

I think we should advertise installation of packages, or if that is unwanted for some reason, advertise the use of venvs instead of pip install globally (or as user which is also not possible on tumbleweed)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I do like to advertise the use of venvs more than using the --user flag, so I added instructions to use a virtualenv.

By using the --user flag we need to explain that this will only work outside of virtualenvs and it's also not what we are using in our test flow in openQA, so I think that's not what we should document.

Copy link
Member

Choose a reason for hiding this comment

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

actually I'd prefer if we wouldn't use the pip method in openQA either from a supply chain security perspective..

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Let's make this a meeting point on Tuesday, that requires more more engineering work especially on older versions (12-SP5) but if we want to do this, it should be possible.

For now I suggest we decouple this initiative from this PR, because that's not easy to solve and not worth waiting for IMHO.


How can I run the tests?
------------------------

Expand All @@ -43,6 +62,27 @@ How can I run the tests?
will reduce the danger of race conditions when building containers)
4. Run ``tox -e $language_stack -- -n auto``

Environment variables
^^^^^^^^^^^^^^^^^^^^^

You can set the following environment variables to configure the behavior of the BCI-Tests:

.. code-block:: shell-session

$ export OS_VERSION=15.6 # Target SLES version
Copy link
Member

Choose a reason for hiding this comment

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

It would be nice to document all defaults in case nothing is set.

$ export CONTAINER_RUNTIME=podman # Defaults to podman
$ export TARGET=ibs-cr # Set container to be tested, see below

Available `TARGET` settings are the following:

ibs SUSE:SLE-15-SP*:Update:BCI
ibs-cr Pending ToTest containers
ibs-released Release BCI container
obs devel:BCI:* on OBS
factory-totest Factory
factory-arm-totest Factory for ARM/aarch64
manual Test the container defined by CONTAINER_URL

Technical contributions
-----------------------

Expand Down
Loading