Scala Steward can raise 3 different kinds of PRs:
Update.ForArtifactId - for a single ArtifactUpdate.ForGroupId - for several artifacts which all have the same Maven group-id, which are also all being updated from the same version, and updated to the same nextVersion.Update.Grouped - manually configured by users using pullRequests.grouping config rules, allowing PRs that update arbitary groups of artifacts.
Update.ForGroupId is pretty good, in that reduces proliferation of single-artifact PRs, and doesn't require manual configuration from users, but could be even better. Consider these two PRs raised together by Scala Steward:
...both of those PRs are actually Update.ForGroupId PRs, but they could be a single Update.ForGroupId PR - they're both updating to and from the same version, they just have different Maven subgroup ids - com.fasterxml.jackson.core & com.fasterxml.jackson.datatype.
In the case of the above PRs, the changes are actually identical, and Scala Steward raising 2 PRs with identical changes is also probably not ideal...
The grouping for Update.ForGroupId PRs happens here:
|
def groupByGroupId(updates: List[ForArtifactId]): List[Single] = { |
|
val groups0 = |
|
updates.groupByNel(s => (s.groupId, s.versionUpdate)) |
If we could identify a reasonable heuristic for trying the grouping with a truncated group-id (ie com.fasterxml.jackson in the above example), we could get more grouping!
Without this, users have to arrive at their own custom config rules, like this:
Identifying reasonable parent group-ids
This is the tricky part - group ids are supposed to be based on reversed domain names, but even those can have a varying number of labels (com.gu vs uk.co.autotrader for instance), and some group ids are not domain name based at all.
There doesn't seem to be any reliable metadata in the POM that states the 'owner' of the group-id used for an artifact:
- jackson-datatype-jsr310-2.20.2.pom doesn't have any part stating that
com.fasterxml is the owner, rather than com.fasterxml.jackson.datatype
etag-caching core_3-13.0.2.pom doesn't have any part stating that com.gu is the owner, rather than com.gu.etag-caching
Still, it might be reasonable to try removing just the last label, so long as there were at least 3 labels remaining.
The fact that the version update has to be identical for grouping would also act as a kind of safety-rail.
See also
Scala Steward can raise 3 different kinds of PRs:
Update.ForArtifactId- for a single ArtifactUpdate.ForGroupId- for several artifacts which all have the same Maven group-id, which are also all being updated from the same version, and updated to the samenextVersion.Update.Grouped- manually configured by users usingpullRequests.groupingconfig rules, allowing PRs that update arbitary groups of artifacts.Update.ForGroupIdis pretty good, in that reduces proliferation of single-artifact PRs, and doesn't require manual configuration from users, but could be even better. Consider these two PRs raised together by Scala Steward:com.fasterxml.jackson.corecom.fasterxml.jackson.datatype...both of those PRs are actually
Update.ForGroupIdPRs, but they could be a singleUpdate.ForGroupIdPR - they're both updating to and from the same version, they just have different Maven subgroup ids -com.fasterxml.jackson.core&com.fasterxml.jackson.datatype.In the case of the above PRs, the changes are actually identical, and Scala Steward raising 2 PRs with identical changes is also probably not ideal...
The grouping for
Update.ForGroupIdPRs happens here:scala-steward/modules/core/src/main/scala/org/scalasteward/core/data/Update.scala
Lines 233 to 235 in eaf4ea2
If we could identify a reasonable heuristic for trying the grouping with a truncated group-id (ie
com.fasterxml.jacksonin the above example), we could get more grouping!Without this, users have to arrive at their own custom config rules, like this:
Identifying reasonable parent group-ids
This is the tricky part - group ids are supposed to be based on reversed domain names, but even those can have a varying number of labels (
com.guvsuk.co.autotraderfor instance), and some group ids are not domain name based at all.There doesn't seem to be any reliable metadata in the POM that states the 'owner' of the group-id used for an artifact:
com.fasterxmlis the owner, rather thancom.fasterxml.jackson.datatypeetag-cachingcore_3-13.0.2.pom doesn't have any part stating thatcom.guis the owner, rather thancom.gu.etag-cachingStill, it might be reasonable to try removing just the last label, so long as there were at least 3 labels remaining.
The fact that the version update has to be identical for grouping would also act as a kind of safety-rail.
See also
Update.ForGroupIdcould enforce that all artifacts are genuinely for the same Maven group-id #3779 - this enhancement would conflict, to some extent, with the suggested refactor in this issueupdates.*&pullRequests.groupingconfig use inconsistent group-&-artifact-id matching expressions #3655 -GroupRepoConfig.configToSlowDownUpdatesFrequencycould be affected by this, as I don't think we have proper sub-group-id matching yet...