Beyond source code, a generator can write CI configuration, a git push helper, build files and a metadata folder. Review every extra file before you publish an SDK. Keep what you understand, delete what you do not use, and make sure none of it carries stale settings or credentials into a public repository.
What the docs say it can emit
The workflow integration page describes a few of these:
- A git push helper script, git_push.sh, to streamline pushing an auto generated SDK to GitHub. The example passes a git user id, a repository id and a release note to the generator, then you run the script from the output directory.
- Some generators also write CI configuration files, with a Travis configuration given as the example, so the output is ready to be tested by that CI.
The post processing page's log output also shows the generator writing a .openapi-generator folder with VERSION and FILES entries, along with spec and test helper files for Ruby.
Why extras deserve a look
| Extra file | Concern |
|---|---|
| CI configuration | May name a service you do not use, or an old runner image, or run steps with broad permissions |
| Push script | Pushes whatever is in the directory, including local files you did not mean to share |
| Build and manifest files | Declare dependencies and repository sources |
| Test and spec scaffolding | May pull in test dependencies |
| Metadata folder | Harmless, and useful for tracing the tool version |
| README and docs | May include sample values, URLs or wording you do not want to publish |
A pre-publish routine
- List everything in the output directory and mark each file as keep, change or delete.
- Delete CI files for services you do not use. Replace the rest with your own pipeline definition, which has pinned actions and minimal permissions.
- Read the push script before running it. Check the target remote, the branch and what it adds. Run it from a clean directory so local stray files are not included.
- Look at the build file for dependency versions and any repository URLs. Make sure they point at your approved registries.
- Search the tree for anything that looks like a credential, an internal host name or a test token. Generated examples sometimes copy values from the spec.
- Check licence information in the package metadata. Your own licence should be stated correctly.
- Run dependency scanning on the final tree, not on the spec.
Keep a record
Commit the metadata folder, and note in the release the generator version and the spec version used. That lets a customer, or you, trace an SDK build back to its inputs. For a customer facing view of the same idea, see how to ask a vendor for an SBOM.
Where Safeguard fits
Safeguard produces an SBOM for the final SDK tree, and policy gates can hold a release pull request until dependency findings are resolved.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the component list a final SDK tree would produce.
Quick check
Does every generator write CI files?
No. The docs say some generators do. Check the output of the one you use.
Can I just run the push script as is?
You can, but read it first and run it from a clean output directory, since it pushes what is there.
Sources
Last reviewed: 19 October 2026.
