RouterOS 7.23beta5: /app YAML schema validation failures

[github-actions]

RouterOS 7.23beta5 /app YAML Schema Validation Failures

RouterOS 7.23beta5 built-in /app YAML entries failed validation against docs/7.23beta5/routeros-app-yaml-schema.json.

This typically means MikroTik has introduced new YAML syntax not yet covered by the schema.
The schema should be updated to allow the new syntax and re-validated.

Failing /app entries

• lorawan-stack: YAML parse error: duplicated mapping key (61:7)

58 | TTN_LW_CONSOLE_UI_QRG_BASE_URL: ...
59 | TTN_LW_CONSOLE_UI_GCS_BASE_URL: ...
60 | TTN_LW_CONSOLE_UI_DCS_BASE_URL: ...
61 | TTN_LW_CONSOLE_UI_IS_BASE_URL: ...
------------^
62 | TTN_LW_CONSOLE_UI_ACCOUNT_URL: ...
63 | ports:

• mikrodash: / must NOT have additional properties; /services/mikrodash/environment/ROUTER_HOST must be string; /services/mikrodash/environment/ROUTER_HOST must be number; /services/mikrodash/environment/ROUTER_HOST must be boolean; /services/mikrodash/environment/ROUTER_HOST must be null; /services/mikrodash/environment/ROUTER_HOST must match exactly one schema in oneOf; /services/mikrodash/environment must be array; /services/mikrodash/environment must be null; /services/mikrodash/environment must match exactly one schema in oneOf

Workflow run

View run logs

[mobileskyfi]

I'm going to leave this open. At this point, there is no reason for a schema change. Both since MikroTik can fix both issues (and should), and even if technically "working" in RouterOS, it's not be "good practice" to allow this generally in schema.

Reasons:

• lorawan-stack - has a dup YAML entry, that is not valid in pure YAML (e.g. outside /app YAML schema) — MikroTik is more permissive in parsing (e.g. first win, or last wins), since it works in RouterOS, as-is. If RouterOS is source of truth for what is "valid" /app YAML, then schema should allow. But as a good practice (and not sure technically) to allow duplicate keys. Dup keys are harmless here (both are same value, so does not matter which is used), if they varied, which would win? Fix likely not simple to "allow duplications" since that is not valid YAML, since the parser in library have to ignore.
• mikrodash - similar, the [placeholder] scheme uses brackets for string interpolation. But here ROUTER_HOST: [routerIP] looks like a YAML array to parser, so it's valid YAML. But our schema allows most types here, but not a YAML array. Now, in /app, it works and [placeholder] variable is replaced - so it does not treat it like a YAML array, just a string (even though syntax-wise it an YAML array)

Now this raises a /app YAML schema process conundrum... how to handle in CI, whether beta/rc should be latest more generally. i.e. it's unknown if new syntax found was allowed by older version (e.g. 8080:80:tcp:web work 7.22 is not been tested). For now, the CI will continue creating issues because there is not a /app YAML for the release (so it will retry and attempt to build one). Since I do not want to fix this in schema and wait for MikroTik to comment/fix their app YAML... CoPilot can adds some "skip versions" list to auto.yaml, which includes only 7.23beta5, and should default in workflow_dispatch input (so could adjust the list without changing in CI to verify) to avoid dups like #54 daily in future.