cookiecutter-django/docs/6-about/maintainer-guide.md

Maintainer guide

This document is intended for maintainers of the template.

Automated updates

We use 2 separate services to keep our dependencies up-to-date:

• Dependabot, which manages updates of Python deps of the template, GitHub actions, npm packages and Docker images.
• PyUp, which manages the Python deps for the generated project.

We don't use Dependabot for the generated project deps because our requirements files are templated, and Dependabot fails to parse them. PyUp is -AFAIK- the only service out there that supports having Jinja tags in the requirements file.

Updates for the template should be labelled as project infrastructure while the ones about the generated project should be labelled as update. This is use to work in conjunction with our changelog script (see later).

Automation scripts

We have a few workflows which have been automated over time. They usually run using GitHub actions and might need a few small manual actions to work nicely. Some have a few limitations which we should document here.

CI

ci.yml

The CI workflow tries to cover 2 main aspects of the template:

• Check all combinations to make sure that valid files are generated with no major linting issues. Issues which are fixed by an auto-formatter after generation aren't considered major, and only aim for best effort. This is under the test job.
• Run more in-depth tests on a few combinations, by installing dependencies, running type checker and the test suite of the generated project. We try to cover docker (docker job) and non-docker (bare job) setups.

We also run the deployment checks, but we don't do much more beyond that for testing the production setup.

Django issue checker

django-issue-checker.yml

This workflow runs daily, on schedule, and checks if there is a new major version of Django (not in the pure SemVer sense) released that we are not running, and list our dependencies compatibility.

For example, at time of writing, we use Django 4.2, but the latest version of Django is 5.0, so the workflow created a "Django 5.0" issue in GitHub, with a compatibility table and keeps it up to date every day.

Limitations

Here are a few current and past limitations of the script

• When a new dependency is added to the template, the script fails to update an existing issue
• Not sure what happens when a deps is removed
• Unable to parse classifiers without minor version
• Creates an issue even if we are on the latest version

Issue manager

issue-manager.yml

A workflow that uses Sebastian Ramirez' issue-manager to help us automate issue management. The tag line from the repo explains it well:

Automatically close issues or Pull Requests that have a label, after a custom delay, if no one replies back.

It runs on a schedule as well as when some actions are taken on issues and pull requests.

We wait 10 days before closing issues, and we have a few customised reasons, which are configured in the workflow itself. The config should be fairly self-explanatory.

Pre-commit auto-update

pre-commit-autoupdate.yml

Run daily, to do pre-commit autoupdate on the template as well as the generated project, and opens a pull request with the changes.

Limitations

• The PR is open as GitHub action which means that CI does NOT run. The documentation for create-pull-request action explains why.
• Some hooks are also installed as local dependencies (via requirements/local.txt), but these are updated separately via PyUP.

Update changelog

update-changelog.yml

Run daily at 2AM to update our changelog and create a GitHub release. This runs a custom script which:

• List all pull requests merged the day before
• The release name is calendar based, so YYYY.MM.DD
• For each PR:
  • Get the PR title to summarize the change
  • Look at the PR labels to classify it in a section of the release notes:
    • anything labelled project infrastructure is excluded
    • label update goes in section "Updated"
    • label bug goes in section "Fixed"
    • label docs goes in section "Documentation"
    • Default to section "Changed"

With that in mind, when merging changes, it's a good idea to set the labels and rename the PR title to give a good summary of the change, in the context of the changelog.

Limitations

• Dependabot updates for npm & Docker have a verbose title, try to rename them to be more readable: Bump webpack-dev-server from 4.15.1 to 5.0.2 in /{{cookiecutter.project_slug}} -> Bump webpack-dev-server to 5.0.2
• Dependencies updates for the template repo (tox, cookiecutter, etc...) don't need to appear in changelog, and need to be labelled as project infrastructure manually. By default, they come from PyUp labelled as update.

Update contributors

update-contributors.yml

Runs on each push to master branch. List the 5 most recently merged pull requests and extract their author. If any of the authors is a new one, updates the .github/contributors.json, regenerate the CONTRIBUTORS.md from it, and push back the changes to master.

Limitations

• If you merge a pull request from a new contributor, and merge another one right after, the push to master will fail as the remote will be out of date.
• If you merge more than 5 pull requests in a row like this, the new contributor might fail to be added.