+ "content": "riscv64 Runners . We make use of the official RISE RISC-V Runners for any jobs which should run on a riscv64 platform, particularly build and test jobs. The python-wheels repository is already configured to access them. The runs-on directives in any new workflows should be changed like so: . jobs: build: runs-on: ubuntu-24.04-riscv . Target Python Versions . Previously RISE has used a Python version matrix covering the four latest releases (major.minor, e.g. 3.14), plus any freethreaded variants available (e.g. 3.14t). As of July 14th, 2026, this includes Pythons 3.11, 3.12, 3.13, and 3.14 (along with 3.14t, the freethreaded equivalent). However, the NumPy project (as of version 2.5.0) supports Python 3.12 as the minimum. Since this package is fundamental to many others which we are supporting, we will follow its precedent when defining our version matrix. Some wheels have previously been built for 3.13t, but since this was an experimental version with limited support we avoid it now. With these factors, our default version matrix becomes: . ['3.12', '3.13', '3.14', '3.14t'] . Exceptions may be necessary for some packages, which should be carefully considered to balance achieving similarity to upstream with feasibility of maintenance. uv . The official actions/setup-python Action does not yet support riscv64 builds, so workflows using it will fall back to using the host version (if one is present matching the major.minor numbering used by the workflow, e.g. 3.12). A simple alternative is to replace any usage of actions/setup-python in the upstream workflow with astral-sh/setup-uv like so: . - uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0 name: Install Python with: python-version: '3.12' activate-environment: true enable-cache: false . Note the python-version ‘activate-environment’, and ‘enable-cache’ options. The first two allow us to select the environment Python and have it pre-enabled (matching actions/setup-python behaviour for our purposes). The enable-cache option is disabled for now, as it has caused failures in previous build attempts. Upstream Project Checkouts . We use the actions/checkout action to checkout the upstream repository at the desired tag: . - name: Checkout numpy v$ uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 with: repository: numpy/numpy ref: v$ submodules: true persist-credentials: false . This effectively overwrites the default project layout for the workflow, which would otherwise be a copy of python-wheels. It allows our workflows to operate as if they are part of the upstream project without having to include them in a fork. More importantly, it is critical for uncomplicated usage of tools like cibuildwheel, which assumes that the root directory is the project to be built when invoked. Using the python-wheels Repository in Workflows . The python-wheels repository contains some custom Actions we require, and patch files to apply for certain projects. The one every build-<package>.yml workflow needs is publish-wheels, which performs the following steps: . | Downloads the built wheel(s) from the previous job | Uploads them to the GitLab PyPI registry (via the lower-level publish-to-gitlab Action) | Opens a PR against docs/packages/<name>.yaml documenting the new version (via ci_scripts/update_doc.py), which docs/packages/generate_packages_doc.py later renders into the published Markdown page. With it in place, the build-numpy.yml script’s publish job looks like this: | . publish: name: Publish numpy $ to GitLab needs: build_wheels # Only publish when the workflow was triggered from main with a specific # version. Manual trigger is the only entry point, so checking the ref is # enough to gate uploads. if: github.ref == 'refs/heads/main' runs-on: ubuntu-latest permissions: contents: write pull-requests: write steps: - name: Publish wheels and open docs PR uses: riseproject-dev/python-wheels/actions/publish-wheels@main with: artifact-pattern: numpy-$-*-manylinux_riscv64 gitlab-username: $ gitlab-token: $ gitlab-project-id: $ gh-token: $ . permissions needs contents: write and pull-requests: write here (not just contents: read) since the docs step pushes a branch and opens a PR with the default GITHUB_TOKEN. Other workflows need to follow the same process, modifying artifact-pattern to match their own artifact naming scheme and otherwise reusing publish-wheels like the example. The publish-to-gitlab Action should only be used directly if a workflow needs the upload step without the docs PR side effect. ",
0 commit comments