Motivation
When users configure bind mounts for their applications, they need to be aware of important constraints and potential pitfalls. Bind mounts require that the specified host path exists on the machine, and in cluster environments, this path must exist on all nodes. Without proper guidance, users may encounter confusing deployment failures that are difficult to debug.
Providing clear, contextual warnings at the point of configuration improves the user experience by preventing common mistakes and helping users make informed decisions about their volume configuration strategy. This is especially critical for users working with cluster deployments who may not realize that bind mounts can cause issues across distributed nodes.
Current Behavior
The AddVolumes component allows users to select between different volume types (including bind mounts) but does not provide any warnings or guidance about the implications of using bind mounts. Users can configure bind mounts without being informed about:
- The requirement that host paths must exist and be valid
- The potential for deployment failures in cluster environments
- Alternative approaches like named volumes
Reproduction Steps:
- Navigate to an application's advanced settings in the dashboard
- Open the volumes configuration section
- Click to add a new volume
- Select "bind" as the volume type from the dropdown
- Observe: No warning or informational message appears to guide the user about bind mount requirements
Expected Behavior
When a user selects "bind" as the volume type, an alert block should appear providing clear warnings about bind mount usage. The alert should inform users about host path validation requirements and warn about potential cluster deployment issues, suggesting alternatives when appropriate.
Acceptance Criteria:
Verification
Manual Testing:
- Start the Dokploy application in development mode
- Navigate to any application's advanced settings → volumes section
- Click to add a new volume
- Select "bind" from the type dropdown and verify the alert appears with appropriate warnings
- Switch to a different volume type (e.g., "volume") and verify the alert disappears
- Switch back to "bind" and confirm the alert reappears
- Verify the alert text is clear, properly formatted, and includes both the general warning and cluster-specific guidance
Expected Results:
- Alert is conditionally rendered based on volume type selection
- Warning text is readable and provides actionable guidance
- Component behavior is consistent across type changes
Submission
Download https://cap.so/ to record your screen (use Studio mode). Export as an mp4, and drag and drop into an issue comment below.
Guide to submitting pull requests: https://hackmd.io/@timothy1ee/Hky8kV3hlx
Motivation
When users configure bind mounts for their applications, they need to be aware of important constraints and potential pitfalls. Bind mounts require that the specified host path exists on the machine, and in cluster environments, this path must exist on all nodes. Without proper guidance, users may encounter confusing deployment failures that are difficult to debug.
Providing clear, contextual warnings at the point of configuration improves the user experience by preventing common mistakes and helping users make informed decisions about their volume configuration strategy. This is especially critical for users working with cluster deployments who may not realize that bind mounts can cause issues across distributed nodes.
Current Behavior
The AddVolumes component allows users to select between different volume types (including bind mounts) but does not provide any warnings or guidance about the implications of using bind mounts. Users can configure bind mounts without being informed about:
Reproduction Steps:
Expected Behavior
When a user selects "bind" as the volume type, an alert block should appear providing clear warnings about bind mount usage. The alert should inform users about host path validation requirements and warn about potential cluster deployment issues, suggesting alternatives when appropriate.
Acceptance Criteria:
Verification
Manual Testing:
Expected Results:
Submission
Download https://cap.so/ to record your screen (use Studio mode). Export as an mp4, and drag and drop into an issue comment below.
Guide to submitting pull requests: https://hackmd.io/@timothy1ee/Hky8kV3hlx