- The workflows assumes that there exists a repository variable
SUPPORTED_PYTHON_VERSIONSwith value["3.10", "3.11", "3.12", "3.13"]andLATEST_PYTHON_VERSIONwith value3.13or similar that lists the supported Python versions of the package. Note: need to use double quotes for the array and no quotes for a single version. - These are configured as organizational variables so do not need to be set explicitly. However, they can be overriden by setting them in the repository or environment scope.
- Permissions are set restrictive for the entire organization. This means that specific permissions need to be configured for every workflow.
- Only define permissions in
workflow.ymlif it is really necessary. E.g.,contents: readis the default and not needed. Defining this would make it cumbersome to change defaults. Nonetheless, we add acontents: readblock to the top of each workflow to keep CodeQL happy and doubly enforce least priviledge.
- We configure CI such that all secrets and access tokens are defined in environments. This allows for granular control of access. Additionally, every GitHub workflow that requires access to an environment secret should require additional approval by select accounts (not teams).
Environments are hardcoded. Currently, there are
anaconda(only master-branch, requires approval, secret token)gh-pages(only gh-pages)pypi(only master-branch, requires approval)testpypi
- PyPI and TestPyPI deployments use trusted publishing. This means that we do not need a secret or token in GitHub. Instead, we configure a specific GitHub environment as trusted source on the PyPI side. If we select this environment in the GitHub workflow, short-lived access tokens will be generated on demand automatically.
- Anaconda uses an access token. The token needs to be generated on the Anaconda website or CLI (scope: "Allow all operations on Conda repositories"). It is not added as an organizational secret but as an environment secret to each repository. This token has en expiration date and needs to be renewed yearly.