I support this request from WMDE's side.

Decision summary

• For the API client to know if the Wikibase instance provides the same REST API functionality as another instance, it would be sufficient to know what Wikibase REST API schema version (OpenAPI document version) the instance provides.
• We will use the version of the schema document to reflect non-breaking and breaking changes accordingly.
• Ideally, each Wikibase instance will provide its schema (Open API document) available for clients. We’ll explore how to do it exactly, ideally in a way that does not rely on deploying Wikibase changes in particular way, but rather have API provide it itself
• We’ve decided to not indicate the schema version in HTTP response headers for now
• We see no need for now to expose the particular API implementation version (e.g. the more performant implementation of the same API functionality)

Thanks for the update and adjustment @Jdlrobson
I am likely missing to complete context but I think I am with @Tgr on suggesting to possibly considering some slightly different approach.
If the test is meant to be detecting significant changes in JS/CSS for WMF wikis, wouldn't it be more accurate to have tests - maybe even voting/blocking ones - that would run with the exact set of extensions and all as is provided on Wikipedia and so on? Possibly might be several "flavours" of such a check, as, as you notice, Wikidata runs a bit more code incl. JS/CSS for it custom UI, possibly similar situation could happen for Wikimedia Commons.
I don't know where such checks would live ideally in WMF Jenkins CI but having them as per-commit tests run on essentially any MW extension does seem like you might be tracking something slightly different that you actually intend to observe?

We've unblocked ourselves by skipping the test again. Apologies for the inconvenience.

Reopening as I am afraid it might be still happening. See eg. gate-and-submit jobs failing for https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/971918 -- we're quite convinced this change cannot affect Resource Loader's module size.

yes, thanks! I guess the only thing to "document" would be stating the API will be doing non-breaking changes whenever possible since considered stable. ("v1")
The mentioned tickets deal with the relevant details, this one is no longer needed.

@Physikerwelt if I see correctly in https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php81-docker/13968/console, the failed end to end test was not Wikibase REST API's but mediawiki one

Keeping the ticket open for the final verification by @Ifrahkhanyaree_WMDE

Works as expected, thank you

Leaving the ticket open for @Ifrahkhanyaree_WMDE final verification.

Looks good, thank you!

@Ifrahkhanyaree_WMDE Wikibase does not validate the script used in labels/descriptions/aliases. There might be cases when that wouldn't be desired. And while it would make sense in some obvious cases it might not be a trivial mechanism to create. In any case, adding this kind of validation is something outside of API's responsibilities, i.e. it should be a policy/restriction/safety that Wikibase generally employs.

oh, thanks. I stupidly checked on Wikidata not Commons.

Seems to have been potentially fixed meanwhile

Seems like it has been cleaned up sufficiently.

yes

thanks @jbond . Phabricator accounts have been @WMDE_Norman and @oleksandr_tsyba_WMDE - both disabled already