#25654 ci(python): check generated Python Connexion server code in a GitHub workflow

Follow-up to #25556, as promised in https://github.com/OpenAPITools/openapi-generator/pull/25556#issuecomment-6648262065.

#25556 asked for the unit tests to stop depending on a local python3. #25579 (merged) did the Java side: it removed testJsonContentHeaderParamsGeneratedTestsCompile and re-enabled testInfoTitleEmbeddedAsPythonStringLiteral with Java-only assertions, so ./mvnw test no longer needs python3. Those Java assertions pin the generated text line by line; they cannot tell whether the result is valid Python or what the string literals evaluate to. This PR adds a GitHub workflow that checks exactly that, modelled on samples-python-fastapi-server.yaml.

What the workflow does

.github/workflows/samples-python-connexion-generated-code.yaml:

• builds the CLI (JDK 11, with the same ~/.m2/repository cache as openapi-generator.yaml) and sets up Python 3.11;
• generates two test specs that are already in the repository, 3_0/python/connexion-json-header-test-values.yaml and 3_0/python/info-title-special-chars.yaml, with each of python-flask, python-flask with useConnexion3=true, python-aiohttp and python-blueplanet (8 outputs);
• runs bin/utils/check-python-connexion-generated.py on each output. For every output the script:
  • compiles the generated test_default_controller.py, treating warnings such as invalid escape sequences as errors;
  • parses the generated setup.py with Python's ast, evaluates the keyword arguments of setup(), and compares three of them with the values the generator should produce from the spec: description (info.title), author_email (info.contact.email, or "" when absent) and long_description (info.description, or the generator's "No description provided …" text when absent);
  • reports every mismatch and exits with 1; a missing or ambiguous file is reported as a one-line error.

Unlike the other samples-python-* workflows, this one generates its inputs instead of checking committed samples: the two specs exist to exercise edge cases (JSON content header parameters; a title, description and contact email full of quotes, triple quotes, backslashes, &, <> and control characters), and committing eight more sample trees for them seemed heavier than generating them in CI.

It runs on push and pull_request when the Connexion generators, AbstractPythonCodegen or PythonStringUtils (which implement the escaping), their templates, the two specs, AbstractPythonConnexionServerCodegenTest, the script or the workflow itself change.

Verified

• On my fork, the workflow ran as written on GitHub Actions and passed: the CLI built, and all 8 outputs reported both checks as OK (https://github.com/khayashi4337/openapi-generator/actions/runs/43377586798).
• Locally (Python 3.14; all 8 outputs and the invalid-escape case also with Python 3.11), the script fails with exit code 1 for each of the following, and passes again once the file is restored:
  • a syntax error in a generated test;
  • an invalid escape sequence such as "\d" in a generated test;
  • a changed description in a generated setup.py;
  • a changed author_email in the setup.py generated from the spec without a contact email;
  • an empty output directory.
• actions/checkout@v7, actions/setup-java@v6, actions/setup-python@v7 and actions/cache@v6 match the versions used by the existing workflows.

No Java code, template or sample changes.

cc @wing328

PR checklist

• Read the contribution guidelines.
• Run the following to build the project and update samples — not applicable: this PR only adds a workflow and a helper script, so no sample or doc output changes. The CLI was built locally and on the fork's Actions run to exercise the workflow.

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. (The Python technical committee is not cc'd: this is CI-only and was requested by the maintainer in #25556.)

🤖 Generated with Claude Code

---

Summary by cubic

Adds a GitHub workflow that verifies generated Python Connexion server code stays valid and correct, after #25579 removed the unit tests' python3 dependency.

• Builds the CLI and generates the two existing Connexion test specs with python-flask (with and without useConnexion3=true), python-aiohttp, and python-blueplanet.
• Runs bin/utils/check-python-connexion-generated.py on each output, which compiles test_default_controller.py (warnings as errors) and evaluates setup.py's description, author_email, and long_description against the spec-derived values.
• Triggers on push/PR when the Connexion generators, AbstractPythonCodegen, PythonStringUtils, templates, the two specs, or the workflow itself change.

No Java, template, or sample changes.