automated release fails due to missing PyPI history anchor

[codyoss]

Description

The release automation script (cli.py) fails with a ValueError when trying to update a library's CHANGELOG.md if the file doesn't use the exact hardcoded PyPI history anchor. This blocks releases for any package that has a malformed or missing header.

Affected Code

In .generator/cli.py (lines 1533-1540):

anchor_pattern = re.compile(
    rf"(\[1\]: https://pypi\.org/project/{library_id}/#history)",
    re.MULTILINE,
)
...
if num_subs == 0:
    raise ValueError("Changelog anchor '[1]: ...#history' not found.")

Root Cause

The regular expression is too strict:

1. It expects [1]: literally. If a package uses [2]: or similar, it fails.
2. It expects the PyPI project name to match the folder name {library_id} exactly.
3. It has strict spacing requirements.

Proposed Solution

Make _process_changelog more robust by:

• Falling back to a less strict regex (e.g., searching for any link containing pypi.org/project/ and #history).
• If no anchor is found, auto-prepend it to the file instead of raising a fatal error.

Culprit Found

During investigation, packages/google-cloud-documentai-toolbox/CHANGELOG.md was found to be missing this anchor, which was blocking its release. I will create a PR to add this shortly.

[kdm-lh]

Hi @codyoss, thank you for working on this! You're mentioning that this issue is blocking the release of google-cloud-documentai-toolbox. I wonder if this is also blocking the release of google-resumable-media. The latest version on PyPI is 2.8.0 while the changelog contains two newer releases 2.8.1 and 2.8.2. The link in the changelog seems to align with the history link already (https://pypi.org/project/google-resumable-media/#history), so could it potentially be due to a different issue? It looks like the google-resumable-media was just recently integrated into the monorepo. (As a sidenote, the Homepage link on PyPI is still pointing to the archived repo (https://github.com/googleapis/google-resumable-media-python).
The unavailability of releases >2.8.0 is currently blocking us from upgrading urllib3 to 2.6.3 which fixed a high vulnerability.

[parthea]

Thanks for reporting this @kdm-lh! We'll follow up on the missing releases in #16472.