`updates.*` & `pullRequests.grouping` config use inconsistent group-&-artifact-id matching expressions

[rtyley]

I'm not sure what the best plan to resolve this would be, but I just wanted to document that for group-&-artifact-id matching, .scala-steward.conf uses differing syntax (ie has differing capabilities), in different parts of the file - and this can be confusing and lead to misconfiguration issues.

• All updates.* config (eg updates.allow, updates.ignore, etc), and dependencyOverrides[].dependency, use org.scalasteward.core.repoconfig.UpdatePattern which supports only exact string match on group-id & artifact-id (so, for instance, you could never really hope to match all the group-ids that Amazon uses). It does include VersionPattern which supports prefix/suffix/exact/contains-matching for version numbers.

  scala-steward/modules/core/src/main/scala/org/scalasteward/core/repoconfig/UpdatePattern.scala

  Lines 43 to 44 in 31f8cb6

  	val byGroupId = patterns.filter(_.groupId === update.groupId)
  	val byArtifactId = byGroupId.filter(_.artifactId.forall(_ === update.artifactId.name))

• pullRequests.grouping config uses org.scalasteward.core.repoconfig.PullRequestUpdateFilter, which has a regex-based implementation that supports a wildcard syntax:

  scala-steward/modules/core/src/main/scala/org/scalasteward/core/repoconfig/PullRequestUpdateFilter.scala

  Lines 35 to 43 in 31f8cb6

  	groupRegex.forall(_.matches(update.groupId.value)) &&
  	artifactRegex.forall(_.matches(update.mainArtifactId)) &&
  	version.forall(isMatchedVersion(_, update))
  	private lazy val groupRegex = group.map(wildcardRegex)
  	private lazy val artifactRegex = artifact.map(wildcardRegex)
  	private def wildcardRegex(groupOrArtifact: String) = {
  	val pattern = Regex.quote(groupOrArtifact).replaceAll("\\*", "\\\\E.+\\\\Q")

Why go beyond exact-string-matching?

From Sonatype, on group-id namespace ownership:

There is no need to create new tickets for new subgroups!

When we grant permissions at the top-level groupId, like io.github.example, you can publish any components under that groupId or any sub-groups that look like io.github.example.mysubgroup1 or io.github.example.android.

It's reasonably common for organisations that publish many artifacts to use sub-group-ids to link together related groups of artifacts, rather than publish them all under the top-level organisation group-id. For instance, AWS control software.amazon as their Maven group id, but almost always release artifacts with sub-group-ids:

• software.amazon.awssdk
• software.amazon.awscdk
• software.amazon.kinesis
• ...many more

To configure update rules for all AWS artifacts, you'd have to write a lot of repetitive config.

Considerations for consolidation

It would be great for users if a single adequately-powerful syntax for filtering artifacts by group-id & artifact-id was used uniformly throughout .scala-steward.conf. I'm not sure how disruptive changing the syntax would be...

Matching group-&-sub-group-ids

Using the more-powerful syntax from PullRequestUpdateFilter everywhere would handle most use cases, but it could be refined to handle sub-groups better. Consider our case at the Guardian where we want to match our top-level group and all sub-groups:

• com.gu
• com.gu.play-googleauth
• com.gu.play-secret-rotation

Currently, even using the PullRequestUpdateFilter syntax, we still have to define two filters - one to handle the top-level group (com.gu), and one to handle all sub-groups (com.gu.*):

"filter" = [{"group" = "com.gu"}], {"group" = "com.gu.*"}]

We want to match all the above group-ids, but not, eg, com.guidoschmidt17, which would be matched by com.gu*, for instance.

If there was a syntax where when we wrote com.gu, all sub-domains (ie com.gu.*) were covered too - that would be ideal for us, and perhaps also what most users would expect to happen?

See also

• Add tests for pullRequests.grouping syntax #3654