-
Notifications
You must be signed in to change notification settings - Fork 22
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
[IA-4137] Add types to desired and existing runtime config #5079
base: dev
Are you sure you want to change the base?
Conversation
src/analysis/modal-utils.ts
Outdated
}; | ||
|
||
// Auxiliary functions -- begin | ||
export const isGce = (runtimeType) => runtimeType === runtimeTypes.gceVm; |
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.
these three isXxxx functions could be ijmproved to be type predicates that return "is TypeX... But from our chat, I assume that will have to wait until we do a 2nd wave of type love.
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.
yeah, since that will require nesting them in an additional field and thus functionally changing the modal itself, which I was able to avoid in this PR
src/analysis/modal-utils.ts
Outdated
// extract desiredruntimeconfig into a type | ||
// TODO: converge type with getExistingEnvironmentConfig | ||
// TODO: type desired runtimetype | ||
export const buildDesiredEnvironmentConfig = ( |
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.
if these util methods are only used by GcpComputeModal, maybe we can avoid adding them to the generic modal-utils file here and add them to a more specific helper file next to the only modal using it.
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.
Yeah, I agree, this file needs a better name because these two methods (and the smaller helpers) are the main use case for it.
src/analysis/modal-utils.ts
Outdated
autopauseThreshold: currentRuntimeDetails?.autopauseThreshold, | ||
computeConfig, |
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.
Should these two be typed as well?
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.
...(cloudService === cloudServices.GCE | ||
? { | ||
zone: computeConfig.computeZone, | ||
region: computeConfig.computeRegion, |
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.
So no need of the region anymore? Only the zone was used?
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.
the region was duplicated on line 69 and 82 in both branches of the conditional, I simplified by moving it up to here https://github.com/DataBiosphere/terra-ui/pull/5079/files#diff-32a05189ab14623d039151b28dfee24908fc62cad51bf92afdb7767afbf7ef01R128
src/analysis/modal-utils.ts
Outdated
return { | ||
hasGpu: computeConfig.hasGpu, | ||
autopauseThreshold: computeConfig.autopauseThreshold, | ||
computeConfig, |
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.
Same question here about typing these?
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.
...(currentRuntimeDetails?.timeoutInMinutes | ||
? { | ||
timeoutInMinutes: currentRuntimeDetails?.timeoutInMinutes, | ||
} |
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.
is the timeout not needed here anymore?
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.
no, it is never used off the existing runtime config object
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.
Instead of removing this, it'd be better to fix the bug where this isn't used, and loading a runtime with a custom timeout does not display the correct value - GcpComputeModal line 236 has const [timeoutInMinutes, setTimeoutInMinutes] = useState(null);
- this could change to useState(currentRuntime?.timeoutInMinutes || null
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.
or at least leaving a comment on that line with the needed change
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 isn't actually a field on existing runtimes! I think the types demonstrate well that this is a field for desired
runtime that we submit in the request, but it is not something leo returns back on existing
.
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'll add a comment on the type
@@ -153,6 +153,8 @@ export const zonesToGpus = [ | |||
{ name: 'US-WEST4-C', validTypes: [] }, | |||
]; | |||
|
|||
// **Deprecated** | |||
// Use cloudServiceTypes in `runtime-config-models` |
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.
since this is deprecated, can we just ✂️ ?
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.
Not without changing the logic... the TODO on line 135 of modal-utils is necessary before. Currently, we use this instead of the runtimeTypes
in a lot of conditional logic. Hopefully if there is time for a second phase of this it can be deleted, but more testing is needed first.
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.
Are you able to add some tests of the new logic that builds the existing runtime config/the desired runtime config from the existing runtime config?
6fac7be
to
7fd7634
Compare
it took a lot of lines to test it.. def was a good idea |
thank you, the tests look great! |
const selectOption = await screen.findByText('2'); | ||
await user.click(selectOption); | ||
const nextButton = await screen.findByText('Next'); | ||
await user.click(nextButton); |
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.
There was actually a bug that these tests relied on to pass that was fixed.
Essentially, the canUpdateRuntime
function compares existing and desired configs and if it finds a difference say 'yes you can update'. The toolLabel
in the desired config was incorrectly computed, and was undefined, which signaled to the modal an update was allowed (hence update button Enabled
). The test on line 369 now correctly reads update should be disabled when no changes have been made, and this subsequent test actually requires a field to be changed (CPUs) for Update
to be enabled.
Quality Gate passedIssues Measures |
No description provided.