EDM-1497: Update API types for Application volumes and Events#308
Conversation
|
""" WalkthroughThe changes introduce new type definitions and enums related to application and image volumes, and update several existing types to support volume specifications and statuses. Types are extended or intersected to include volume-related properties, and new exports are added to the central types index. Some files receive only documentation or comment updates. Additionally, new event reasons and corresponding translations for device lifecycle and status notifications are added. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UI
participant Types
participant API
User->>UI: Edit or create application/device spec
UI->>Types: Use ApplicationProviderSpecFixed (now includes volume provider spec)
UI->>API: Submit application/device spec (with volume info)
API->>Types: Reference ApplicationVolume*, ImageVolume* types for validation/status
API-->>UI: Respond with DeviceApplicationStatus (now includes volumes status)
Suggested reviewers
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
npm error Exit handler never called! 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (15)
🚧 Files skipped from review as they are similar to previous changes (15)
⏰ Context from checks skipped due to timeout of 90000ms (4)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
libs/types/models/ApplicationVolumeStatus.ts (1)
8-13: Consider if additional status fields will be needed.The
ApplicationVolumeStatustype currently only includes anamefield. For a status type, you might want to consider if additional fields will be needed such as:
- Volume state/phase (e.g., "pending", "bound", "available")
- Error messages for failed volumes
- Capacity information
- Mount status
Since this is auto-generated code, any additions would need to be made in the OpenAPI specification.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
libs/types/index.ts(2 hunks)libs/types/models/ApplicationVolume.ts(1 hunks)libs/types/models/ApplicationVolumeProviderSpec.ts(1 hunks)libs/types/models/ApplicationVolumeStatus.ts(1 hunks)libs/types/models/DeviceApplicationStatus.ts(2 hunks)libs/types/models/ImageApplicationProviderSpec.ts(1 hunks)libs/types/models/ImagePullPolicy.ts(1 hunks)libs/types/models/ImageVolumeProviderSpec.ts(1 hunks)libs/types/models/ImageVolumeSource.ts(1 hunks)libs/types/models/InlineApplicationProviderSpec.ts(1 hunks)libs/ui-components/src/components/Device/EditDeviceWizard/deviceSpecUtils.ts(1 hunks)libs/ui-components/src/types/extraTypes.ts(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (7)
libs/types/models/ApplicationVolumeProviderSpec.ts (1)
libs/types/models/ApplicationVolume.ts (1)
ApplicationVolume(6-11)
libs/types/models/ImageApplicationProviderSpec.ts (1)
libs/types/models/ApplicationVolumeProviderSpec.ts (1)
ApplicationVolumeProviderSpec(6-11)
libs/types/models/ApplicationVolume.ts (2)
libs/types/index.ts (2)
ApplicationVolume(12-12)ImageVolumeProviderSpec(95-95)libs/types/models/ImageVolumeProviderSpec.ts (1)
ImageVolumeProviderSpec(6-12)
libs/ui-components/src/types/extraTypes.ts (2)
libs/types/models/ApplicationVolumeProviderSpec.ts (1)
ApplicationVolumeProviderSpec(6-11)libs/types/models/ImageApplicationProviderSpec.ts (1)
ImageApplicationProviderSpec(6-11)
libs/types/models/InlineApplicationProviderSpec.ts (2)
libs/types/models/ApplicationVolumeProviderSpec.ts (1)
ApplicationVolumeProviderSpec(6-11)libs/types/models/ApplicationContent.ts (1)
ApplicationContent(7-7)
libs/types/models/ImageVolumeProviderSpec.ts (2)
libs/types/index.ts (2)
ImageVolumeProviderSpec(95-95)ImageVolumeSource(96-96)libs/types/models/ImageVolumeSource.ts (1)
ImageVolumeSource(9-15)
libs/types/models/DeviceApplicationStatus.ts (1)
libs/types/models/ApplicationVolumeStatus.ts (1)
ApplicationVolumeStatus(8-13)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: integration-tests
🔇 Additional comments (14)
libs/types/models/DeviceApplicationStatus.ts (2)
6-6: LGTM! Clean import addition.The import statement is correctly added to support the new volumes property.
21-24: LGTM! Well-designed optional property.The addition of the optional
volumesproperty is well-implemented:
- Uses optional syntax for backward compatibility
- Proper TypeScript array typing
- Clear documentation comments
libs/types/models/ApplicationVolumeProviderSpec.ts (1)
5-11: LGTM! Well-structured provider spec type.The
ApplicationVolumeProviderSpectype is well-implemented:
- Proper import of the
ApplicationVolumedependency- Optional array property for backward compatibility
- Clear documentation
- Follows the established pattern for provider specifications
The type correctly references
ApplicationVolumewhich extendsImageVolumeProviderSpec(as shown in the relevant code snippets), maintaining a clean type hierarchy.libs/types/models/ApplicationVolume.ts (1)
6-11: LGTM! Well-structured type definition.The
ApplicationVolumetype correctly uses intersection to extendImageVolumeProviderSpecwith an optionalnameproperty. The type design provides flexibility for volume naming while inheriting all image volume provider capabilities.libs/types/models/ImageVolumeProviderSpec.ts (1)
6-12: LGTM! Clear and well-documented type definition.The
ImageVolumeProviderSpectype is properly structured with requiredimageandnameproperties. The JSDoc comment clearly explains the purpose of thenamefield, and the type design appropriately models a volume populated by image contents.libs/types/models/ImageVolumeSource.ts (1)
6-15: LGTM! Excellent type definition with comprehensive documentation.The
ImageVolumeSourcetype is well-designed with clear documentation explaining OCI compliance requirements. The combination of requiredreferenceand optionalpullPolicyprovides the right balance of mandatory and flexible configuration options for image sources.libs/types/models/ImageApplicationProviderSpec.ts (1)
5-11: LGTM! Proper integration of volume capabilities.The modification correctly extends
ImageApplicationProviderSpecby intersecting withApplicationVolumeProviderSpec, which adds volume support while preserving the existingimageproperty. This change aligns perfectly with the PR objectives to integrate application volumes into provider specifications.libs/types/models/ImagePullPolicy.ts (1)
8-12: LGTM! Well-structured enum definition.The
ImagePullPolicyenum follows standard Kubernetes conventions with clear documentation. The three values (Always,IfNotPresent,Never) align with expected image pull behaviors, and the JSDoc comment properly explains the default policy and each option's behavior.libs/types/models/InlineApplicationProviderSpec.ts (2)
6-6: Proper import addition for type extension.The import of
ApplicationVolumeProviderSpecis correctly added to support the intersection type definition.
7-12:Details
✅ Verification successful
LGTM! Clean intersection type extension.
The change from a simple object type to an intersection type that combines
ApplicationVolumeProviderSpecwith the existing inline content specification is well-designed. This approach:
- Maintains backward compatibility for existing
inlineusage- Adds volume support through the intersection with
ApplicationVolumeProviderSpec- Follows the consistent pattern used in other provider specs
Verify that existing usage of
InlineApplicationProviderSpecacross the codebase continues to work with this intersection type:
🏁 Script executed:
#!/bin/bash # Description: Check usage of InlineApplicationProviderSpec to ensure compatibility with intersection type change # Search for usages of InlineApplicationProviderSpec rg -A 5 "InlineApplicationProviderSpec" --type ts # Look for any type assertions or casts that might be affected rg -A 3 "as InlineApplicationProviderSpec|<InlineApplicationProviderSpec>" --type tsLength of output: 4372
✅ InlineApplicationProviderSpec usage verified
I searched the codebase for all references to
InlineApplicationProviderSpecand confirmed:
- References in
•libs/ui-components/src/types/deviceSpec.ts
•libs/ui-components/src/components/Device/EditDeviceWizard/deviceSpecUtils.ts
•libs/types/index.ts
•libs/types/models/ApplicationProviderSpec.ts- No type assertions or casts (
as InlineApplicationProviderSpecor<InlineApplicationProviderSpec>) were found.The intersection change maintains full compatibility with existing usages. LGTM!
libs/ui-components/src/types/extraTypes.ts (2)
4-4: Proper import addition.The import of
ApplicationVolumeProviderSpecis correctly added to support the extended type definition.
71-75: LGTM! Consistent type extension for volume support.The extension of
ApplicationProviderSpecFixedto includeApplicationVolumeProviderSpecin the intersection is well-implemented. This change:
- Maintains all existing properties (
ApplicationEnvVars,name,appType)- Adds volume support through
ApplicationVolumeProviderSpec- Preserves the union with
ImageApplicationProviderSpecor inline files- Follows the consistent pattern used across other provider spec types
The intersection type approach ensures backward compatibility while adding the new volume functionality.
libs/types/index.ts (2)
12-14: LGTM! Properly added application volume type exports.The new exports for
ApplicationVolume,ApplicationVolumeProviderSpec, andApplicationVolumeStatusare correctly added with properexport typesyntax and maintain alphabetical ordering.
94-96:Details
✅ Verification successful
LGTM! Correctly added image volume exports.
The exports for
ImagePullPolicy(enum),ImageVolumeProviderSpec, andImageVolumeSourceare properly structured:
ImagePullPolicycorrectly usesexport(notexport type) since it's an enum- Type exports use appropriate
export typesyntax- Maintains alphabetical ordering within the section
Verify that all newly exported types have corresponding implementation files:
🏁 Script executed:
#!/bin/bash # Description: Verify that all newly exported volume-related types have corresponding model files # Check for the existence of model files for new exports echo "Checking for model files..." for type in "ApplicationVolume" "ApplicationVolumeProviderSpec" "ApplicationVolumeStatus" "ImagePullPolicy" "ImageVolumeProviderSpec" "ImageVolumeSource"; do if [ -f "libs/types/models/${type}.ts" ]; then echo "✓ ${type}.ts exists" else echo "✗ ${type}.ts missing" fi doneLength of output: 1792
✅ All new exports verified and correctly implemented
- Confirmed that the following model files exist under
libs/types/models:
ImagePullPolicy.tsImageVolumeProviderSpec.tsImageVolumeSource.ts- Export syntax (
exportfor enum,export typefor types) and alphabetical ordering are correct.LGTM!
celdrake
force-pushed
the
EDM-1497-api-types-for-application-volumes
branch
from
62dc126 to
4248f46
Compare
celdrake
force-pushed
the
EDM-1497-api-types-for-application-volumes
branch
4 times, most recently
from
1b14c05 to
285d257
Compare
celdrake
changed the title
celdrake
force-pushed
the
EDM-1497-api-types-for-application-volumes
branch
from
285d257 to
800ff64
Compare
2 participants
Summary by CodeRabbit