Migrate Gitlab CI repo to here

[corona10]

Migrate https://gitlab.com/python-devs/ci-images to this repo.

Action Items

• Port https://gitlab.com/python-devs/ci-images under cpython-ci directory
• Write GA script (manual trigger with cool UI) to release CPython CI image
• Publish CI images to https://github.com/orgs/python/packages and Gitlab

[corona10]

cc @brettcannon @JacobCoffee @hugovk

[corona10]

@JacobCoffee cc @warsaw
At the first stage, let's just port files and CI to verify itself.
As the next level, I hope to publish Github Action only.
And as the final level, we can publish it to Gitlab too.

[warsaw]

@corona10 can I ask about more detail on this bullet item?

Write GA script (manual trigger with cool UI) to release CPython CI image

One of the nice things about the GL actions is that they are almost completely hands-off. There's a cron action that triggers every evening, downloads the latest tarballs, builds and publishes them. So it always gets the latest releases, even if the README.md file is a little out of date. That happens because it's still a manual process to update README.md when the RM announces a new Python release, although we've made some attempts at automating even that.

Right now, before 3.14a0 is released, it also builds from the git HEAD but I'll disable that once there's a tarball on python.org (since they would collide on a make altinstall).

Do also take a look at some of the open tickets on the GL project. There's some additional improvements we've thought about but never gotten around to.

All in all, I'm glad to see this effort move forward!

[warsaw]

Publish CI images to https://github.com/orgs/python/packages and Gitlab

For backward compatibility, we will still need to publish images to the GitLab registry. There are downstream projects that use those images for their own CI so we don't want to break them.

[corona10]

One of the nice things about the GL actions is that they are almost completely hands-off. There's a cron action that triggers every evening, downloads the latest tarballs, builds and publishes them.

I think we can do the same thing. :) I thought it was a handy job, but it looks like it's not!
https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule

[warsaw]

I thought it was a handy job, but it looks like it's not!

Sorry, I don't quite understand the comment. Do you mean the comment from the docs "In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days."?

I should also mention that we did have some cases where we ran out of minutes for the runner jobs, which is the main reason I disabled building inactive Python versions. It used to build two "channels", with the second channel publishing an image that even had EOL'd Pythons. But when we were in a runner-minutes crunch, disabling that channel got us back under quota and nobody seemed to complain so 🤷 .

Since then, we got a lot more minutes using GitLab's OSS plan, which is great except that you have to actively renew it every year. It's a little bit of a PITA; they're process used to be quite slow and onerous but I literally just renewed it and it wasn't too bad. That said, I never felt the need to re-enable that second channel. Once EOL'd always EOL'd! 😄

[corona10]

Sorry, I don't quite understand the comment.

Ah I just wanted to talk about the cron job that should be triggered every night is able to be ported as the GitHub Action as scheduled tasks.

Further more detail, I should take a look at more detail through this weekend. :)

[corona10]

To avoid a 60-day inactivity restriction, there might be a workaround for it.
(e.g: https://github.com/gautamkrishnar/keepalive-workflow)
But I should take a look at it in more detail, and maybe I should share some overall workflow architecture before we start working on this task.

[warsaw]

The 60-day inactivity restriction may never be reached in practice, given the frequency of pre-releases, bug and security fixes across all active versions. At the very least the README.md will need to update, whether that's done manually (as I currently do it) or automatically (as would be ideal).

FWIW, whenever an RM announces a new release (in a public channel), I typically just edit the README.md file in the GitLab web IDE and then commit it to main. I almost never create a branch since the images will always track the very latest releases anyway, and the README.md is just updating the docs and a couple of links. It only takes 2 minutes so even then it's probably a lot less time than trying to automate the process 🤣

However, when a new major release comes out, I do typically create a branch and test it out, because that often also comes with an EOL for an old version. For the 3.13.0 release / 3.8 EOL I also got rid of the multiple channels, and re-enabled the build-from-git-head for 3.14. I'll revert that (in a branch) once 3.14.0a0 is released.

In each of these cases where I do interact with the repo, I always watch the version output from the test job, just to make sure those jive with the announced release versions.

[hugovk]

Dependabot will help spam keep the repo active, please see PR #20.