fix: [PL-56199]: support Open API yaml URL with Github API #34
Conversation
|
|
packages/cli/src/helpers.mts
Outdated
| @@ -10,6 +10,14 @@ import { has } from 'lodash-es'; | |||
|
|
|||
| const DIR_NAME = getDirNameForCurrentFile(import.meta); | |||
|
|
|||
| // helpers when when working with url to generate service | |||
| const DEFAULT_BRANCH = 'develop'; | |||
There was a problem hiding this comment.
There are times when we need to generate from feature branches and deploy to PR env.
We should handle that use case too.
Possibly, take branch as input via env variable?
| const DEFAULT_BRANCH = 'develop'; | |
| const DEFAULT_BRANCH = process.env.GITHUB_BRANCH || 'develop'; |
There was a problem hiding this comment.
done and tested this with a new branch and passing branch name in env variable
| @@ -0,0 +1,4 @@ | |||
| GITHUB_PAT=GITHUB_PAT | |||
There was a problem hiding this comment.
can we avoid hardcoded design dependency on Github?
considering that we have most of our repos moving to Harness Code now, we should support querying harness0.harness.io with the Harness PAT as well.
a simpler, more generic design would be to just take a complete url as a param, instead of taking org + repo + branch and constructing github urls via "magic".
| @@ -53,3 +64,15 @@ export function getDirNameForCurrentFile(meta: ImportMeta): string { | |||
| export function pathToTemplate(val: string): string { | |||
| return val.replace(/\{/g, '${'); | |||
| } | |||
|
|
|||
| export function b64DecodeUnicode(str: any) { | |||
There was a problem hiding this comment.
is there a way to avoid the need for this decoder? few concerns:
- it's very specific to github it seems
- it looks like magic code.. why is it doing what it's doing?
There was a problem hiding this comment.
Github API returns bas64 encoded content, hence need to decode the content.
Summary
Since our harness core repo was converted into private repository, we had to manually create a yaml file in https://github.com/harness/react-api-client repo and add the openApi yaml content for respective service to generate swagger.
With this we are enabling back generation of services using url ("openApi file path" would be better choice of words).
To achieve this user will require
Here is an attached video, where we are trying to generate idp-service swagger
https://drive.google.com/file/d/1lFrfwnAq-H3fFVPVj0ld_LtyUSH9WSFL/view?usp=sharing
Screenshots
NA
Contributor license agreement