feat(vulnerability): regenerate client from latest openapi spec

[Siasurai]

Description

regenerate API client for vulnerability from latest openapi spec
https://redhat.atlassian.net/browse/RHINENG-26655

Need to check if it's a breaking change

[charlesmulder]

@Siasurai Looks like the regenerated client includes breaking changes and therefore technically requires a major version bump, which can be achieved by appending an exclamation mark after the conventional commit type eg. feat(vulnerability)!.... More info available here https://www.conventionalcommits.org/en/v1.0.0/

These are some of the breaking changes:

1. Removed exported interfaces — consumers using these get compile errors:
   - BusinessRiskListOutData, BusinessRiskListOutMeta
   - CveDetailOutData, CveDetailOutDataAttributes
   - StatusListOutData, StatusListOutMeta
   - SystemDetailsOutData, SystemDetailsOutDataTags
   - DashboardCvesBySeverity, DashboardRecentRules
2. Changed property types in existing interfaces:
   - AffectedSystemsIdsOut.links: Links → InlineResponse2003Links
   - AffectedSystemsIdsOut.meta: MetaAffectedSystems → object (loses type safety)
3. Function return type changes:
   - getAffectedSystemsIdsByCve(): Returns InlineResponse2004 instead of AffectedSystemsIdsOut

I wonder if the vulnerability API itself is versioned and if so, does it adhere to semantic versioning?

[Siasurai]

@charlesmulder I updated the commit message to feat(vulnerabilities)!: for the major version bump

I also asked our backend developer about API versioning. He said the service uses semantic versioning, but the API is still v1 and there should not be any breaking changes (not since the last client generation) New changes should only be added endpoints and attributes.

So the breaking changes in this PR are probably from the generator producing different TypeScript structures (maybe a different generator version), not from real breaking API changes

[charlesmulder]

Thank you for finding out @Siasurai. I have approved the PR. In my opinion, from a javascript-clients point of view, the updated client contains breaking changes, even though the API does not, so using the new API endpoints will require a major version update of the client.

[charlesmulder]

Hi @Siasurai Please update the commit message scope to include the full package name ie. feat(@redhat-cloud-services/vulnerabilities-client)!: regenerate client from latest openapi spec otherwise semver is capped at patch bump.

[Siasurai]

@charlesmulder thanks for noticing, I'll ofc update the message

FYI: I’ve also moved this PR to draft so backend can check why the API schemas are sent without $ref

[Siasurai]

@charlesmulder Hi
Our backend restored $refs in the OpenAPI spec, so I regenerated the client again. The diff looks much cleaner now, and I don’t think there are any real breaking changes, but I’m not 100% sure

Could you please take another look at the review when you have a moment? Thanks a lot in advance!

[charlesmulder]

Hi @Siasurai Thank you for spending time on this.

Still a breaking change requiring adding an ! to your commit message.

1. CvesWithoutErrataOut interface restructured (BREAKING)

Before:

interface CvesWithoutErrataOut {
  updated: CvesWithoutErrataOutUpdated;
  meta: MetaPermissions;
}

After:

interface CvesWithoutErrataOut {
  cves_without_errata: CvesWithoutErrataOutCvesWithoutErrata;
}

• Removed updated property (replaced with cves_without_errata)
• Removed meta property
• Changed structure completely

2. New interface CvesWithoutErrataOutCvesWithoutErrata

Replaced old nested structure with:

interface CvesWithoutErrataOutCvesWithoutErrata {
  enabled?: boolean;
}

3. Renamed interface (BREAKING)

• CvesWithoutErrataOutUpdated → CvesWithoutErrataPatchOut
• Structure changes in nested types

4. New GET endpoint added (non-breaking addition)

getCvesWithoutErrata()  // New method

[Siasurai]

@charlesmulder thank you for review! And done 😊