docs: fix README paths (module→modules), unify dev commands, and clar…#104
docs: fix README paths (module→modules), unify dev commands, and clar…#104pangfufuf wants to merge 1 commit intokubeedge:mainfrom
Conversation
…ify login token/env-var notes Signed-off-by: pangfufuf <2972795272@qq.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Summary of ChangesHello @pangfufuf, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request focuses on enhancing the clarity and accuracy of the project's README documentation. It addresses outdated file paths, unifies development startup commands for frontend modules, and refines the instructions for Kubernetes token retrieval based on version, aiming to improve the onboarding experience for new contributors without introducing any code changes. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request improves the documentation in README.md by correcting directory paths, unifying development startup commands, and clarifying the token retrieval process for different Kubernetes versions. My review focuses on ensuring the instructions are clear, accurate, and complete based on the PR's stated goals. I've identified a few areas for improvement. The frontend development instructions include a redundant build step which could be confusing. Also, the PR description mentions adding a PowerShell example and security notes about tokens, but these changes appear to be missing. Overall, these are great improvements to the documentation that will enhance the developer onboarding experience. Addressing the points above will make it even better.
| API_SERVER=http://127.0.0.1:8080 pnpm run dev | ||
| ``` | ||
|
|
||
| ### Login with token |
There was a problem hiding this comment.
The pull request description mentions adding notes on token expiry and the importance of least-privilege RBAC for production environments. These notes seem to be missing. Adding them would provide valuable security context for users.
For example, you could add a note that the cluster-admin role used in the example is for demonstration purposes only and a more restrictive, least-privilege role should be created for production use. You could also mention that tokens generated with kubectl create token are short-lived by default.
| npm run build | ||
| API_SERVER={api module address} npm run start | ||
| Example: API_SERVER=http://127.0.0.1:8080 npm run dev | ||
| API_SERVER=http://127.0.0.1:8080 npm run dev |
There was a problem hiding this comment.
The npm run build command is typically used for creating a production build, which is then served using npm run start. The npm run dev command is for development and doesn't require a separate build step, as it compiles and serves assets on the fly. Including npm run build here could be confusing for developers.
For a development setup, you should only need to run the dev script. If you want to document both development and production startup, it would be clearer to separate them.
For example:
Development
API_SERVER=http://127.0.0.1:8080 npm run devProduction
npm run build
API_SERVER=http://127.0.0.1:8080 npm run startThis comment also applies to the yarn and pnpm instructions.
| npm run build | |
| API_SERVER={api module address} npm run start | |
| Example: API_SERVER=http://127.0.0.1:8080 npm run dev | |
| API_SERVER=http://127.0.0.1:8080 npm run dev | |
| API_SERVER=http://127.0.0.1:8080 npm run dev |
| @@ -65,26 +65,23 @@ If your API server is running with self-signed certificate, you can set `--apise | |||
| ### Frontend | |||
There was a problem hiding this comment.
/kind documentation
What this PR does / why we need it:
Fix incorrect paths module/... → modules/... (backend: modules/api, frontend: modules/web)
Normalize startup examples to ... run dev and provide npm/yarn/pnpm variants
Add Windows PowerShell example for setting API_SERVER
Clarify login flow by Kubernetes version:
1.24+ → kubectl create token
1.23- → read token from Secret
Add notes on token expiry and least-privilege RBAC for production
Minor wording & formatting polish for readability
Which issue(s) this PR fixes:
NONE
Special notes for your reviewer:
Focused on docs accuracy and onboarding experience; no code changes.
Does this PR introduce a user-facing change?:
Documentation: fix README paths, unify dev commands, clarify token retrieval by Kubernetes version, and add PowerShell example.