-
Notifications
You must be signed in to change notification settings - Fork 25
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
Add SDK Typedoc Implementation for v3 Client #701
Conversation
- restructure configurations to for monorepo/workspace mode - add individual tsconfig.json and typedoc.json config files - add base tsconfig.base.json and typedoc.base.json to hold common configurations - specify namespaces for each module or packages - update github actions workflow file to script Version Package PRs
|
- remove the files configuration
- remove the files configuration
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #701 +/- ##
=======================================
Coverage 92.83% 92.83%
=======================================
Files 25 25
Lines 279 279
Branches 12 12
=======================================
Hits 259 259
Misses 20 20
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
- update docs.yml workflow file
- update docs.yml workflow file
- update docs.yml workflow file
- update docs.yml workflow file
- update docs.yml workflow file
@@ -1,15 +1,14 @@ | |||
name: SDK Type Docs Specification | |||
on: | |||
push: |
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 you explain why you removed this part? Will it now be deployed on every PR?
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.
This was remove because of double deployment, as it will be deployed both for all PRs and also when the PR is merged which I don't think is necessary.
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.
And it will be available in GH pages? How will it ensure that PR won‘t overwrite the current docs on master if there is only 1 URL for the GH pages?
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 am not sure I understand, but how it works is that any changes made through a PR will build a new version of the docs and deploy it to gh-pages. This is to ensure that whatever modification is made to the SDK will automatically be updated in the docs.
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.
And also, there is no docs in the master, all the docs are built and deployed to gh-pages during PR builds.
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.
But then if the docs changes in PR is deployed to the gh-pages, the docs will be available to the users, but they will not see the correct classes in the sdk because the PR is not merged to master?
This doesn't matter, it is not as if the PR will take forever before it is merged. I think the time between raising the PR and getting it merged is relatively short to worry about this scenario.
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.
Well that is not how the official docs work, if we have to look at it this way, the javadoc doesn't show any deployment in the PR to see how the docs looks like, I don't think we should go with that approach.
The official docs gives you a preview link which can be inspected to see the changes before the PR is merged, I think this is a better approach than the javadocs implementation.
I agree, so this GH pages link is for a preview only?
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.
Well that is not how the official docs work, if we have to look at it this way, the javadoc doesn't show any deployment in the PR to see how the docs looks like, I don't think we should go with that approach.
The official docs gives you a preview link which can be inspected to see the changes before the PR is merged, I think this is a better approach than the javadocs implementation.I agree, so this GH pages link is for a preview only?
No, it's not only for previews, it's also the live gh-pages link. I can change the trigger to merge or release only, but doing this, we will lose our ability to see the updated docs before merging the PR (no preview deployment link) which was something I thought about before going with the PR trigger approach.
But if you still think we should deploy it on merge or release, then we can talk to the team about it to see which approach is more favourable.
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.
Let‘s discuss it in the tooling weekly 👍
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 think you mixed up the docs website with the ones for the SDK. The docs website publishes a preview for every PR using vercel. This is not the case for the SDK docs.
In the Java Repo we built the docs only for the main branch to see that it's not broken, but there is no deployment happening.
Deploy to the the GH pages happens only after a tag has been made or the build was triggered manually. This should be sufficient as the docs are mainly auto generated. Only manually written docs are sometimes built locally to check the look.
Co-authored-by: Jens Schulze <[email protected]>
- update doc.yml workflow file - update workflows to use repository dispatch
Summary
Add SDK Typedoc Implementation for v3 Client
Completed Tasks