Simple CI recipes for .github/workflows?

Python Help
1

Does anybody have a slightly less crazy version of .github/workflows/ for just one build of one version on one Linux platform for a brief CI checking than what’s in python/cpython proper? I don’t need all platforms and all versions, just one version of Python (actually the ancient 3.6) on one Linux distro (openSUSE/Leap).

I have tried to simplify the directory from GitHub - openSUSE-Python/cpython at opensuse_3.6-gh-action and so far I have failed spectacularly, because it is just a way too complicated I assume.

2

This isn’t in GH YAML or in a Dockerfile, and you’ll have to find the URL or branch for Python 3.6. If you have more cores, you can bump the -j2 higher too. But all that is required to build from source on Debian, in CI or in anything else, is:

apt-get update -y
apt-get install build-essential gdb lcov libbz2-dev libffi-dev \
         libgdbm-dev liblzma-dev libncurses5-dev libreadline6-dev \
         libsqlite3-dev libssl-dev lzma lzma-dev tk-dev uuid-dev xvfb git
git clone --depth=1 --branch=3.12 https://github.com/python/cpython
cd cpython
./configure
make -j2
./python -m ensurepip

I’ve tested these on Debian Trixie, but initially copied the script commands from here: Setup and building.

If they need too much work to get them to run for the Ubuntu runners, you could use a Docker-containerised Github Action.

3

Hmm, I have created my attempt for GitHub Actions, but apparently there is some weird setting on python/cpython, which disallows … something … I don’t even understand that weird message in the top of the pull request:

CPython Mirror

GitHub - python/cpython: The Python programming language is a cpython mirror repository. Pull requests are not accepted on this repo and will be automatically closed. Submit patches at https://bugs.python.org

For additional information about contributing to CPython, see the developer’s guide.

What? I don’t want to submit this to python/cpython, and that PR is not based on upstream branches at all.

On the top of that, Workflow runs · openSUSE-Python/cpython · GitHub still shows unchanged upstream actions. Any idea how to make GitHub to see my attempt?

4

Github’s trying to run it. Look at the actions page, and examine the error:

No event triggers defined in `on`

You need to add something like:

on:
  workflow_dispatch:

and fire the jobs off manually for testing (or add whichever automatic triggers are needed - on push and on PR or merge are good ones).

5

I don’t understand: when looking at line 3 of my build.yml I see:

on:
  push:
    branches:
        - 'opensuse_3.6'
  pull_request:
    branches:
        - 'opensuse_3.6'

What I am missing?

6

Make sure the workflow (.yml) file is on the main branch. Then push a commit to the opensuse_3.6 branch, and see if it runs.

Sometimes GHA requires workflow files to exist in the main branch, before it acknowledges their existence. It could all get very complicated and circular otherwise (e.g.if workflows in all branches can run, creating other branches, which could contain other workflows).

7

Well:

a) No, it shouldn’t be on the main branch, because that’s the faithful mirror of the main branch of python/cpython
b) Something happened, but then the action failed without any reasonable explanation Build and Test · openSUSE-Python/cpython@8e0aeed · GitHub
c) actionlint playground was happy with my workflow file

8

Workflows only need to be on main to use workflow_dispatch, sorry.

Anyway, I’ve built it twice now: Workflow runs · JamesParrott/BuildCPythonInOpenSuse · GitHub
Running all 491 tests will take a while longer, and I wouldn’t be surprised if one of them fails.
The tests pass. Turns out that -j3 option is important.

9

I missed this small note on the bottom of the page (it is clearly not very clear):

actions/checkout@v4 is not allowed to be used in openSUSE-Python/cpython. Actions in this workflow must be: within a repository owned by openSUSE-Python.

So, I got rid of it, and it seems that at least the test runs now. Let’s see how it finishes!

10

I am really slow, when looking at your workflow file, I see:

run: git clone --depth=1 --branch=3.12 http://www.github.com/python/cpython

I don’t understand. If this is done on push or pull_request event, I surely don’t care about branch 3.12, but I want the code being pushed or PRed in, don’t I?

run: ./python -m test -j3

I think the right replacement for -j is -j0, which should run on as many processors as available.

11

If you’re not developing CPython itself, if you just want to build it from source, there’s no need to work from a fork of it. The CPython repo can just be cloned fast enough into any workflow, of any other project’s repo.

Set the branch and the url to that of the git repo, of whichever Python you want to build. I just happen to know 3.12 builds, and have never tried 3.6.

12

I am a developer, even not primarily the upstream one (although, I am trying to help as well). I work for SUSE and that branch is our current Python 3.6 code for our SLE packages.

And I think, I have finally beat it to the submission: Convert main branch GitHub Action for OpenSUSE 3.6 builds. · openSUSE-Python/cpython@bb831e4 · GitHub ; unfortunately, only to find I have some problems with version of OpenSSL in Leap (I think).