ci: Added CI check for Towncrier change log fragments

[BugFriendlyGarden]

Added CI check for Towncrier change log fragments

Description

New check looks at the PRs commit history and requires at least one newfragments/.x file for all PRs. This is how we'll track and update changes to changelog.rst for releases.

Changes

• ci: Added News Fragments Added check
• ci: Removed redundant checklist options from default PR description
• docs: Fixed some typos
• build: Adjusted pyproject.toml's configuration for towncrier pre-commit checks

Checklist

Please check the following items as they're completed.
Completion of all checklist items signals to maintainers that a PR is fully ready for review.

• This PR conforms to the process detailed in the Contributing Guide
• I have included no proprietary/sensitive information in my code
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have tested my code
• Removing "Draft" status from the PR (if applicable).

[GhostofGoes]

please squash commits

[BugFriendlyGarden]

Moved back to draft since the new test needs to be limited to only run on PR pushes, not any push.

[CySpiegel]

There are a few issues I think we should check first.

The overall idea makes sense, and it is good that the new check includes its own fragment. However, there are two issues that need to be fixed before this can merge:

• The new job fails on every non-PR run of the workflow.
• The two new Towncrier settings in pyproject.toml are not recognized and have no effect.

The new job breaks push and workflow_call runs

.github/workflows/tests.yml:42

tests.yml runs for push, pull_request, and workflow_call, but the new job is not limited to pull-request events.

On a non-PR run, ${{ github.event.pull_request.number }} is empty. That turns the check into:

ls newsfragments/.*

I tested this under Bash 5.2, which is what the Ubuntu 24.04 runners use. With the default globskipdots behavior, the glob matches nothing and ls exits non-zero.

That means every push will fail this job, including pushes to main after a merge. The release workflow also calls tests.yml, so this would cause the Core Tests step in releases to fail as well.

The job needs an event guard:

if: github.event_name == 'pull_request'

The new Towncrier settings are not valid

pyproject.toml:783-788

Neither extension nor [tool.towncrier.categories] is recognized by Towncrier 25.8.0, which is the version pinned in .pre-commit-config.yaml.

I verified this against Towncrier’s Config dataclass:

uv run --with towncrier==25.8.0 python -c \
"import dataclasses; from towncrier._settings.load import Config; \
names=[f.name for f in dataclasses.fields(Config)]; \
print(sorted(names)); \
print('extension:', 'extension' in names, '| categories:', 'categories' in names)"

Output:

['all_bullets', 'create_add_extension', 'create_eof_newline', 'directory',
 'filename', 'ignore', 'issue_format', 'issue_pattern', 'name',
 'orphan_prefix', 'package', 'package_dir', 'sections', 'single_file',
 'start_string', 'template', 'title_format', 'types', 'underlines',
 'version', 'wrap']
extension: False | categories: False

Towncrier silently ignores both settings. Running towncrier build --draft on this branch still produces the default headings, including “Features,” “Bugfixes,” and “Misc,” rather than the headings defined in the new block.

Fragment types need to be configured using supported Towncrier syntax, such as:

[tool.towncrier.fragment.<type>]

or:

[[tool.towncrier.type]]

The five types listed in this PR are already Towncrier’s defaults, and the default misc type already suppresses fragment content. Unless the custom headings are intentional, the categories block can simply be removed.

If extension = "" was intended to stop towncrier create from adding .rst, the supported option is:

create_add_extension = false

The checkout action does not match the repository’s pinning policy

.github/workflows/tests.yml:39

The new job uses:

actions/checkout@v6

The other 13 checkout steps in the repository use the same SHA-pinned v7 release:

actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7

Since the repository consistently pins actions by commit SHA and uses StepSecurity’s harden-runner, the new job should use the existing pinned checkout version as well.

[CySpiegel]

extension = "" is not a valid Towncrier setting

pyproject.toml:783

Towncrier 25.8.0 does not recognize an extension setting, so this line has no effect.

If the goal is to prevent towncrier create from appending .rst, the supported option is:

create_add_extension = false

Otherwise, this line should be removed.

The PR does not fix the existing changelog build

The towncrier build --yes step disabled in commit c5c51b7 remains commented out in release.yml, and the underlying failures are still present.

Towncrier is not declared in any PDM dependency group. pyproject.toml contains the [tool.towncrier] configuration, and pdm.lock contains a Towncrier entry, but nothing in the dependency graph actually depends on it.

As a result, this command does not install Towncrier on a clean checkout:

pdm install -d

That means both of these fail:

pdm run towncrier check

towncrier build --yes

The first affects the pre-commit hook, while the second affects the release workflow.

There is also a separate version-detection issue. Running towncrier build without an explicit --version fails with:

No module named 'PEAT'

This happens because package = "PEAT" does not point to an importable Python package. I reproduced the same behavior on both main and this PR branch.

The PR description says the configuration was adjusted for the Towncrier pre-commit checks, but both new configuration keys are ignored. The actual fixes still needed are:

• Add Towncrier to the PDM development dependencies, for example with pdm add -dG dev towncrier.
• Install Towncrier in the release job.
• Fix the package/version detection configuration or pass the version explicitly during the build.

The contributor links point to the wrong file

.github/pull_request_template.md:25
.github/workflows/tests.yml:51

Both references direct contributors to .github/CONTRIBUTING.md and mention the “Update the CHANGELOG” section.

That file does not mention Towncrier, news fragments, or the changelog. The relevant instructions are in the root-level CONTRIBUTING.rst, starting around line 67.

Both references should point to CONTRIBUTING.rst instead.

The contributor documentation contradicts the new check

CONTRIBUTING.rst:82-86

The documentation currently says fragments should use this format:

<PR_NUMBER>.<TYPE>.rst

It also says an issue number may be used instead of the PR number.

Neither instruction matches the new CI check:

• A fragment named after an issue number will fail because the job only searches for the pull-request number.
• The documented .rst suffix conflicts with the CI examples, such as 80.feature.
• It also conflicts with existing repository fragments, such as 72.bugfix.

The documentation should be updated in this PR so that it matches the naming convention the CI job actually enforces.

The documentation job name is misleading

.github/workflows/tests.yml:27

The new job uses documentation as its key, so it will appear as something like:

Core Tests / documentation

That sounds like a documentation-build job, especially since the repository already has actual documentation jobs. This check only validates the presence of a changelog fragment.

A clearer name would be:

newsfragment:
  name: Changelog Fragment Check

It would be better to rename this before the current job name is added to any branch-protection rules.

The harden-runner version does not match the other jobs

.github/workflows/tests.yml:31

The new job pins harden-runner to v2.17.0, while the other two jobs in the same workflow use the v2.20.0 commit beginning with bf7454d0.

The new job should use the same pinned version as the rest of the file.

[GhostofGoes]

Holy Moly @CySpiegel your agent needs a KISS skill.

could summarize as: "The job fails on non-PR workflow runs, and the towncrier settings added are incorrect. Go fix. Also, here are a few suggestions for improvements, each suggestion is one sentence"

I'm really tired of reviewing PRs and MRs the last few week with Descriptions filled with AI vomit. Don't need all of the context, don't need fancy words, ELI5.

[GhostofGoes]

Don't forget to squash.
Also could always add a PDM run script like 'pdm run changelog'