Repository navigation
ci(dependabot): removed the paths filter of the auto-merge caller - #21
Merged
Merged
Conversation
The caller only started for changes to the Dockerfile, so pip (pyproject.toml) and docker-compose (docker-compose.e2e.yml) PRs never reached docker-maintenance-dependabot.yml: no job, no annotation, the PR just stayed open. Without the filter every Dependabot PR gets an explicit decision from the module. Why this is safe: * required-workflows stays docker-release.yml. Its pull_request paths already cover Dockerfile, pyproject.toml and docker-compose*.yml, and its PR run genuinely exercises each of them: pytest installs from pyproject.toml, the image build runs the pytest gate, and the e2e round trips start the server images of docker-compose.e2e.yml. * GitHub Actions updates and any change under .github/ stay manual by the module's own guard. * Merge settings, permissions and merge-update-types (patch) are unchanged. The header no longer claims the merge triggers docker-release.yml: the merge is made with GITHUB_TOKEN, which starts no push workflow.
actions-maintenance.yml called the same docker-maintenance-dependabot module, filtered on .github/workflows/**, for GitHub Actions updates only. The module never merges those (a CI change cannot be vouched for by its own CI), so this caller only ever wrote the "left open" annotation. docker-maintenance.yml now starts for every Dependabot PR, GitHub Actions updates included, and writes that same annotation. Keeping both would start the module twice on every GitHub Actions PR. Its job-level concurrency group (docker-maintenance-dependabot-pr-<number>, cancel in progress) is shared repository-wide, so one of the two runs would be cancelled and leave a cancelled check on the PR. Nothing that worked is lost: GitHub Actions PRs still get exactly one explicit decision and stay a manual merge.
Contributor
|
🎉 This PR is included in version 1.10.2 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
docker-maintenance.ymlonly started for changes toDockerfile. Dependabot also updates pip (pyproject.toml) and docker-compose (docker-compose.e2e.yml) here, and those PRs never reacheddocker-maintenance-dependabot.yml: no job, no annotation, the PR just stayed open without any decision (row 1 of the module's decision table). Owner decision: the module reacts to every Dependabot ecosystem.What
docker-maintenance.yml: removed thepaths:filter from thepull_requesttrigger (types unchanged: opened, synchronize, reopened, ready_for_review). Updated the header so it describes the real scope, and dropped the claim that the merge triggersdocker-release.yml: the merge is made withGITHUB_TOKEN, which starts no push workflow.actions-maintenance.yml: removed. It called the same module for GitHub Actions updates only, and the module never merges those. With (1),docker-maintenance.ymlcovers them too and writes the same "left open" annotation. Keeping both would start the module twice on every GitHub Actions PR. The module's job-level concurrency group (docker-maintenance-dependabot-pr-<n>,cancel-in-progress: true) applies across the whole repository, so one of the two runs would be cancelled and leave a cancelled check on the PR.required-workflows(docker-release.yml),merge-method,auto-approve,merge-update-types(defaultpatch), permissions andsecrets: inheritare unchanged.docker-release.ymlis not touched: itspull_requestpaths already cover every file Dependabot changes here.Per ecosystem
Dockerfile(python:3.14-alpine)docker-release.ymlbuilds the image from it, pytest gate included, and the e2e round trips run with itchore(docker): no releasepyproject.tomldocker-release.ymlstarts onpyproject.toml. Its pytest job runspip install -e ".[test]", the image build installs from it and runs pytest, and the round trips run that imagechore(deps): no releasedocker-compose.e2e.yml(postgres, mariadb, mysql, mailpit)docker-release.ymlstarts ondocker-compose*.yml. The e2e round trips start the server images ofdocker-compose.e2e.yml(thecomposeleg uses its database images, the alerts suite uses mailpit). Compose images with${VAR:-default}cannot be updated by Dependabotchore(deps): no release.github/workflows/**chore(ci): no releasedependabot.yml, and the repository has no such manifestsWith
merge-update-types: patch, minor and major updates stay open for review with a notice. Most of the tags here are not plainX.Y.Z(3.14-alpine,18-alpine,13,26.7,v1), so in practice most image updates will be left open on purpose.chore(...)prefixes and theGITHUB_TOKENmerge cut no release. The dailycheck-base-images.ymlstill handles base-image digest drift.Compatibility
dependabot[bot]only), as before.checks/statuses/actions: read) are not needed and were not added.Test
This PR changes only
.github/, sodocker-release.ymldoes not start on it. Its CI shows that the workflow files are valid and that the caller now starts without a paths filter (its job is skipped, because this is not a Dependabot PR). The end-to-end proof comes with the next Dependabot pip or docker-compose PR: it will now get a "Docker Maintenance" run with an annotation.