-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat: API collector automation #1
Conversation
DEPENDENCIES on the way, just awaiting approval of submitted review: https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/14664 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good to me, so I'm fine with merging.
One questions though:
The assumption seems to be, that openAPI Specs will be stored as release artifact. AFAIK, we are writing a TRG to put that file to the /docs
folder. Do we need to clarify/enhance that
src/api-collector/main.go
Outdated
|
||
func getAPISpecAssets(ctx context.Context, client *github.Client, owner string, repo string) []assetInfo { | ||
var apiSpecs []assetInfo | ||
release, _, err := client.Repositories.GetLatestRelease(ctx, owner, repo) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what if as an alternative way to get the documentation, the url for a published openapi yaml file could be specified an url in the .tractusx
file?
it will make this process more flexible, because the yaml could then be published either:
- in the releases file (it can be referenced with a url like:
https://github.com/eclipse-tractusx/<project-name>/releases/latest/download/openapi.yaml
) - on github pages
- kept in the repository in the
docs
folder
it will be up to the single project to decide where to store it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @ndr-brt, thanks for your suggestion! I think I like the flexibility it gives to devs..
@SebastianBezold, @ndr-brt I adapted the code to use .tractusx metadata for API specs urls, feel free to review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me 👍
PR is introducting a subcomponent of automation responsible for collecting OpenAPI specs across organization (currently default to Tractus-X) following specific naming convention productname_openapi.{yml, yaml} and storing it within api-hub repository under docs folder. Downloaded assets will be used by workflow to generate Swagger UI and published at GitHub Pages for easy access.
Updates eclipse-tractusx/sig-infra#376
Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review: