You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@devlake.apache.org by "DoDiODev (via GitHub)" <gi...@apache.org> on 2026/09/01 11:36:15 UTC
[PR] build(ci): add Dependabot configuration for all package ecosystems [devlake]
DoDiODev opened a new pull request, #9089:
URL: https://github.com/apache/devlake/pull/9089
## Summary
Adds `.github/dependabot.yml` so that dependency updates arrive as reviewable
pull requests instead of periodic manual audits.
This is a configuration-only change. No source file, build step or runtime
behaviour is touched, and rolling it back means deleting one file.
The configuration covers six ecosystem entries across 14 directories:
| Ecosystem | Directories | Manifests found |
|---|---|---|
| `gomod` | `/backend` | `go.mod` |
| `npm` | `/config-ui` | `package.json` + `yarn.lock` |
| `npm` | `/e2e` | `package.json` (no lockfile) |
| `pip` | `/backend/python`, `/backend/python/pydevlake`, `/backend/python/plugins/azuredevops`, `/backend/python/test/fakeplugin`, `/grafana/scripts` | 2 × `requirements.txt`, 3 × `pyproject.toml` + `poetry.lock` |
| `docker` | `/backend`, `/config-ui`, `/grafana`, `/devops/docker/lake-builder`, `/.devcontainer` | 6 Dockerfiles |
| `github-actions` | `/` | 14 workflows + `.github/actions/auto-cherry-pick` |
## Design decisions
**Weekly schedule, five open pull requests per ecosystem.** Enough to keep the
tree moving without flooding review capacity.
**Minor and patch updates are grouped, majors stay separate.** A grouped pull
request keeps low-risk churn to a single review; a major change deserves its own
discussion. This mirrors how the recent manual dependency batches were split.
**`commit-message.prefix: build(deps)`.** `.github/workflows/commit-msg.yml`
rejects any commit that does not match its conventional-commit pattern. The
prefix was verified against that exact regular expression, including the grouped
form (`build(deps): bump the … group across 5 directories with 3 updates`) and
the development-dependency form (`build(deps-dev): …`).
**Language base images are pinned deliberately, so they are ignored.** In Docker
tag semantics `python:3.11 → python:3.14` and `golang:1.26 → golang:1.27` are
*minor* updates. They are not dependency bumps, though: the Python tag has to
match what the Poetry lockfiles resolve against, and the Go tag has to match the
`go` directive in `backend/go.mod` and the toolchain used by CI. Both are
therefore ignored for minor as well as major updates and remain a conscious,
manual decision. `node` is ignored for majors only, because the build image
tracks the active LTS line and Node 26 is not an LTS release.
**`versioning-strategy: increase` for `/e2e`.** That directory declares
`"@playwright/test": "^1.58.2"` and has no lockfile. With the default strategy
Dependabot only rewrites a manifest once a release leaves the declared range, so
the entry would have produced nothing while still looking configured.
**`git2go` is never bumped automatically.** It is ABI-coupled to the libgit2
version installed in the builder image; a mismatch fails at link time.
## Action pinning
Most workflows reference actions by tag. The `docker/*` actions are pinned to a
commit SHA with a `# vX.Y.Z` comment, for example:
```yaml
uses: docker/build-push-action@bcafcacb16a39f128d818304e6c9c0c18556b85f # v7.1.0
```
Dependabot updates such a pin to the new commit SHA and rewrites the version
comment, so the pinning style is preserved rather than replaced by a tag.
Dependabot never proposes changing the *namespace* of an action. Moving to a
differently owned action stays a manual step, which matters here because ASF
infrastructure maintains an allow-list of permitted actions.
Files that are not valid workflows are not read at all — this includes
`.github/workflows/codespell.yml.action-blocked-by-asf` and
`go-checklist.yml.bak`. The blocked Codespell action is therefore left alone.
## Deferred upgrades
Every `ignore` entry carries a comment explaining why it exists, so it can be
removed once the reason no longer applies:
| Entry | Reason |
|---|---|
| `typescript` (major) | TypeScript 7 is the native-port compiler; adopting it means validating the whole build chain at once |
| `node` (major) | Node 26 is not an LTS release |
| `github.com/swaggo/swag` (major) | swag v2 is still a release candidate and requires regenerating every swagger annotation |
| `github.com/libgit2/git2go/*` | ABI-coupled to libgit2 |
| `go` | the toolchain directive moves together with CI and the base images |
| `python`, `golang`, `mcr.microsoft.com/devcontainers/go` (major + minor) | runtime decisions, see above |
## Not covered
Stating this explicitly, because a configuration file can otherwise suggest more
coverage than it provides:
- **`docker-compose*.yml`** — the `docker` ecosystem reads Dockerfiles only, so
the `mysql` and `postgres` service images stay on manual maintenance.
- **`devops/deployment/k8s/k8s-deploy.yaml` and the Helm chart** — images pinned
in plain YAML are not a supported manifest format.
- **`backend/scripts/install-mockery.sh`** — a tool version inside a shell
script.
- **`apache/skywalking-eyes@main`** — a branch reference rather than a version.
- **Unpinned entries in `backend/python/requirements.txt`** — without a version
constraint there is nothing to raise.
## Validation
- YAML parses cleanly.
- Validated against the SchemaStore `dependabot-2.0.json` schema (Draft 7) with
no violations, which also confirms the plural `directories` key and every
`update-types` value used.
- All 14 configured directories exist and contain the expected manifest.
- The commit message convention was checked against the regular expression in
`.github/workflows/commit-msg.yml` for six representative bot commit forms.
### Verified on a fork before opening this PR
This configuration was run against a fork with version updates enabled. On
2026-09-01 it produced **17 pull requests** across five ecosystems, which
confirms the behaviour that matters here:
- **Grouping works.** `js-minor-patch` bundled 21 updates into a single PR,
`actions-minor-patch` bundled 4, and `python-minor-patch` bundled 3 across two
directories. Major bumps stayed outside the groups, as intended.
- **Action pins stay pins.** The `github-actions` group PR rewrote SHAs to new
SHAs and carried the `# vX.Y.Z` comment along, e.g.
`docker/setup-qemu-action@ce36039… # v4.0.0` became
`docker/setup-qemu-action@96fe6ef… # v4.2.0`. No pin was downgraded to a tag.
- **`versioning-strategy: increase` is required for `/e2e`.** It produced
`update @playwright/test requirement from ^1.58.2 to ^1.62.1` - a bump that
would otherwise stay silent, because the new release already satisfies the
declared caret range and that directory has no lockfile.
- **The `ignore` rules hold.** `typescript` is at 6.0.3 with 7.0.2 available and
no PR was raised. The language images (`node`, `golang`, `python`) were
likewise left alone.
- **`open-pull-requests-limit` throttles.** The `github-actions` ecosystem
stopped exactly at its limit of 5.
Two issues surfaced during that run and are already fixed in this branch:
1. `dependency-name: mcr.microsoft.com/devcontainers/go` never matched, because
Dependabot strips the registry host from the dependency name. Using
`devcontainers/go` fixes it - after the change Dependabot closed the
superfluous PR itself with *"Looks like devcontainers/go is no longer being
updated by Dependabot"*.
2. Explicit `labels` were dropped. Dependabot only creates its *default* labels
automatically; labels named in the configuration must already exist, and none
of the ones originally chosen exist in this repository. Every PR carried a
*"The following labels could not be found"* warning. Without the key,
Dependabot applies and creates its defaults, so no repository setup is
required up front. Maintainers can add their own labels later if they want
them.
### Known limitation: the `gomod` ecosystem
The sixth ecosystem, `gomod`, could not be verified. It fails for a reason that
is independent of this configuration: `backend/mocks/` is gitignored while
tracked sources such as `helpers/unithelper` import it, so `go mod tidy` cannot
resolve those packages and Dependabot aborts after every version bump.
The same failure reproduces on a plain checkout without Dependabot involved:
```
go: github.com/apache/incubator-devlake/helpers/unithelper imports
github.com/apache/incubator-devlake/mocks/core/dal: no matching versions for query "latest"
```
Generating the mocks first makes `go mod tidy` exit cleanly and leaves `go.mod`
and `go.sum` byte-identical, so the module itself is consistent.
This is tracked separately in #9088. Until it is
resolved, the `gomod` block in this file will not produce pull requests. It is
kept in place so that Go updates start working as soon as the underlying issue
is fixed - reviewers may of course prefer to drop the block until then.
## Rollback
Delete the file. Any pull requests Dependabot has already opened need to be
closed manually.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@devlake.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] build(ci): add Dependabot configuration for all package ecosystems [devlake]
Posted by "klesh (via GitHub)" <gi...@apache.org>.
klesh merged PR #9089:
URL: https://github.com/apache/devlake/pull/9089
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@devlake.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] build(ci): add Dependabot configuration for all package ecosystems [devlake]
Posted by "DoDiODev (via GitHub)" <gi...@apache.org>.
DoDiODev commented on PR #9089:
URL: https://github.com/apache/devlake/pull/9089#issuecomment-5508933883
## Open question for maintainers: automatic merging after a trial period?
This pull request deliberately does **not** enable any form of automatic
merging - every Dependabot pull request will need a human merge. Whether that
stays the case is a maintainer decision, and it is easier to make once there is
some data, so this is only a question, not a proposal to change anything here.
For context, since it is a common misconception: Dependabot itself cannot merge.
The `automerged_updates` key disappeared with Dependabot Preview in 2021 and
`.github/dependabot.yml` has no auto-merge setting at all. What people call
"Dependabot auto-merge" today is three separate pieces, none of them in this
file:
1. the repository setting **Allow auto-merge**, which for an ASF repository is
an INFRA/`.asf.yaml` matter;
2. **branch protection with required status checks** on `main` - without it,
auto-merge merges immediately and the CI signal is worthless;
3. a small workflow (~30 lines) that reads `dependabot/fetch-metadata` and calls
`gh pr merge --auto --squash` only when `update-type` is
`version-update:semver-patch` (and optionally `…-minor`).
Two details make this cheap for this repository specifically: Dependabot pull
requests are branches in the repository rather than fork pull requests, so they
do not sit in `action_required` and the checks run on their own; and a squash
merge takes the pull request title as the commit message, which already carries
the `build(deps): …` prefix that `.github/workflows/commit-msg.yml` requires.
**The questions, concretely:**
1. Is automatic merging something you want at all, or do you prefer every
dependency change to pass a human review, regardless of severity?
2. If yes - how long should the trial period be in which everything is merged by
hand? The schedule here is weekly, so an observation window of roughly
**6-8 weeks (about 6-8 update cycles)** would show how often a grouped
minor/patch pull request is green and mergeable unchanged, and how often it
actually needs work. A longer window is of course fine; the point is to
decide on evidence rather than on a feeling.
3. What scope would you be comfortable with? A staged rollout would be the
careful version: start with **patch only, `github-actions` and `docker`**,
and extend to the `npm`/`pip` minor+patch groups only if the first stage was
uneventful. Majors would never be in scope.
4. Can INFRA enable *Allow auto-merge* and the required status checks on `main`?
Without both, the workflow is pointless, so this is worth clarifying before
anyone writes it.
One optional addition that pairs well with this: Dependabot's `cooldown` key can
delay a pull request until a release is a few days old, which takes the edge off
the "compromised release published minutes ago" scenario that automatic merging
otherwise amplifies. It is not used in this configuration and could be added in
the same follow-up.
If the answer to (1) is yes, we are happy to prepare that follow-up pull request
(the workflow file plus, if wanted, the `cooldown` entries) once the trial period
has run. Nothing in the present pull request depends on the answer.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@devlake.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org