STATUS: IMPLEMENTED
Context
The Sling Starter GitHub module is mainly a bill of materials, listing all dependencies that should be included in the final build. Updating these dependencies manually is tedious and time-consuming. With the CI checks we have in place, we are already able to validate most dependency updates without the need to manually verify the behaviour of the Sling Starter.
Dependencies in the Sling Starter are specified using the Sling/OSGi feature model, which are not currently supported by automatic dependency update tools
Scope
This document will propose:
- A tool that will be used to generate automatic dependency updates for the Sling Starter
- A policy for automatic updates that can be reused for projects similar to the Sling Starter
Tool selection
Two major dependency updates tools have been considered:
Dependabot is currently enabled for the apache
org on GitHub and generating updates. See also Dependabot . At this time ( ) the Dependabot project does not accept contributions for new ecosystems - https://github.com/dependabot/dependabot-core#contributing-to-dependabot . Since it does not support the OSGi feature model natively, it is not usable in the scope of this proposal.
Renovate is not enabled for the whole apache
github org, but at least one project is using it:
-
INFRA-20365Getting issue details...
STATUS
. In that setup, Renovate forks the repositories and only requires read permissions. There is an open pull request that adds OSGi feature model support to the renovate app: https://github.com/renovatebot/renovate/pull/19282 .
Proposal: use renovate.
Update policy
As discussed at large in Dependabot, not all automatic updates are welcome. Renovate permits a more strict filtering of updates through the renovate.json
file.
The Sling Starter policy is implemented via - SLING-11822Getting issue details... STATUS and https://github.com/apache/sling-org-apache-sling-starter/pull/85 .
The proposed policy for the Sling Starter is
{ "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": [ "config:base" ], "packageRules" : [ { "matchPackagePrefixes": [ "org.apache.tika" ], "groupName": "Apache Tika" }, { "matchPackagePrefixes": [ "org.apache.httpcomponents:" ], "groupName": "Apache HTTPComponents" }, { "matchPackagePrefixes": [ "org.apache.pdfbox:" ], "groupName": "Apache PDFBox" }, { "matchPackagePrefixes": [ "org.apache.sling:org.apache.sling.models" ], "groupName": "Apache Sling Models" }, { "matchPackagePrefixes": [ "org.apache.jackrabbit:" ], "groupName": "Apache Jackrabbit and Jackrabbit Oak", "allowedVersions": "/^[0-9]+\\.[02468]+\\.[0-9]+$/" }, { "matchPackagePatterns": [ "guava" ], "enabled": false }, { "matchManagers": ["maven"], "matchDepTypes": ["provided"], "enabled": false }, { "enabled": false, "matchDatasources": [ "docker" ], "matchUpdateTypes": [ "major" ] } ], "regexManagers": [ { "fileMatch": ["^pom\\.xml$"], "matchStrings" : [ "depName=(?<depName>.*?)\\s+-->\\s+<.*?\\.version>(?<currentValue>.*?)<\\/.*?\\.version>" ], "datasourceTemplate": "maven" } ] }
- Packages which should be updated together are marked using the
groupName
package rules - Jackrabbit and Jackrabbit Oak updated are restricted to stable versions only ( odd minor version component )
- Guava is not updated since it is tied to the Jackrabbit Oak version
- Only minor Docker version updates are activated
- Pom properties that control feature model versions are marked with a special syntax so renovate can process them (see the pom.xml snippet below)
<project> <!-- ... --> <properties> <!-- versions to be replaced in the feature files --> <!-- renovate: depName=org.ow2.asm:asm --> <asm.version>9.3</asm.version> <!-- renovate: depName=org.apache.jackrabbit:jackrabbit-jcr-commons --> <jackrabbit.version>2.20.6</jackrabbit.version> <!-- renovate: depName=org.apache.jackrabbit:oak-api --> <oak.version>1.44.0</oak.version> <!-- ... --> </properties> <!-- ... --> </project>