Commit Graph
9 Commits
Author SHA1 Message Date
infinito-nexus-updater[bot] 0efe436e61 update(versions): update pins with a declared source (web-app-xwiki) 2026-10-21 10:35:14 +00:00
infinito-nexus-updater[bot] 1d6bcdc907 update(versions): update pins with a declared source (web-app-xwiki) 2026-10-19 10:26:53 +00:00
infinito-nexus-updater[bot] 279aae5713 update(versions): update pins with a declared source (web-app-xwiki) 2026-10-15 19:54:46 +00:00
infinito-nexus-updater[bot] d827b0575f update(versions): update pins with a declared source (web-app-xwiki) 2026-10-05 19:20:55 +00:00
kevinveenbirkenbachandClaude Opus 5.5 739c78bad1 feat(update): bump addon pins through their declared source
The version-source updater only read meta/services.yml. An addon pinned in
meta/addons/<id>.yml stayed where it was: the ONLYOFFICE connector for
Nextcloud sat on v10.1.2, which does not install on Nextcloud 35, until
someone bumped it by hand.

The updater now reads addon files too. An addon declares its source in the
`update:` block it already has, beside monitored, catalog and upstream_id.
A monitored addon of the github-releases catalog needs nothing more: its
upstream_id names the repository whose tags are its versions. The
update-version-sources job opens the PRs, one per role.

Every pinned addon is wired:

- nextcloud onlyoffice carries its own version pin now. Its archive URL
  stays a literal that carries the pin, because
  test_pinned_addon_archives_available reads it as written
- wordpress mcp-adapter, moodle auth_oidc and jellyfin sso-authentication
  follow the tags of their repository, moodle within its v4.5 series
- the three xwiki extensions read their Maven metadata
- pretix-oidc reads the PyPI simple index. The JSON API answers 404 behind
  the package cache the test stack routes pypi.org through
- joomla's plugin is built here and jellyfin's ldap-authentication is bound
  to the md5 of its archive; both are opted out with that reason

A bump rewrites the pin and the config.archive line together, and an
archive that does not carry the pin fails test_version_keys, so the two
cannot drift apart again. test_version_pins_are_watched covers addon pins
as well: a new one without a source or a reasoned opt-out fails the lint.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-10-05 02:50:48 +02:00
kevinveenbirkenbachandClaude Opus 5 3eb69b3d78 fix(xwiki): name the AI LLM extension artifact that upstream actually publishes
2383311b7c declared the extension as org.xwiki.contrib.llm:application-ai-llm-ui.
That artifact does not exist at version 0.7, so the extension manager fails while
resolving it and nothing installs.

Measured against the registry the role reads:

  200  .../org/xwiki/contrib/llm/application-ai-llm-models-ui/0.7/
  404  .../org/xwiki/contrib/llm/application-ai-llm-ui/0.7/

The 404 body names the missing path itself, so this is not a redirect or a
substring artefact.

The version stays at 0.7; only the artifact id was wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-31 11:42:32 +02:00
kevinveenbirkenbachandClaude Opus 5 2383311b7c feat(xwiki): declare the AI LLM extension as a gateway consumer
xwiki was listed in requirement 036 as an unverified candidate. Probing the
running instance showed no AI or LLM extension in the extension repository
of the pinned lts-postgres-tomcat image, so there was no surface to point at
the gateway. Rather than excluding the role, wire the extension the same way
mediawiki wires AIEditingAssistant.

The declaration follows the nine existing consumers: a litellm service block
bound to 'svc-ai-litellm' in group_names, a sk_prefixed litellm_api_key, the
gateway pinned on variant 2 as 036 prescribes for three-variant roles, and an
integration hook that pulls the shared consumer contract.

meta/addons/ai-llm.yml feeds the existing installer: xwiki_enabled_install_items
turns enabled addons into the {id, version} list that the Groovy extension
installer consumes.

Two limits, deliberately not papered over. The maven coordinate
org.xwiki.contrib.llm:application-ai-llm-ui at 0.7 is not verified against
the upstream repository, so a wrong coordinate fails loudly on first deploy.
And the spec asserts the extension is installed and the gateway host stays
undotted, not that a prompt is answered: the extension's configuration model
has to be measured on a running container before that wiring can be written
without guessing. xwiki therefore does not yet satisfy criterion 6.

This role has never been deployed; only the gate has run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-28 12:41:55 +02:00
kevinveenbirkenbachandClaude Opus 4.8 9a4701370a refactor(addons): move wordpress addon tasks to tasks/addons; remove bogus xwiki matomo addon
Relocate the wordpress per-addon task files from tasks/plugins/ to tasks/addons/ (pure renames) and repoint tasks/main.yml, giving every role a uniform tasks/addons/ layout. Remove roles/web-app-xwiki/meta/addons/matomo.yml: matomo is provided as a service via services.matomo, not an Extension-Manager extension, and the org.xwiki.contrib:matomo extension does not exist in the nexus catalog (install plan failed).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-18 00:16:54 +02:00
kevinveenbirkenbachandClaude Opus 4.8 6b7a579850 feat(xwiki): migrate plugins to meta/addons (req 026)
oidc-authenticator (bridges sso), ldap-authenticator (bridges ldap), matomo (bridges matomo); version pins preserved as strings; xwiki_filters derives install items from addons.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-17 11:30:46 +02:00