feat: generate inline enums

[ctreatma]

This enables the RESOLVE_INLINE_ENUMS option for openapi-generator@v7.0.0 to tell the generator to create dedicated models for inline enums instead of treating the inline enums as plain strings. Among other things, generating inline enums helps the SDK properly validate API responses against oneOf schemas in which each component schema has different enum values for the same property name.

In addition to the RESOLVE_INLINE_ENUMS option, this also enables the enumClassPrefix setting. Since the constants used in each enum are defined in the same scope, we have to turn this setting on in order to avoid conflicts between different enums that include identical values.

Fixes #124

[t0mk]

@ctreatma , sorry I clicked on Ready for Review by accident.

[ctreatma]

sorry I clicked on Ready for Review by accident.

No worries! I was ready to take it out of draft anyway (or more to the point, I forgot I'd left it as a draft).

[t0mk]

It looks good, and I think it's a useful change. just briefly see my note above https://github.com/equinix-labs/metal-go/pull/145#pullrequestreview-1628845081

On a bit unrealted note, now that we know how templates work in oag, we could for example do a custom partial_header.mustache, without the #appDescription text, which takes tens of (visual) lines in the beginning of every go source code file.

[ctreatma]

On a bit unrealted note, now that we know how templates work in oag, we could for example do a custom partial_header.mustache, without the #appDescription text, which takes tens of (visual) lines in the beginning of every go source code file.

Before doing something like this, I think we'd need to improve how our custom templates are managed so that we can easily pull in upstream changes any time we upgrade the generator. I'm not a huge fan of our current patching process (I find it somewhat difficult to reason about and it can be tricky to fix things when patching fails)...but keeping templates up-to-date with the current patching process could look like:

• instead of custom templates we have patch files
• we use the openapi-generator author template to eject the templates from the generator
• apply the patches to the templates
• then generate the code using the patched templates

[github-actions[bot]]

This PR is included in version 0.22.0 :tada: