Update API definitions to fix CAMARA validation warnings and hints

[bigludo7]

What type of PR is this?

Add one of the following kinds:

correction
cleanup
repository management

What this PR does / why we need it:

CAMARA validation is reporting many warnings and hints. This PR reduces that number.

Which issue(s) this PR fixes:

Fixes #271

Special notes for reviewers:

Changelog input

 release-note
 - Update API definitions to fix CAMARA validation warnings and hints

Additional documentation

This section can be blank.

docs

[camara-validation]

CAMARA Validation — PASS (with warnings)

0 errors, 13 warnings, 9 hints | Profile: standard

View full results

[bigludo7]

@rartych @hdamker I need help here as I'm struggling to solve last error:

:1 — [spectral-execution-error] Spectral exited with code 2: Error running Spectral! Use --verbose flag to print the error stack. Error #1: Cannot read properties of null (reading 'in') (code/API_definitions/sim-swap.yaml)

Any help welcome :)
Thanks

[hdamker]

@rartych @hdamker I need help here as I'm struggling to solve last error:

:1 — [spectral-execution-error] Spectral exited with code 2: Error running Spectral! Use --verbose flag to print the error stack. Error #1: Cannot read properties of null (reading 'in') (code/API_definitions/sim-swap.yaml)

Any help welcome :) Thanks

@bigludo7

Two separate issues:

• an infrastructure regression bug in one of the validation rules, see r4 ruleset: camara-security-no-secrets rule crashes Spectral (exit 2) on any null value in a spec tooling#322 and PR fix(linting): guard camara-security-no-secrets given against null nodes tooling#323. After it's fixed you will see also the validation results for sim-swap.yaml
• the release-plan.yaml is inconsistent ... the target_api_status is public instead of alpha. I created draft PR fix(release-plan): set target_api_status to alpha for the alpha pre-release #274 for that. To re-validated and merged after the tooling fix landed (most probably tomorrow)

[bigludo7]

Thanks @hdamker
I wait for the signal.

[hdamker]

Here referencing the common definition does not work, as nullable: true needs a type sibling, not possible in OAS 3.0.3. On the other side the common DateTime can't be defined with nullable: true.

My recommendation: go back to inline definition, just adding the maxLength field.

latestSimChange:
  type: string
  format: date-time
  maxLength: 64
  nullable: true
  description: Timestamp of latest SIM swap performed. It must follow [RFC 3339 (https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.

[hdamker]

Thanks @hdamker
I wait for the signal.

The crash(es) of validation are fixed. There were actually two different ones, one in our custom rule (camaraproject/tooling#322), and after that was fixed an upstream bug got unmasked (camaraproject/tooling#328).

There are three errors now found by Validation, which have the same root cause. See my review comment https://github.com/camaraproject/SimSwap/pull/272/changes#r3394527908. The rule is firing for all three examples using the definition. Should be fixed before merging the PR.