chore: update api client job #54
Conversation
| @@ -17,8 +17,6 @@ jobs: | |||
| run: sudo apt-get install jq | |||
| - name: Fetch OpenAPI doc | |||
| run: ./scripts/fetch_api.sh ${{ github.event.client_payload.download_url }} | |||
| - name: Generate SDKs | |||
There was a problem hiding this comment.
Generation on the PR makes no sense for js-sdk as we do not have testing and validation done yet.
We have examples that can are used for testing (typescript compilation) but they have just some limited API.
Created issue: #55
There was a problem hiding this comment.
Could we have it like this:
- Jobs creates PR adding the new OAS
- Perform manual changes if needed and merge
- On merge to main - kick off the generation job and create another PR
There was a problem hiding this comment.
Thinking how this will work
Do you have nice way wow we could differentiate any merge to main from PR by bot PR and normal PR?
There was a problem hiding this comment.
If the author is app-services-ci ?
There was a problem hiding this comment.
Or we can have single job that checks if PR has label and if label is applied then generation happens.
This can be replicated across different SDKs :)
Sounds amazing as it resolves couple problems:
- you can review openapi changes
- you can edit it if needed
- you can generate all things the right time
- No need to have any local development if builds are passing and examples work
There was a problem hiding this comment.
Label: bot:generate
Developer applies label if he wish to add changes to PR
Job can start that check if label exist and generate all APIs
|
Need to test if that log description will be created |
|
I have idea - we can simply keep patches to API files and add them automatically and then regenerate. That will reduce number of steps. We can try this once #53 is done |
Add more info to the PR that will contain instructions how to make SDK released for everyone.
As we see there is quite set of manual steps right now but this can be automated further later on.