Ability to generate code from authenticated external spec url

[quirell]

I know that you can use url instead of local path for your specification file

//go:generate go run github.com/deepmap/oapi-codegen/cmd/oapi-codegen --config=config.yaml  https://github.com/deepmap/oapi-codegen/blob/master/examples/only-models/api.yaml

And I would like to use this feature in my project but my repositories are private so it's impossible atm.
I've noticet that the loader you're using has the ability to do that by overriding this function
https://github.com/getkin/kin-openapi/blob/f66e2a1cb3567e8214f5268a10d955dc24f72ade/openapi3/loader.go#L36
but you don't allow to set it.
I'd like to add a feature that would enable the oapi-codegen command to use authenticated tokens somehow, and I guess some other people could use that so I'd like to implement it in a way that could be merged into the master branch and released sometime, if it aligns with your vision of the project.
Therefore, I'd like to pitch some ideas about how this should be done so it doesn't violate your current vision of how the tool should be configured.
I think it would be enough to add ability to set Authentication header in config file, but I'm not sure if you even want such feature?

[jamietanna]

Hey, thanks for sharing interest in implementing this.

The docs recommend avoiding using HTTPS for grabbing specifications, and instead managing them via a manually updated copy of that file.

I've previously used something like this GitHub Actions setup to make it possible to see when files are out-of-sync, and it may be straightforwardish to make an action that will also update this

This could be improved via renovatebot/renovate#24730 (not yet implemented)

Although it can be handy to do this, it can also lead to a number of issues with builds not being reproducible or having flaky builds due to network connectivity issues.

[jamietanna]

I've also written this which allows for using this re-usable action which allows you to keep vendored files in sync more easily.

I'll update the README to make it clearer that this is an option (and naturally recommended as I wrote it 😝)

[quirell]

@jamietanna
Hi, I just noticed that what you're saying goes against official open api spec which clearily supports external reference.
Even that won't change your mind about this feature ? Shouldn't the users of oapi-codegen be allowed to decide if they want to use this feature or not ?

[jamietanna]

I absolutely see the value of being able to - for ease of development - pointing at a remote spec.

But I've been burned by builds that aren't reproducible in the past, or accidentally bringing in breaking changes without a human being in the loop, so feel that it's something we shouldn't be recommending people do, hence the recommendation to commit the spec to your repo, which could be automated and using authentication.

If there's an overwhelming support from the community, we can rethink this, but given the risks, and the potential for additional support burden on the project (ie issues around "why is my build sometimes failing) I'm not sure we'll be changing our viewpoint, unless we have some sponsorship for the ongoing support of the feature.

See also #1564 is planned for our next major release (whenever that is) to make it opt-in functionality, to reduce the number of folks relying upon it without understanding the risks.

[quirell]

I totally understand that.
By the way, with how we want to approach it I don't think irreproducible builds or connection issues are possible, since we generate code manually and then commit - not using ci/cd- and we're pointing to specific commit with version tag, so we can eliminate both connectivity issues and schema sync issues ( you can't merge if test's are not passing).
Thanks for your continuous effort to improve the tool!

[quirell]

Thanks for a comprehensive answer.
I've read the docs you provided but it's about templating, isn't it ?
I see that recently there was even a PR that documents how to use remote references, so I hardly see this as a discouragement.

I see how your github action can be useful, but in my usecase for example, I would like to generate go client files by referencing openapi spec of services from other repositories, and there's no risk of something becoming out of sync. Anyways, I understand your decision. Thank you!