Remove stuck CI checks with Python 3.6

[Martchus]

The checks with Python 3.6 seem to get stuck at a very early stage with no output at all. Canceling/restarting didn't help when I tried it on 2025-08-12 and 2025-08-13.

Considering Python 3.6 is EOL anyway it makes not much sense to invest more effort here. So I'm simply removing these checks.

[AdamWill]

Please don't do this yet. I'm on vacation but will look at this later. Python 3.6 is EOL upstream but is maintained and supported in RHEL 8, that's why I tend to keep support for it in my projects until it's impossible. I want to at least have a shot at keeping it working.

[Martchus]

I now had to convert this back to a draft anyway as now all Python jobs get stuck. So this problem is likely not related to Python 3.6 after all. Maybe we exceeded some quota on our GitHub action usage or there's some general problem with these GitHub actions.

[perlpunk]

I cancelled the job from yesterday, but still the jobs from today are not starting...

[okurz]

The checks with Python 3.6 seem to get stuck at a very early stage with no output at all. Canceling/restarting didn't help when I tried it on 2025-08-12 and 2025-08-13.

Considering Python 3.6 is EOL anyway it makes not much sense to invest more effort here. So I'm simply removing these checks.

Same as what AdamWill said. Also Python 3.6 is not EOL for openSUSE/SLE. Only upstream maintenance support has ended. Meaning that maybe "ubuntu" is not a viable base for that anymore

[Martchus]

Also Python 3.6 is not EOL for openSUSE/SLE.

I don't think this is relevant for two reasons:

• Versions of openSUSE/SLE that stick to old versions of Python can just as well stick to old versions of this library.
• openSUSE, e.g. Leap 15.6 (but probably also recent SPs of SLE 15) also provide much newer versions of Python in addition to still supporting 3.6. So this client could still be used there with these newer versions.

[d3flex]

restore this and the CI will work. I tested here #68. I used 3.11 because I think this is the latest in Ubuntu, but you just need one. I will close my PR now

[Martchus]

Thanks, I'll try tomorrow.

[Martchus]

Let's see whether just bumping this version works - but probably not and we'll still have to remove Python 3.6.

[okurz]

Now this change looks weird. Why try to use "ubuntu-latest" for all versions including 3.6 but use the old 20.04 for 3.11? Maybe you wanted to remove 3.6 completely in line 14 but as Adam and me suggested to keep it have you tried to use a different base than 20.04 for 3.6?

[AdamWill]

Sorry, I meant to have a look at this when I got back from PTO but still didn't get the roundtuits yet :/

I just looked into it briefly, and the core issue seems to be "github took the ubuntu-20.04 image away". There's no other OS image you can use on github-hosted runners that would have Python 3.6 in it. Somebody asked setup-python to deal with this and they declined: actions/setup-python#1048 . So right now I suspect there's nothing practical we can do to keep testing on 3.6 and we should just drop it as initially proposed, unfortunately.

I can ask internally at RH if we're interested in helping with this somehow, since we're the primary reason anyone cares about Python 3.6 any more...

[okurz]

So right now I suspect there's nothing practical we can do to keep testing on 3.6 and we should just drop it as initially proposed, unfortunately.

We could run an openSUSE image like openSUSE Leap 15.6 that has python3.6

[AdamWill]

But then I think we'd also need to provide (i.e. maintain) a runner, right? You can't run arbitrary images on GitHub-hosted runners. I was trying to avoid getting there (if we're going to do that, we could equally do it with RHEL or CentOS 8).

Someone in the RH discussion I started said the following, which looks interesting, but I haven't looked into it in detail yet, including who's maintaining these containers and where they come from:

For the few places where I still care about Python 3.6, I run them in a "python:3.6" container, skipping actions/setup-python completely.

You get something like this:

jobs:
  build:
    runs-on: ubuntu-24.04
    container: ${{ matrix.container }}
    strategy:
      fail-fast: false
      matrix:
        python:
          - "3.9"
          - "3.9"
          - "3.10"
          - "3.11"
          - "3.12"
          - "3.13"
        include:
          - python: "3.6"
            container: "python:3.6"
          - python: "3.7"
            container: "python:3.7"
    steps:
      - uses: actions/checkout@v5
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python }}
        if: matrix.container == null
      - name: do things
        run: whatever

An actual working example can be found in [1].

[1] https://github.com/theforeman/foreman-ansible-modules/blob/develop/.github/workflows/main.yml

[AdamWill]

ah, OK, so I get it now: the container: thing is just an interface to docker hub. So you can start with an ubuntu runner and deploy whatever container you like on it. with that, there are various ways to get Python 3.6 (deploy a Fedora container and install it, deploy a CentOS 8-ish container, deploy one of these python containers that are maintained by...somebody, deploy a Leap 15.6 container if those exist?)

So we can probably work with one of those, I'll have a play with it.