Conversation
|
|
||
| `default-days: 30` serves as fallback for packages that don't follow semver (e.g., some Docker images). | ||
|
|
||
| **Security updates are exempt from cooldown** because `target-branch: develop` is a non-default branch. Per the docs: cooldown does not affect security updates when `target-branch` points to a non-default branch. |
There was a problem hiding this comment.
Target branch for Dependabot should be main, right?
| ### Other Settings | ||
|
|
||
| - `open-pull-requests-limit: 20` on all ecosystem entries | ||
| - `schedule.interval: "monthly"` — unchanged |
There was a problem hiding this comment.
I would put daily here. Once we have auto-merge, we do not need extra delay in addition to cooldown.
|
|
||
| - `open-pull-requests-limit: 20` on all ecosystem entries | ||
| - `schedule.interval: "monthly"` — unchanged | ||
| - `target-branch: "develop"` — unchanged |
There was a problem hiding this comment.
correct, leftover, main is the target always.
|
|
||
| ### Repos without dependabot.yml | ||
|
|
||
| Create a new `.github/dependabot.yml` using the appropriate template. Use `target-branch: "develop"` for service repos. For workflow-only repos (like transitdata-shared-workflows), omit `target-branch` so PRs target the default `main` branch. |
|
|
||
| ### Repos with existing dependabot.yml | ||
|
|
||
| Add grouping, cooldown, docker ecosystem, and bump PR limit to 20. Use the appropriate template (Maven, Gradle, or Python) based on the repo's primary ecosystem. |
There was a problem hiding this comment.
"Adding" in the sense of overwriting with the unified dependabot.yml, right?
| - `schedule.interval: "monthly"` — unchanged | ||
| - `target-branch: "develop"` — unchanged | ||
|
|
||
| ## Template Configurations |
There was a problem hiding this comment.
Here I would just use one template for all repos. In my understanding Dependabot does not break if it has extra, unused ecosystems listed in dependabot.yml. I think having a single dependabot.yml everywhere simplifies the centralized management discussed in the other proposal.
There was a problem hiding this comment.
ok, if that is the case, then yes, makes things simpler.
| - **Major production deps**: ungrouped → individual PRs (require changelog review) | ||
|
|
||
| For infrastructure ecosystems (github-actions + docker): | ||
| - **`infrastructure`** group (multi-ecosystem): minor + patch updates for both github-actions and docker combined into a single PR |
There was a problem hiding this comment.
This I do not understand. What is the benefit? What is the connection between these updates to warrant grouping them?
There was a problem hiding this comment.
replied in the comment below
| - **Major production deps**: ungrouped → individual PRs (require changelog review) | ||
|
|
||
| For infrastructure ecosystems (github-actions + docker): | ||
| - **`infrastructure`** group (multi-ecosystem): minor + patch updates for both github-actions and docker combined into a single PR |
There was a problem hiding this comment.
However, I suggest grouping github-actions + docker ecosystems if they both originate from HSLdevcom. Does Dependabot syntax support that? That is because there might be a connection between new shared Dockerfile and shared workflow versions. (Such Dependabot PRs we can also auto-approve and auto-merge if the CI passes but that is not at the core of this proposal.)
I'm still thinking whether that grouping only applies to MAJOR version updates or for any version updates. What do you think?
There was a problem hiding this comment.
Ok, I merged into a single one grouping HSLdevcom using patterns as ["HSLdevcom/*"] (not sure if this will suffice, but we'll see).
haphut
left a comment
haphut
left a comment
There was a problem hiding this comment.
Good job! Please answer the comments or modify accordingly.
|
Done, replied and/or adjusted for all comments. |
|
Great! One more Dependabot trick for Node LTS-only (EDIT: not needed for Node.js anymore, see next comment): updates:
- package-ecosystem: "docker"
ignore:
- dependency-name: "node"
versions: [ "25", "27", "29", "31", "33", "35", "37", "39" ]Source: dependabot/dependabot-core#2247 (comment) A similar trick can be made for JVM, and it would go something like this: updates:
- package-ecosystem: "docker"
ignore:
# Ignore non-LTS versions
- dependency-name: "eclipse-temurin/*"
# The list can be extended when closer to the end as the release schedule might change in five years.
versions: [ "26", "27", "28", "30", "31", "32", "34", "35", "36" ]That trick would enable using this (Obligatory: RenovateBot supports this use case out of the box, again.) |
|
Aha, Node.js is changing their release schedule so all major versions will be LTS. So the trick is only relevant for JVM Docker images. Source: https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule |
2 participants
No description provided.