- Python 100%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
Michał Szczepanik
05a5028058
This upgrades the dependencies in pyproject.toml together with the uv lockfile. The major reason was the release of datalad-core 0.3, which means it no longer has to be installed from the source repo. Other updates are done just as a formality. There is a significant change in that datalad-next removed its git-annex dependency (made it optional), so uv no longer includes git-annex in the environment for this project. I think this is a positive change: now, testing will happen with the git-annex version available in the "external" environment (the same happens with Git anyway). We can change it back by declaring an explicit dependency of this project (perhaps also optional). This would make for an easier installation in a CI environment. Later, we may also think of having a way of swapping several git-annex versions on the "client" side when running tests. But for now, as the tests are started manually, I think I prefer an update to my "global" git-annex to influence the tests. The build-system upper bound is moved following the release of uv 0.12, in a way suggested in release notes (this change is not strictly necessary). |
||
| src/forgejo_integration_testing | ||
| tests | ||
| .gitignore | ||
| .python-version | ||
| pyproject.toml | ||
| pytest.toml | ||
| README.org | ||
| uv.lock | ||
Forgejo integration testing
This repository contains a small selection of tests for validating interactions of git-annex with a Forgejo-aneksajo instance.
Example usage
Using uv run pytest from the project root is recommended to
automatically manage dependencies. The following command will run all
tests against the given forgejo instance, creating repositories under
the "scratch" organization (which must exist beforehand):
export FORGEJO_TOKEN=<...>
uv run pytest --instance-url https://hub.example.invalid --org scratch --gpg-keyid B2682F34Not all parameters are mandatory, see below.
Parametrization
CLI
The following parameters can be provided to pytest:
--instance-url(required): base URL of the forgejo instance that the tests will run against--org: name of the organization for creating test repositories; if not provided, all repositories will be created under the user account the token belongs to--gpg-keyid: GPG key ID for use with tests that use encrypted special remotes (used with initremote); these tests will be skipped if not provided
Environment variables
The following environment variables will be read on setup:
FORGEJO_TOKEN: access token to use for forgejo API calls (e.g. creating repositories); needs read:misc, write:organization, write:repository, and write:user permissions
Environment and interactions
Forgejo API calls will be done using the instance URL and credentials provided.
Git & git-annex operations will be done in the same environment as the pytest process, ie. with the configuration and credential helpers defined by the user. Caching or unlocked store of git credentials will eliminate the need for interaction.
GPG operations (done by git-annex) will be done in the same
environment as the pytest process, ie. with the user's key
store. These tests are enabled by providing the --gpg-keyid option
and skipped otherwise. A dedicated throwaway key with no password
would work best.
Repository organization
Tests are in tests, helpers are in src to make them importable as
a named package (although they are likely not very useful on their
own).
Caveats
Repository cleanup is not yet implemented, so test repositories are (currently) not removed after the test session.