refactor: remove fixed LimitRange enforcement from form data processing#1519
refactor: remove fixed LimitRange enforcement from form data processing#1519KUASWoodyLIN wants to merge 1 commit intomainfrom
Conversation
Summary of ChangesHello @KUASWoodyLIN, 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 refactoring streamlines the workspace creation process by removing a static, hardcoded constraint on resource allocation. By no longer enforcing a fixed Highlights
Changelog
Activity
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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the workspace creation form by removing a hardcoded LimitRange enforcement from the transformFormData function. This is a positive change as it removes a magic value override and makes the component's behavior more predictable. The limitRange from the initialData object will now be correctly used, centralizing the default configuration and improving maintainability. The change is clean and aligns with the stated goal.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Pull request overview
Removes the submit-time overwrite that forced a hard-coded spec.limitRange during workspace creation, so the manifest uses whatever LimitRange is already present in the form data.
Changes:
- Deleted the
transformFormDatalogic that overwrotespec.limitRangewith fixed CPU/memory defaults. - Workspace creation now retains
spec.limitRangefrominitialData/ form state rather than enforcing a constant at submit time.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Handle Resource Quota Logic: limits align with requests, strict defaults | ||
| if (spec?.resourceQuota?.hard) { | ||
| const hard = spec.resourceQuota.hard; | ||
| // Sync limits with requests | ||
| if (hard['requests.cpu']) hard['limits.cpu'] = hard['requests.cpu']; | ||
| if (hard['requests.memory']) hard['limits.memory'] = hard['requests.memory']; | ||
| } | ||
|
|
||
| // Enforce fixed LimitRange | ||
| if (spec) { | ||
| spec.limitRange = { | ||
| limits: [ | ||
| { | ||
| type: 'Container', | ||
| default: { | ||
| cpu: '500m', | ||
| memory: '512Mi' | ||
| }, | ||
| defaultRequest: { | ||
| cpu: '500m', | ||
| memory: '512Mi' | ||
| } | ||
| } | ||
| ] | ||
| }; | ||
| } | ||
|
|
||
| return data; |
There was a problem hiding this comment.
Removing the spec.limitRange overwrite changes the effective LimitRange defaults for newly created workspaces from the previously-enforced 500m/512Mi to whatever is in initialData.spec.limitRange (currently cpu: '1', memory: '2Gi'). If the 500m/512Mi values are still the intended defaults, update initialData accordingly; otherwise, consider making this default change explicit (e.g., via PR description/changelog) since it affects resource behavior in the cluster.
No description provided.