generate go client from openapi spec

[houqp]

relates to #9080.

Client readme: https://github.com/houqp/airflow/tree/client_go/clients/go.

TODO:

• test client generation in CI if there is openapi spec change
• disable unapplicable precommit checks for generated client code
• Create custom README
• Create documentation for go client release process
• change username back to apache
• support problem+json content type in openapi generator

---

Make sure to mark the boxes below before creating PR: [x]

• Description above provides context of the change
• Unit tests coverage for changes (not needed for documentation changes)
• Target Github ISSUE in description if exists
• Commits follow "How to write a good git commit message"
• Relevant documentation is updated including usage instructions.
• I will engage committers as explained in Contribution Workflow Example.

---

In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.
Read the Pull Request Guidelines for more information.

[houqp]

Here is what it looks like to use the go client in a real world project: https://github.com/houqp/terraform-provider-airflow/blob/openapi/resource_variable.go, https://github.com/houqp/terraform-provider-airflow/blob/openapi/provider.go

[houqp]

created upstream openapi generator PR to add problems HTTP API support: OpenAPITools/openapi-generator#6793

[potiuk]

One general comment - I think we should not commit the generated code of client to the Airflow Code nor copied OpenAPI specification. It should be generated and ignored, instead we should package it in some .tar.gz or .zip file and publish it as artifact of the CI build - later we will add a mechanism to release it together with the release of Airflow.

[mik-laj]

@potiuk The ability to view the code in the repository is very helpful. When I don't know the library and plan to use it, I often look at its source code. When I have a problem with the library, I also look for its source on the internet, because a local copy of the source code is hidden in strange directories.

The Kubernetes library is published in a similar way.
https://github.com/kubernetes-client/python

[potiuk]

Correct. But I do not think it should be in the airflow repo because the code is auto-generated . It should be separate repo (and I think maybe a separate repo for each client) and we should publish the code there from master automatically when there is a change in the client spec. How about 'apache/airflow-client-go' etc.?

What we will need to do is I think to:

1. create the repos

2. setup secret tokens to be able to push to those repos from airflow master build

I am happy to help with that and talk to infra about those.

WDYT?

[mik-laj]

@potiuk It's a good idea, but I'm not sure we have to do it now. Temporarily storing automatically generating the code will allow us to solve teething problems more easily.

We can transfer all the code to new repositories for each client before the release of Airflow 2.0. Then the specification will be stable all the time and will not change. The Airflow team will also have much more experience with automatically generated clients, so there will be fewer problems with them. Now previewing changes in clients while changing specifications would be very helpful to prevent unknown problems.

We also don't have to publish development versions in a separate repository. It seems to me that publishing artifacts on Github Actions will be sufficient and will also allow download clients on forks and pull requests. Which will help solve teething problems.

[houqp]

@potiuk @mik-laj github actions are passing now, ready for another round of review.

[houqp]

@potiuk @mik-laj @feluelle updated add pre-commit as dependency to code gen script and use it to prepend headers, ready for another round of review.

[potiuk]

Some suggestions for more structure of organising the changes - following approach that we will soon take :)

[houqp]

@potiuk moved codegen validation to separate workflow.