Renovate Nextcloud 数据源配置指南用 registryUrls 与自定义管理器自动化 Nextcloud 应用更新【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovateMend.io 出品的跨平台依赖自动化 CLI内置了nextcloud数据源用于从 Nextcloud 官方应用商店的 feed 中发现 Nextcloud 应用App的更新版本。本指南将围绕该数据源的官方说明结合仓库源码讲解其工作原理、无默认 registry 时的registryUrls配置方法以及借助 regex 自定义管理器自动升级 Nextcloud 平台版本号的完整实战方案。Nextcloud 数据源是什么nextcloud数据源datasource的作用是从 Nextcloud 官方 feed 中读取应用更新信息。与 npm、Maven 等自带默认仓库地址的数据源不同Renovate 官方明确说明该数据源没有默认的 registry url必须通过registryUrls配置项显式指定否则无法完成版本查询。这一点在源码中可以得到印证在 数据源实现 中_getReleases方法首先检查registryUrl如果为空则直接返回nullif (!registryUrl) { return null; }同时该数据源类并未像其他数据源那样覆写defaultRegistryUrls见 datasource 基类 中该字段的默认行为因此用户配置是获取 registry 的唯一途径。该数据源通过 数据源注册表 中的api.set(NextcloudDatasource.id, new NextcloudDatasource())完成注册数据源 id 固定为nextcloud。配置 registryUrls让 Nextcloud 数据源开始工作由于没有默认 registry你需要通过registryUrls覆盖默认行为。registry 指向的是 Nextcloud 官方应用商店按平台版本导出的应用列表 JSON{ packageRules: [ { matchDatasources: [nextcloud], registryUrls: [ https://apps.nextcloud.com/api/v1/platform/30.0.0/apps.json ] } ] }上述配置的含义是当某个依赖匹配到nextcloud数据源时从https://apps.nextcloud.com/api/v1/platform/30.0.0/apps.json拉取该平台版本示例中为 30.0.0下所有应用的更新列表。关于该 JSON 的结构从 schema 定义 可以看出它是一个顶层数组每个元素包含字段类型说明idstring应用标识即packageName匹配的目标websitestring应用主页用于推导sourceUrl与changelogUrlreleases数组该应用的版本列表每个releases元素又包含字段类型说明versionstring版本号createdstring发布时间ISO 8601 字符串isNightlyboolean是否为夜间构建版本translations记录Record各语言版本的变更日志键为语言代码如en数据源会从响应数组中查找id packageName的应用找不到时返回null对应 源码因此packageName必须与 feed 中的应用id完全一致。数据源如何解析应用更新源码级原理拿到 registry 的 JSON 后NextcloudDatasource会做如下处理见 index.tsHTTP 请求与校验通过this.http.getJson(registryUrl, Applications)请求 registry并用 Zod 模式Applications校验响应结构。模式中的LooseArray、LooseRecord来自 schema-utils 工具允许响应在兼容范围内存在额外字段而不会校验失败。版本号排序该数据源声明了defaultVersioning semver.id即 semver 版本规则所有应用版本都按语义化版本解析与排序。时间戳规范化created字段经asTimestamp转为标准 ISO 8601 时间戳作为releaseTimestamp测试断言中可见毫秒级格式2025-01-14T09:13:25.123Z。变更日志提取默认取英文翻译defaultTranslationLanguage en中的changelog字段当 changelog 为空字符串或缺失时changelogContent会被置为undefined而非空串源码。稳定版判定isStable: !release.isNightly夜间构建被标记为非稳定版本从而影响 Renovate 对发布渠道的过滤。源码与更新日志 URL 推导当应用website匹配正则(?prefix.*github.com\/nextcloud)(?suffix\/.*)时sourceUrl取原website而changelogUrl会被改写为{prefix}-releases{suffix}的形式例如https://github.com/nextcloud/user_oidc会被推导为https://github.com/nextcloud-releases/user_oidc不匹配时changelogUrl回退为website本身。这些行为在 单元测试 中有完整覆盖包括无 registryUrl 返回 null、找不到应用返回 null、changelogUrl 推导以及changelog 内容、isStable、releaseTimestamp 的组装结果等场景可作为理解数据源行为的权威参考。缓存机制与容错数据源请求通过withCache进行包级缓存源码getReleases(config: GetReleasesConfig): PromiseReleaseResult | null { return withCache( { namespace: datasource-${NextcloudDatasource.id}, key: ${config.registryUrl}:${config.packageName}, fallback: true, }, () this._getReleases(config), ); }缓存命名空间为datasource-nextcloud该命名空间已在 缓存命名空间清单 中注册缓存键由registryUrl与packageName组合而成不同平台版本的 registry 互不干扰。fallback: true表示开启扩展硬 TTL 的优雅降级当上游 Nextcloud 服务出错时只要缓存数据尚未超过硬 TTL就返回过期数据而不是直接抛错实现见 with-cache.ts默认 TTL 为 30 分钟。此外datasource 基类 默认registryStrategy first即当配置了多个 registry url 时Renovate 默认只使用第一个见 registry 解析逻辑。因此请把最想使用的平台版本 registry 放在第一位。自动更新平台版本用自定义管理器接管 URL 中的版本号registryUrls方案的一个局限是URL 中写死的平台版本如30.0.0本身不会随 Nextcloud 主版本升级而变化。官方文档给出了进阶方案——通过 regex 自定义管理器custom manager识别并更新平台版本号。如果你希望 Renovate 自动更新平台版本可以在customManagers中这样配置{ customManagers: [ { customType: regex, managerFilePatterns: [/(^|/)renovate.json$/], matchStrings: [ https://apps.nextcloud.com/api/v1/platform/(?currentValue\\d\\.\\d\\.\\d)/apps.json ], depNameTemplate: nextcloud/server, datasourceTemplate: github-releases } ] }这段配置的含义与工作方式managerFilePatterns限定在仓库根目录或任意目录的renovate.json文件中查找匹配串即你自己的 Renovate 配置文件matchStrings用正则定位 registry URL 中的平台版本号命名捕获组currentValue捕获30.0.0这类三位语义化版本depNameTemplate声明依赖名nextcloud/serverdatasourceTemplate声明使用github-releases数据源来查询 Nextcloud 服务端的最新发布版本。配置完成后当 Nextcloud 官方发布新的平台版本时Renovate 会像对待普通依赖一样为renovate.json中的这个版本号创建更新 PR平台版本与基于它的应用列表得以同步演进。配置要点与注意事项packageName必须对应 feed 中的应用id查询不到匹配应用时数据源返回null依赖会被跳过。platform 版本与应用的兼容性apps.json是按平台版本切分的升级平台版本后请同步核对 registry URL避免拉取到与当前平台不兼容的应用列表。版本规则为 semver该数据源默认使用 semver 解析版本非语义化版本号的 app 可能被过滤。夜间构建被视为非稳定版isNightly为true的 release 会以isStable: false输出默认情况下不会进入稳定渠道的升级候选。变更日志依赖英文翻译只有translations.en.changelog非空时才会带出changelogContent。多个 registry 默认只取第一个如需切换平台版本直接调整registryUrls的顺序或内容即可无需改动数据源本身。相关资源数据源官方说明lib/modules/datasource/nextcloud/readme.md核心实现lib/modules/datasource/nextcloud/index.ts响应结构校验lib/modules/datasource/nextcloud/schema.ts单元测试lib/modules/datasource/nextcloud/index.spec.ts数据源注册lib/modules/datasource/api.ts数据源基类与 registry 策略lib/modules/datasource/datasource.ts、lib/modules/datasource/index.ts【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Renovate Nextcloud 数据源配置指南：用 registryUrls 与自定义管理器自动化 Nextcloud 应用更新
Renovate Nextcloud 数据源配置指南用 registryUrls 与自定义管理器自动化 Nextcloud 应用更新【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovateMend.io 出品的跨平台依赖自动化 CLI内置了nextcloud数据源用于从 Nextcloud 官方应用商店的 feed 中发现 Nextcloud 应用App的更新版本。本指南将围绕该数据源的官方说明结合仓库源码讲解其工作原理、无默认 registry 时的registryUrls配置方法以及借助 regex 自定义管理器自动升级 Nextcloud 平台版本号的完整实战方案。Nextcloud 数据源是什么nextcloud数据源datasource的作用是从 Nextcloud 官方 feed 中读取应用更新信息。与 npm、Maven 等自带默认仓库地址的数据源不同Renovate 官方明确说明该数据源没有默认的 registry url必须通过registryUrls配置项显式指定否则无法完成版本查询。这一点在源码中可以得到印证在 数据源实现 中_getReleases方法首先检查registryUrl如果为空则直接返回nullif (!registryUrl) { return null; }同时该数据源类并未像其他数据源那样覆写defaultRegistryUrls见 datasource 基类 中该字段的默认行为因此用户配置是获取 registry 的唯一途径。该数据源通过 数据源注册表 中的api.set(NextcloudDatasource.id, new NextcloudDatasource())完成注册数据源 id 固定为nextcloud。配置 registryUrls让 Nextcloud 数据源开始工作由于没有默认 registry你需要通过registryUrls覆盖默认行为。registry 指向的是 Nextcloud 官方应用商店按平台版本导出的应用列表 JSON{ packageRules: [ { matchDatasources: [nextcloud], registryUrls: [ https://apps.nextcloud.com/api/v1/platform/30.0.0/apps.json ] } ] }上述配置的含义是当某个依赖匹配到nextcloud数据源时从https://apps.nextcloud.com/api/v1/platform/30.0.0/apps.json拉取该平台版本示例中为 30.0.0下所有应用的更新列表。关于该 JSON 的结构从 schema 定义 可以看出它是一个顶层数组每个元素包含字段类型说明idstring应用标识即packageName匹配的目标websitestring应用主页用于推导sourceUrl与changelogUrlreleases数组该应用的版本列表每个releases元素又包含字段类型说明versionstring版本号createdstring发布时间ISO 8601 字符串isNightlyboolean是否为夜间构建版本translations记录Record各语言版本的变更日志键为语言代码如en数据源会从响应数组中查找id packageName的应用找不到时返回null对应 源码因此packageName必须与 feed 中的应用id完全一致。数据源如何解析应用更新源码级原理拿到 registry 的 JSON 后NextcloudDatasource会做如下处理见 index.tsHTTP 请求与校验通过this.http.getJson(registryUrl, Applications)请求 registry并用 Zod 模式Applications校验响应结构。模式中的LooseArray、LooseRecord来自 schema-utils 工具允许响应在兼容范围内存在额外字段而不会校验失败。版本号排序该数据源声明了defaultVersioning semver.id即 semver 版本规则所有应用版本都按语义化版本解析与排序。时间戳规范化created字段经asTimestamp转为标准 ISO 8601 时间戳作为releaseTimestamp测试断言中可见毫秒级格式2025-01-14T09:13:25.123Z。变更日志提取默认取英文翻译defaultTranslationLanguage en中的changelog字段当 changelog 为空字符串或缺失时changelogContent会被置为undefined而非空串源码。稳定版判定isStable: !release.isNightly夜间构建被标记为非稳定版本从而影响 Renovate 对发布渠道的过滤。源码与更新日志 URL 推导当应用website匹配正则(?prefix.*github.com\/nextcloud)(?suffix\/.*)时sourceUrl取原website而changelogUrl会被改写为{prefix}-releases{suffix}的形式例如https://github.com/nextcloud/user_oidc会被推导为https://github.com/nextcloud-releases/user_oidc不匹配时changelogUrl回退为website本身。这些行为在 单元测试 中有完整覆盖包括无 registryUrl 返回 null、找不到应用返回 null、changelogUrl 推导以及changelog 内容、isStable、releaseTimestamp 的组装结果等场景可作为理解数据源行为的权威参考。缓存机制与容错数据源请求通过withCache进行包级缓存源码getReleases(config: GetReleasesConfig): PromiseReleaseResult | null { return withCache( { namespace: datasource-${NextcloudDatasource.id}, key: ${config.registryUrl}:${config.packageName}, fallback: true, }, () this._getReleases(config), ); }缓存命名空间为datasource-nextcloud该命名空间已在 缓存命名空间清单 中注册缓存键由registryUrl与packageName组合而成不同平台版本的 registry 互不干扰。fallback: true表示开启扩展硬 TTL 的优雅降级当上游 Nextcloud 服务出错时只要缓存数据尚未超过硬 TTL就返回过期数据而不是直接抛错实现见 with-cache.ts默认 TTL 为 30 分钟。此外datasource 基类 默认registryStrategy first即当配置了多个 registry url 时Renovate 默认只使用第一个见 registry 解析逻辑。因此请把最想使用的平台版本 registry 放在第一位。自动更新平台版本用自定义管理器接管 URL 中的版本号registryUrls方案的一个局限是URL 中写死的平台版本如30.0.0本身不会随 Nextcloud 主版本升级而变化。官方文档给出了进阶方案——通过 regex 自定义管理器custom manager识别并更新平台版本号。如果你希望 Renovate 自动更新平台版本可以在customManagers中这样配置{ customManagers: [ { customType: regex, managerFilePatterns: [/(^|/)renovate.json$/], matchStrings: [ https://apps.nextcloud.com/api/v1/platform/(?currentValue\\d\\.\\d\\.\\d)/apps.json ], depNameTemplate: nextcloud/server, datasourceTemplate: github-releases } ] }这段配置的含义与工作方式managerFilePatterns限定在仓库根目录或任意目录的renovate.json文件中查找匹配串即你自己的 Renovate 配置文件matchStrings用正则定位 registry URL 中的平台版本号命名捕获组currentValue捕获30.0.0这类三位语义化版本depNameTemplate声明依赖名nextcloud/serverdatasourceTemplate声明使用github-releases数据源来查询 Nextcloud 服务端的最新发布版本。配置完成后当 Nextcloud 官方发布新的平台版本时Renovate 会像对待普通依赖一样为renovate.json中的这个版本号创建更新 PR平台版本与基于它的应用列表得以同步演进。配置要点与注意事项packageName必须对应 feed 中的应用id查询不到匹配应用时数据源返回null依赖会被跳过。platform 版本与应用的兼容性apps.json是按平台版本切分的升级平台版本后请同步核对 registry URL避免拉取到与当前平台不兼容的应用列表。版本规则为 semver该数据源默认使用 semver 解析版本非语义化版本号的 app 可能被过滤。夜间构建被视为非稳定版isNightly为true的 release 会以isStable: false输出默认情况下不会进入稳定渠道的升级候选。变更日志依赖英文翻译只有translations.en.changelog非空时才会带出changelogContent。多个 registry 默认只取第一个如需切换平台版本直接调整registryUrls的顺序或内容即可无需改动数据源本身。相关资源数据源官方说明lib/modules/datasource/nextcloud/readme.md核心实现lib/modules/datasource/nextcloud/index.ts响应结构校验lib/modules/datasource/nextcloud/schema.ts单元测试lib/modules/datasource/nextcloud/index.spec.ts数据源注册lib/modules/datasource/api.ts数据源基类与 registry 策略lib/modules/datasource/datasource.ts、lib/modules/datasource/index.ts【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考