Setting up tox on ubuntu-24.04 runners fails

[jnsgruk]

Github recently released their ubuntu-24.04 series runners. Using those results in an error because actions-operator tries to install tox globally with pip, rather than in a virtual environment.

See example failure here: https://github.com/canonical/parca-k8s-operator/actions/runs/10922157328/job/30315898232

Run charmed-kubernetes/actions-operator@main
Install core snap
Install LXD
Initialize LXD
Install tox
  /usr/bin/which tox
  /usr/bin/which pip
  /usr/bin/pip
  pip is available, install tox
  /usr/bin/pip install tox
  error: externally-managed-environment
  
  × This environment is externally managed
  ╰─> To install Python packages system-wide, try apt install
      python3-xyz, where xyz is the package you are trying to
      install.
      
      If you wish to install a non-Debian-packaged Python package,
      create a virtual environment using python3 -m venv path/to/venv.
      Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
      sure you have python3-full installed.
      
      If you wish to install a non-Debian packaged Python application,
      it may be easiest to use pipx install xyz, which will manage a
      virtual environment for you. Make sure you have pipx installed.
      
      See /usr/share/doc/python3.[12](https://github.com/canonical/parca-k8s-operator/actions/runs/10918199388/job/30304336943#step:3:13)/README.venv for more information.
  
  note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
  hint: See PEP 668 for the detailed specification.

[jnsgruk]

@addyess are you still a maintainer on this?

[addyess]

@jnsgruk aye...

i believe the actions-operator supports this by first using the setup-python action:

See #81

if you'll add a setup-python before actions-operator, then tox will install into that environment instead of the system-wide one

[jnsgruk]

For anyone reading, I solved this in zinc-k8s like so:

• jnsgruk/zinc-k8s-operator@e6f9a45
• jnsgruk/zinc-k8s-operator@e2efc4f

[addyess]

@jnsgruk precisely. That's how it's expected to look

[jnsgruk]

Hmm, seems the action is now stalled on setting up MicroK8s, though: https://github.com/jnsgruk/zinc-k8s-operator/actions/runs/10999695504/job/30540473863

[addyess]

@jnsgruk looking at sg -- maybe it now requires a password?

Mon, 23 Sep 2024 17:55:06 GMT   /usr/bin/bash -c sudo usermod -a -G snap_microk8s $USER
Mon, 23 Sep 2024 17:55:06 GMT   /usr/bin/sg snap_microk8s -c microk8s status --wait-ready --timeout=600
Mon, 23 Sep 2024 23:53:39 GMT   Password: 
Mon, 23 Sep 2024 23:53:39 GMT   Error: The operation was canceled.

This might take some time to sort out

[addyess]

I recreated your issue in the CI for this project:
https://github.com/charmed-kubernetes/actions-operator/actions/runs/11006467708/job/30560799999?pr=83

the same issue with sg occurs both for microk8s and lxd... in either case the github runner session can't seem to get past an interactive prompt from from sg requesting the password be entered

[jnsgruk]

This seems to be an upstream issue, which is closed but not solved.

Looks like one of our colleagues solved this by replacing instances of sg GROUP with sudo -u $USER -E

[addyess]

Alright, that's applied but has ripples into pytest-operator

charmed-kubernetes/pytest-operator#139

[addyess]

@jnsgruk thanks for highlighting this need. #83 closes this issue