build-trust / ockam

Orchestrate end-to-end encryption, cryptographic identities, mutual authentication, and authorization policies between distributed applications – at massive scale.
https://ockam.io
Apache License 2.0
4.48k stars 560 forks source link

Configure Dependabot to group Elixir pull requests #5325

Open mrinalwadhwa opened 1 year ago

mrinalwadhwa commented 1 year ago

Why: https://github.com/build-trust/ockam/pull/5324

How: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/customizing-dependency-updates#grouping-dependabot-version-updates-into-one-pull-request

Where: https://github.com/build-trust/ockam/blob/develop/.github/dependabot.yml#L38-L113


We love helping new contributors! ❤️ If you have questions or need help as you explore, please join us on Discord. If you're looking for other issues to contribute to, please checkout our good first issues.

shanesveller commented 1 year ago

This Dependabot feature will be beneficial for things like ecto/ecto_sql or earmark and its child packages, which should upgrade together, but I think we also sometimes want conceptual grouping along a different axis.

We currently have a set of Elixir packages we develop like so:

.
├── ockam
├── ockam_abac
├── ockam_cloud_node
├── ockam_healthcheck
├── ockam_kafka
├── ockam_metrics
├── ockam_services
├── ockam_typed_cbor
└── ockam_vault_software

Some of them have interdependencies to a sibling, and some of them depend on the same third-party Elixir libraries as one another. Due to how Mix's dependency resolution algorithm behaves, it requires a single exact version of any given package from the perspective of your mix.lock. This is in contrast to Cargo where we can safely have multiple distinct majors (or pre-1.x minors) while still being able to compile the project and often running correctly. In our Elixir tree, the full set of our projects must have mutually coherent definitions of any dependencies that overlap. So for example, all of ours depend on credo, dialyxir, ex_doc, and many of them depend on jason. If two of them were to define incompatible dependency specs, such as one with jason ~> 1.3.0 and one with jason ~> 1.2.0, those two packages couldn't be installed in the same downstream project without using override: true to force the Jason package to one revision chosen locally.

If a new version of e.g. credo were published, what would be nice is if we had one PR, across any number of commits, but bumping the version of credo in every one of our Elixir packages that included it. Ideally it would move us to an identical revision across the board, but that's not always possible without human intervention, like we saw in #5324.