-
Notifications
You must be signed in to change notification settings - Fork 14
DOP-5448: Integrate Bump GH action to generate spec pages #530
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
Changes from all commits
e8089e6
4912fa5
c4492f0
25341fa
6e66ccd
c560d8c
4ea7858
05fb6a5
6400e06
1b75b08
e7ff7a1
3a89f2b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,59 @@ | ||
| import fs from 'node:fs'; | ||
| import path from 'node:path'; | ||
| import { fileURLToPath } from 'node:url'; | ||
|
|
||
| const __filename = fileURLToPath(import.meta.url); | ||
| const __dirname = path.dirname(__filename); | ||
|
|
||
| // Standalone specs can be added directly to the mapping. Any spec that requires displaying a version dropdown | ||
| // will need to map its different versions to a separate Bump "branch". For example, a new resource version | ||
| // for Atlas Admin API v2 will lead to a new entry in the array with its own Bump branch. | ||
| const SPEC_MAPPING = [ | ||
| { | ||
| doc: process.env.ATLAS_ADMIN_V1_DOC_ID, | ||
| file: 'openapi/v1-deprecated/v1.json', | ||
| branch: 'main', | ||
| }, | ||
| ]; | ||
|
|
||
| function handleAdminAPIv2() { | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: can we please have unit tests? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (ok to add in a follow-up PR) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay, I can file a follow-up DOP ticket. Is there an ideal location within the repo to add this test? I didn't see a test directory for existing action scripts, but maybe I missed it 😅 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. good point! I am not sure, in our case, we have scripts but they call some of the tools we built under the tools folder, which is where we have the most logic, if you think you'll build more on top of this script you can look into https://github.com/mongodb/openapi/tree/main/tools/spectral/ipa and create a tool folder for |
||
| const docId = process.env.ATLAS_ADMIN_V2_DOC_ID; | ||
| const directory = 'openapi/v2'; | ||
| const filePath = path.join(__dirname, `../../${directory}/versions.json`); | ||
| const versions = JSON.parse(fs.readFileSync(filePath, 'utf8')); | ||
|
|
||
| if (!versions || !Array.isArray(versions)) { | ||
| console.error(`No versions found for Atlas Admin API v2 at ${filePath}`); | ||
| return; | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: add logs for troubleshooting in the future, if file changes and we fail to parse There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good call. Added |
||
| } | ||
|
|
||
| for (const [index, version] of versions.entries()) { | ||
| const openapiFilename = `openapi-${version}.json`; | ||
| const openapiFilePath = path.join(path.dirname(filePath), openapiFilename); | ||
|
|
||
| if (!fs.existsSync(openapiFilePath)) { | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: add logs if we find a version but not a file |
||
| console.error(`Could not find resource version "${version}" at ${openapiFilePath}`); | ||
| continue; | ||
| } | ||
|
|
||
| const file = `${directory}/${openapiFilename}`; | ||
| SPEC_MAPPING.push({ | ||
| doc: docId, | ||
| file, | ||
| branch: version, | ||
| }); | ||
|
|
||
| // We want the latest version to have its own version AND be the latest/default branch | ||
| if (index === versions.length - 1) { | ||
| SPEC_MAPPING.push({ | ||
| doc: docId, | ||
| file, | ||
| branch: 'latest', | ||
| }); | ||
| } | ||
| } | ||
| } | ||
|
|
||
| handleAdminAPIv2(); | ||
| // Output to GH action | ||
| console.log(JSON.stringify(SPEC_MAPPING)); | ||
rayangler marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,65 @@ | ||
| name: Check & deploy API documentation | ||
|
|
||
| on: | ||
| workflow_dispatch: # Allow manual trigger in case of quick fix | ||
|
|
||
| permissions: | ||
| contents: read | ||
|
|
||
| jobs: | ||
| create-matrix: | ||
| runs-on: ubuntu-latest | ||
| outputs: | ||
| matrix: ${{ steps.set-matrix.outputs.matrix }} | ||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v4 | ||
| - name: Setup Node | ||
| uses: actions/setup-node@v4 | ||
| - name: Generate matrix | ||
| id: set-matrix | ||
| env: | ||
| ATLAS_ADMIN_V1_DOC_ID: ${{ vars.ATLAS_ADMIN_V1_DOC_ID }} | ||
| ATLAS_ADMIN_V2_DOC_ID: ${{ vars.ATLAS_ADMIN_V2_DOC_ID }} | ||
| run: | | ||
| spec_mapping=$(node .github/scripts/generateSpecMapping.js) | ||
| echo "matrix=$spec_mapping" >> "$GITHUB_OUTPUT" | ||
|
|
||
| deploy-doc: | ||
| needs: create-matrix | ||
| if: ${{ github.event_name == 'push' || github.event_name == 'workflow_dispatch' }} | ||
| name: Deploy API documentation on Bump.sh | ||
| strategy: | ||
| matrix: | ||
| spec-mapping: ${{ fromJson(needs.create-matrix.outputs.matrix) }} | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 | ||
| - name: Deploy API documentation | ||
| uses: bump-sh/github-action@690c81156715f37cb72d006e5cbb81fbd9b45365 | ||
| with: | ||
| doc: ${{matrix.spec-mapping.doc}} | ||
| token: ${{secrets.BUMP_TOKEN}} | ||
| file: ${{matrix.spec-mapping.file}} | ||
| branch: ${{matrix.spec-mapping.branch}} | ||
|
|
||
| api-preview: | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what is the experience to access the preview spec on bump once the job is completed? I am wondering if we should add a step here to add a comment to the PR with the link to the spec There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right now, each matrix job will result in a separate preview link in the GH action logs (example). Would you like me to file a separate ticket to investigate the best way to comment on the PR (probably without spamming a comment for each one) or is this sufficient for now? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
SGTM. Feel free to introduce it in separate PR and spec out how to get access to preview urls. |
||
| needs: create-matrix | ||
| if: ${{ github.event_name == 'pull_request' }} | ||
| name: Create API preview on Bump.sh | ||
| strategy: | ||
| matrix: | ||
| spec-mapping: ${{ fromJSON(needs.create-matrix.outputs.matrix) }} | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 | ||
| - name: Create API preview | ||
| uses: bump-sh/github-action@690c81156715f37cb72d006e5cbb81fbd9b45365 | ||
| with: | ||
| doc: ${{matrix.spec-mapping.doc}} | ||
| token: ${{secrets.BUMP_TOKEN}} | ||
| file: ${{matrix.spec-mapping.file}} | ||
| branch: ${{matrix.spec-mapping.branch}} | ||
| command: preview | ||
Uh oh!
There was an error while loading. Please reload this page.
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.
Can we document how this array will grow over time?
I'm trying to establish how many matrix jobs this PR will render after we merge and how this will grow over time. Short explanation would do the job
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.
I updated the comment to be more explicit, but let me know if you need that written out elsewhere or if you need a better explanation!
Right now, it'll create a separate job for each major spec version of the Atlas Admin API, and for each resource version. Docs currently supports 1-2 more additional public OpenAPI specs, which means we may add them to this repo, leading to more jobs, but I wasn't sure if this repo is intended for all OpenAPI specs, or if the preference is to only have this repo be for Atlas Admin API exclusively.
If the number of jobs becomes a concern, what we could potentially do is explore creating a custom action that can accept the entire array as a single input and bulk deploy/preview everything instead of relying on Bump's action that only accepts 1 at a time.
Uh oh!
There was an error while loading. Please reload this page.
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.
SGTM. It is not about how many jobs but how many minutes are used.
I see that in current scenario this new job will use less than 10 minutes of run time monthly which seems fine.