#4137 new task

Update Fedora builder image

Reported by: blaisep Owned by:
Priority: normal Milestone: Automate Release Process
Component: dev-infrastructure Version: n/a
Keywords: ci Cc:
Launchpad Bug:

Change History (11)

comment:1 Changed at 2024-12-07T02:18:36Z by btlogy

fedora-35 was actually not used by the CI workflow (only building an image for it, but not using it).

This PR could bring it back:

Once active again, we could bump it to fedora-41. But I think this will require that someone publish a new image to Docker hub (and I'm not sure who has the credential - unless CircleCI has them).

Alternatively, we could easily test on fedora-41 on GHA (if we go there).

See test in progress: https://github.com/LeastAuthority/tahoe-lafs/pull/8/checks

Last edited at 2024-12-07T02:19:47Z by btlogy (previous) (diff)

comment:2 Changed at 2024-12-07T02:19:10Z by btlogy

  • Component changed from unknown to dev-infrastructure
  • Keywords ci added
  • Owner changed from btology to btlogy

comment:3 Changed at 2024-12-09T16:49:01Z by btlogy

Rather than PR#1405 which propose to switch from oraclelinux-8 to fedora-35, I'm now in favor for PR#1406 which should drop python 3.8 while keeping oraclelinux-8.

Then we can bring back fedora-35 and bump it to fedora-41 (which will also require to publish a new image in Docker hub).

I'll try to test this new build on GHA while waiting for PR#1406 to be merged...

comment:4 Changed at 2024-12-09T18:42:30Z by btlogy

Strong of what we've learned in PR#1406, here is the steps I think we need to take:

  1. PR the addition of fedora-41 as a new image to build from a fork w/o CircleCI account (NOT LeastAuthority),
  2. Ask a GH admin (e.g.: meejah) to trigger the parametrized build (image=true)
  3. PR the revival and replacement of the unit test on fedora-35 by fedora-42 and remove the fedora-35 build image part.

NOTES:

  • Both PRs could be done at once, but will result in build failure and require a re-run, which only GH admin can do again...
  • I bet a Docker Hub admin should/could delete the fedora-35 image from the registry after that...

comment:5 Changed at 2024-12-10T11:45:44Z by btlogy

Testing on fedora-41 might be too soon, unless we start working on supporting Python 3.13:

12.34 ERROR: Package 'tahoe-lafs' requires a different Python: 3.13.0 not in '<3.13,>=3.8'
------
Dockerfile.fedora:27
--------------------
  25 |     COPY . ${BUILD_SRC_ROOT}
  26 |     
  27 | >>> RUN "${BUILD_SRC_ROOT}"/.circleci/prepare-image.sh "${WHEELHOUSE_PATH}" "${VIRTUALENV_PATH}" "${BUILD_SRC_ROOT}" "python${PYTHON_VERSION}"
  28 |     
--------------------

But fedora-40 with Python 3.12 could be a nice step over.

comment:6 Changed at 2024-12-13T11:13:05Z by btlogy

With ticket:4143 and PR#1409 (not yet merged), we've published a new fedora-40 image.

I've prepared a branch to re-activate the fedora builder (previously dropped in PR#1395) and switch to version 40 with Python 3.12.

It's building the wheel and unit testing successfully, but it's not ready yet for a PR because pending on ticket:4131 and PR#1406 (which is also pending on ticket:4143 and PR#1409).

But we are getting there...

comment:7 Changed at 2024-12-16T11:42:52Z by btlogy

  • Owner btlogy deleted

the proposed PR#1409 has been rejected in favor or a new one PR#1418 in which an image has been built for fedora-40.

The builder still need to be bumped and the legacy image removed and this should happen in ticket:4143.

I suppose this ticket could be amended to reflect the step to fedora 40 instead of 41 and then closed as soon as ticket:4143 is completed.

comment:8 Changed at 2024-12-16T11:43:21Z by btlogy

  • Summary changed from Update Fedora builder image to fc41 to Update Fedora builder image

comment:9 Changed at 2024-12-17T17:18:40Z by meejah

Again, 1409 was not "rejected"; your relevant commits from it are all in 1418 (which extends it) correctly attributed to you. I tried to make this clear from the description which says "extension of 1409".

Also, I only made 1418 after you said "feel free to tweak this PR to your liking". This is the only way I know to add commits to a PR that's on a fork.

Last edited at 2024-12-17T20:22:59Z by meejah (previous) (diff)

comment:10 Changed at 2024-12-18T07:19:27Z by btlogy

Meejah: you have decided to not merge 1409. This is what I mean by "rejected".

I would not call PR 1418 a fork of 1409 since they do not share a common history.

If some commits of 1409 are well in 1408, you've added more which are unrelated to the original ticket:4143 (usual practice it seems).

comment:11 Changed at 2024-12-18T14:02:00Z by meejah

In my view, I _did_ merge 1409 (via 1418).

They do share history. (Yes, the commit-hashes are not exactly the same as you force-pushed 1409 several times, and 1418 is a rebase).

It is not clear to me what changes you think are unrelated, maybe the chutney timeout increase?

Note: See TracTickets for help on using tickets.