GitHub Action Reference

GitHub Action reference

- uses: actions/checkout@v7
- uses: derblub/django-upgrade-report@v1
  id: django
  with:
    fail-on: blocked

Every input and output of the action, as action.yml describes them. Continuous integration shows them in whole workflows.

Inputs

Input	Default	What it does
path	.	Project directory with a lockfile, requirements*.txt or pyproject.toml. Several, one per line, make one report with an overview; with recursive, the directories to look for projects in.
recursive	false	'true' finds the projects under path (a monorepo, a folder of services) and makes one report with an overview.
target	auto	Django version to upgrade to: 'auto' (the newest LTS above your Django, or the newest release when no LTS is above it), 'lts', 'latest' or e.g. '5.2'.
framework	django	What to plan the upgrade of: 'django', or 'wagtail' or 'django-cms', whose packages are then checked against target and from of that framework.
via		'lts' plans the way to the target in steps, one report per LTS on the way; 'each' one per feature version. Empty: one report. The counts are summed over the steps. Does not go with baseline.
from		The Django version you run today, e.g. '4.2', when your requirements only give a range. Empty reads it from the project.
fail-on		Fail the step when a package is 'blocked', needs an 'upgrade' or a 'check'. Empty never fails.
comment	false	'true' puts the report on the pull request as one comment, updated on every push; 'on-change' updates it only when a status or step changed. Needs permissions: pull-requests: write. Default 'false'.
issue	false	'true' keeps one open issue per target with the plan as a task list: ticks stay, what needs nothing any more is ticked off. Needs permissions: issues: write. Default 'false'.
comment-key		Tells comments apart when the action runs more than once for one path in a pull request, e.g. in a matrix. Default: the path.
baseline		Path to an earlier JSON report (the report output of a previous run). The summary then starts with what changed since. A missing file is skipped, so the first run works too.
fail-on-change		With baseline: fail the step when 'any'thing changed, or when something is 'worse'. Empty never fails.
python-target	auto	Also check every dependency on this Python: 'auto' (when the target Django needs a newer one than your project uses), 'none' or e.g. '3.12'.
fail-on-python		Fail the step when a dependency is 'blocked', needs an 'upgrade' or a 'check' on that Python. Empty never fails.
evidence	false	'true' looks for signs of support for packages to check in their public GitHub repositories (the test matrix on the default branch). Sends those repository names to GitHub.
check-private-on-pypi	false	'true' looks up packages your project installs from another index on PyPI, too: for an index that mirrors PyPI (Artifactory, Nexus, devpi). Their names are sent to PyPI.

Outputs

Output	What it holds
report	Path to the JSON report. Unique per use of the action, so two uses in one job keep both.
blocked	Number of blocked packages.
upgrade	Number of packages to upgrade.
check	Number of packages to check manually.
ready	Number of ready packages.
changes	Number of changes since the baseline, empty without one.
python-blocked	Number of dependencies no release of which runs on the newer Python, 0 when there is none to check.

The action brings its own Python, runs on Linux and Windows runners, caches answers from PyPI between runs, and writes the Markdown report to the job summary. The summary and the outputs are written before fail-on fails the step.