Both were updating `github-actions` daily, so both proposed the same bumps.
actions/setup-python v7 arrived twice within an hour: Renovate as #5575, Dependabot
as #5576.
Renovate is the one to keep. It pins actions to digests via
`helpers:pinGitHubActionDigests`, so master carries
`actions/setup-python@5fda3b9... # v7`, while Dependabot proposes a bare `@v7` and
would undo that pinning. Renovate's bumps also merge on a branch once CI has run
them, whereas Dependabot's sit outside every automerge rule here and need a human
for each one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
Its `paths` filter listed `i18n/**` but not the workflow file, so a change to the
workflow - an action bump, say - triggered nothing. Those bumps automerge on a
branch, so they were merging with nothing having run them.
The Molecule workflow already lists itself for this reason. `update-translations.yml`
cannot do the same: it only runs on pushes to master, and it holds `contents: write`
and `pull-requests: write` to open translation PRs, so running it from a dependency
branch would be worse than not exercising it. Its bumps stay unexercised on purpose,
and a broken one shows up as a failed translations run rather than as anything users
see.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
A component bump touches that role's defaults/main.yml, which is on the Molecule
workflow's path filter, so the change-detection job runs that role's scenario.
The bump therefore only merges once the new version has actually been started on
the configuration the role renders. That is a real gate, and a stronger one than
a human reading a version number in a diff.
Patch only. A minor carries behaviour changes that no static rule can judge - the
MASH fleet tried a minor-automerge preset across 21 stateless roles and reverted
all of them, because reading a given release's notes is what decides it, and that
is a job for a human or an agent rather than a config file.
Branch push rather than a PR, as with the other automerge rules here.
The list has to stay in step with the roles that actually have a scenario, so
bin/check-molecule-automerge-list.py enforces it from prek. The direction that
matters is a role keeping automerge after losing its scenario: bumps would then
merge with nothing exercising them. It reports the harmless direction too, since
a role gaining a scenario without being listed is usually an oversight.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
Anything under molecule-shared/ - the helper container images, Postgres, and the
Python pins - is on the Molecule workflow's path filter, and a change to a shared
file makes the detect job run every scenario rather than a subset. So an update
there is already gated on the whole suite passing on its own branch, which is a
stronger check than a human reading the diff.
Branch push rather than a PR, matching how the housekeeping updates in this file
already work: nothing to review and no email on success, and a failure still
surfaces as a PR.
This is also how a new Postgres major reaches us. The bump to the pin runs every
scenario against it before it can merge, so if a component does not cope with the
new major we find out from a failed Renovate branch rather than from a user.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
molecule-shared/ and the workflow itself are used by every scenario, so a
change to either has to run all of them rather than only the roles whose own
files moved. They were also missing from the paths filter, so such a change
would not have triggered the workflow at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>