Adding Debian 12 golden images, and fixing ArchLinux

[ScriptAutomate]

There are two paths to getting nox on Debian 12:

• Install it via pip3 but with --break-system-packages, since operating systems are moving toward avoiding installing any Python packages at the system level (due to the risk of breaking OS functionality).

OR:

• Install nox via apt install python3-nox nox -y (or pkg.install with a more complicated state jinja logic), but not be using the targeted, expected version of nox referenced in nox.sls to be used (python3-nox is currently 2022.11.21)

Using --break-system-packages seems to be the exact same experience currently used by all other AMIs.

From a long-term perspective, we should evaluate whether we will want to run nox from one of the following:

• System level Python env, which means requiring --break-system-packages as more OS targets require it (currently how this is implemented on systems, and what this current draft PR is implementing with passing tests)
• Provide nox via a different, isolated virtualenv/venv (created by the system-level Python version)
• Provide nox via a different, isolated pyenv virtualenv (under a standardized Python version)

[dmurphy18]

I feel the python3-nox would be more appropriate, had to do it on Debian 11 arm64, since it didn't particularly like the python3 -m pip install nox

And that is more in line with the OS packages

Changed my mind on this after talking with @ScriptAutomate last Friday, better to have the same version of nox used over all of the different OS's.

[ScriptAutomate]

I feel the python3-nox would be more appropriate, had to do it on Debian 11 arm64, since it didn't particularly like the python3 -m pip install nox

And that is more in line with the OS packages

The only version of nox available via apt on Debian 12 (for python3-nox) is 2022.11.21, which means that the version of nox we'd be using would differ between built golden images.

@s0undt3ch Can you confirm which path is best?

[s0undt3ch]

The only issue I see with using the system packages nox is if the version is too low for the features we need.

Right now, I'm not sure of the system version is recent enough.

An alternative is to install the system python pipx and install nox this way. This could be implemented for all OS'es(probably only excluding windows)

[ScriptAutomate]

Moving Forward

Had a conversation about this. Going the following direction:

• Going with nox and --break-system-packages for this PR (as it is inline with current functionality of AMIs that are built for the test suite)
• In a follow-up PR, going to evaluate implementing pipx installations, and using pipx to install and manage versions of nox. This will require some extra work, because we'd need to ensure pipx is available on each target OS as part of updating the nox.sls
  • pipx would assist in avoiding installing nox into the system-level Python, and will run nox in an isolated virtual environment
  • pipx docs

Arch Linux is failing

Arch Linux fails to find osfinger grain?

2023-06-23T20:52:59.3467868Z            �[1;31m==> amazon-ebs.image:     {%- if grains['osfinger'] == 'Debian-12' %}    <======================�[0m
2023-06-23T20:52:59.3468561Z            �[1;31m==> amazon-ebs.image:     - name: "{{ pip }} install 'nox=={{ nox_version }}' --break-system-packages"�[0m
2023-06-23T20:52:59.3469238Z            �[1;31m==> amazon-ebs.image:     {%- else %}�[0m
2023-06-23T20:52:59.3469961Z            �[1;31m==> amazon-ebs.image:     - name: "{{ pip }} install 'nox=={{ nox_version }}'"�[0m
2023-06-23T20:52:59.3471522Z            �[1;31m==> amazon-ebs.image:     {%- endif %}�[0m
2023-06-23T20:52:59.3472558Z            �[1;31m==> amazon-ebs.image:   {%- else %}�[0m
2023-06-23T20:52:59.3473697Z            �[1;31m==> amazon-ebs.image: [...]�[0m
2023-06-23T20:52:59.3474338Z            �[1;31m==> amazon-ebs.image: ---�[0m
2023-06-23T20:52:59.3475579Z            �[1;31m==> amazon-ebs.image: [CRITICAL][salt.state                                                         :4280] Rendering SLS 'base:python-pkgs.nox' failed: Jinja variable 'dict object' has no attribute 'osfinger'; line 48

When testing locally, I can retrieve it properly.

# When testing on a container, osfinger works as expected
salt-call --local grains.get osfinger

# Output
local:
    Arch Linux-20230611

Requires more troubleshooting.

Misc failures (unrelated)

Other test failures are unrelated to this PR:

• Windows: Chocolatey specific installs are failing for:
  • rust
  • jq
  • rsync
• OpenSUSE failing installs of:
  • python-xml
  • npm
  • bower (via npm.installed)

Will ignore for this PR.

[ScriptAutomate]

Looks like we were running into an ArchLinux bug:

• Arch Linux has no osfinger salt#54344

...Arch has no osfinger grain...

Needed to modify the sls jinja logic to avoid targeting osfinger in conditional check. Since ArchLinux now requires --break-system-packages to work, also, it has been added within scope of this change.

PR is moved out of draft state. If CI/CD passes properly, this will be good to merge in.

[ScriptAutomate]

Tickets opened for follow-ups in broken CI/CD that are unrelated to Debian 12 changes:

• Issue detailing Windows problem: Windows: Chocolatey not being recognized in PATH #1812
• PR resolving SUSE issues: Fix SUSE Leap 15 builds: node v18 and python3-xml fixes #1813