Repository navigation
chore(sync): integrate Dokploy canary through 5df820a - #38
Conversation
- Added components for handling and displaying Docker networks, including creation, editing, and listing of networks. - Introduced a new API router for network operations, integrating with the database schema for network management. - Updated the sidebar layout to include a link to the networks dashboard, ensuring user access to network features. - Created necessary database migrations for the network table and its associated types. - Enhanced the dashboard layout to support the new network management interface.
- Eliminated the unused DOKPLOY_SERVER_VALUE constant from the network handling component. - Updated the default serverId to undefined in the network form values and adjusted related logic to ensure compatibility with cloud environments. - Enhanced server validation in the createNetwork function to require a serverId when in cloud mode, improving error handling for network creation.
- Introduced a new column "networkIds" of type text[] with a default value of an empty array to the application, compose, mariadb, mongo, mysql, postgres, and redis tables. - Updated the application and compose schemas to include the new networkIds field in their respective TypeScript definitions. - Added corresponding entries in the migration journal and created a snapshot for version 7 to reflect these changes.
- Deleted the SQL files for the "network" table and its associated constraints, as well as the snapshots for versions 0146 and 0147, to clean up the database schema and remove unused components. - Updated the migration journal to reflect these deletions, ensuring the database remains consistent and manageable.
- Added a new "network" table with various attributes including networkId, name, driver, and constraints for organizationId and serverId. - Introduced a custom ENUM type "networkDriver" for network drivers. - Updated existing tables (application, compose, mariadb, mongo, mysql, postgres, redis) to include a new "networkIds" column of type text[]. - Created a snapshot for version 7 to reflect these schema changes in the database.
- Updated the createNetwork function to ensure serverId is required when in cloud mode, improving error handling for network creation. - Added braces for clarity in the conditional statement, enhancing code readability.
- Deleted the SQL file for the "network" table and its associated constraints, as well as the snapshot for version 0146, to clean up the database schema. - Updated the migration journal to reflect these deletions, ensuring consistency in the database structure.
- Introduced a new ENUM type "networkDriver" and created the "network" table with various attributes for network management. - Added "networkIds" column to multiple existing tables (application, compose, mariadb, mongo, mysql, postgres, redis) to support network associations. - Established foreign key constraints for "organizationId" and "serverId" in the "network" table to ensure referential integrity. - Updated migration journal and added a new snapshot for version 0166 to reflect these changes.
…gnore - Deleted the SQL file and snapshot related to the "network" management schema, cleaning up the database structure. - Updated the migration journal to reflect these deletions. - Added .playwright-* to .gitignore to exclude Playwright test files from version control.
- Introduced a new SQL file defining the "network" type and its associated table structure. - Added "networkIds" column to multiple application tables for network association. - Established foreign key constraints for the "network" table linking to "organization" and "server" tables. - Updated migration journal and added a new snapshot for versioning.
- Updated the ShowNetworks component to improve the layout and user experience. - Introduced a new Pencil icon for editing networks and added a Badge component for displaying network drivers. - Refactored loading and empty state handling for better visual feedback. - Modified the API query to include server details for each network, enhancing the data returned for better context.
…ogic - Replaced zodResolver with standardSchemaResolver for improved schema validation. - Added new toggle options for network settings, enhancing user interface clarity. - Refactored network creation and update logic to streamline payload handling. - Updated network form schema to remove default values, ensuring explicit user input. - Introduced SERVER_LOCAL sentinel for local Dokploy server identification.
- Simplified the network form schema by removing unnecessary fields and enforcing validation rules for IP settings. - Updated the HandleNetwork component to eliminate the edit functionality, focusing on network creation only. - Improved the ShowNetworks component by adding a delete action for network management, enhancing user experience. - Introduced a new SQL migration for the network schema, establishing necessary constraints and types. - Cleaned up the API by removing the update network functionality, reflecting the immutable nature of Docker networks.
…actions - Introduced a new ShowNetworkConfig component for displaying detailed Docker network configuration. - Integrated ShowNetworkConfig into the ShowNetworks component, allowing users to view network details directly. - Updated the layout of network actions for improved user experience and accessibility. - Enhanced the API to support network inspection functionality, providing necessary data for the new component.
…synchronization - Added server filtering capability to the dashboard, allowing users to manage networks specific to selected servers. - Introduced SyncNetworks component for synchronizing Docker networks with Dokploy, enabling import of new networks and cleanup of stale records. - Updated HandleNetwork and ShowNetworks components to support server-specific operations, improving user experience and functionality. - Enhanced API to support network synchronization and importing, ensuring accurate data handling for network management.
…e synchronization - Added a new API endpoint for recreating Docker networks that have been removed, allowing users to restore networks directly from the Dokploy interface. - Updated the ShowNetworks and SyncNetworks components to include options for recreating networks, improving user management capabilities. - Enhanced the network synchronization process to better handle stale records, providing users with clear actions for network maintenance. - Refactored network creation logic to streamline the process and ensure consistency across network management operations.
- Added functionality for assigning Docker networks to services, allowing users to manage network associations directly from the UI. - Introduced new components for assigning networks to both individual services and compose files, improving user experience and flexibility. - Updated existing components to integrate network assignment features, ensuring seamless interaction within the dashboard. - Enhanced the database schema to support new network-related fields, including `networkIds` and `detachDokployNetwork`, for better service configuration. - Improved the layout and responsiveness of various UI elements to accommodate new features and enhance usability.
validateDomain returns isValid: true for CDN-fronted domains but reuses the `error` field to carry the provider's informational warning. Both domain tooltips branched on `error` alone, so the message rendered under a red "Error:" heading even though the badge correctly showed a green "Behind Cloudflare" state. Check the valid+message case first, matching how the badge already distinguishes the two. Applied to both the table view (columns.tsx) and the card view (show-domains.tsx), which shares the same tooltip. Fixes Dokploy#4910 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Added auditing functionality for network creation, recreation, and deletion actions in the network API. - Updated the audit log schema to include "network" as a resource type. - Enhanced the network router to log actions with relevant metadata, improving traceability and accountability for network management operations.
Feat/add network management
…rk validation - Added new endpoints for application creation, retrieval, and reloading with detailed request and response schemas. - Updated existing network validation schemas to enforce minimum length requirements for network IDs. - Improved OpenAPI documentation to ensure better clarity and validation for application-related operations.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (93)
🔥 Files not summarized due to errors (1)
📝 WalkthroughWalkthroughThis change adds managed Docker network storage, synchronization, creation, inspection, removal, dashboard controls, per-service assignments, Compose network injection, and Swarm network resolution. It also adds Compose icon handling, removes Redis maintenance flows, narrows several database projections, and updates supporting UI styles and fixtures. ChangesNetwork management
Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
Suggested reviewers: Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Rolling back any application fails with PostgresError: cannot pass more than 100 arguments to a function (54023) since 0175_fantastic_peter_quill took the application table to 101 columns. findRollbackById hydrated deployment -> application -> environment -> project, so drizzle compiled all 101 application columns plus the nested blob into one json_build_array() call, above the FUNC_MAX_ARGS = 100 limit. At 99 columns it sat exactly on the limit. None of that nested data is read: the routers only use deployment.applicationId, and rollback()/removeRollbackById() read the rollback row itself. Drop the nested relations, the same shape as Dokploy#4257 for findPreviewDeploymentById. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ersisting fix(ui): make interactive icons inside badges clickable again
Dokploy stopped using Redis in v0.29.9 when the deployment queue moved to an in-memory implementation, and install.sh no longer creates the dokploy-redis service. Remove the remaining references so fresh installs don't report Redis as unhealthy: - checkRedisHealth from infrastructure health check - cleanRedis/reloadRedis endpoints and their UI actions - initializeRedis dev setup and redis-connection config - unused bullmq dependency
…vers chore: remove leftover Redis infrastructure code
fix: avoid postgres 100-argument limit in findRollbackById
…it-finders fix: avoid postgres 100-argument limit in schedule, volume backup and port queries
- Updated ShowIconSettings component to handle both application and compose service types. - Added new icon column to the compose table in the database. - Implemented fetching and updating of icons for services in the environment and application pages. - Introduced fetchTemplateLogo function to retrieve logos for templates, improving icon handling for compose services.
feat(icon): enhance icon management for services
…tooltip-error-title fix(domains): don't render CDN info message as an error in DNS tooltip
What is this PR about?
This guarded sync integrates Dokploy upstream
canarythrough5df820a74. Today's reviewed delta adds 12 commits afterd768adb6a, including service icon management, PostgreSQL argument chunking for backup and port operations, Redis infrastructure cleanup, and small DNS and badge UI fixes. The complete PR is 40 commits and 94 paths ahead of the fork'smain.I reviewed every overlapping path. In
compose.ts, I preserved the fork's isolated deployment setting and adopted upstream's template icon. Upstream's migration number0176collided with the fork's existing0176-0180chain, so I generated0181_exotic_victor_mancha.sqlfor the compose icon column and regenerated the migration snapshot, journal, and OpenAPI document. A second migration generation reported no drift.The fork's Cloudflare, Tailscale, Halifax CI, deployment isolation, and other intentional behavior remains present. Upstream
canaryis still the active source branch.Verification:
pnpm install --frozen-lockfilepassed.NODE_ENV=test pnpm --dir apps/dokploy run migration:generatepassed twice, with no schema drift on the second run.NODE_ENV=test pnpm --dir apps/dokploy run generate:openapipassed with 584 endpoints.pnpm run format-and-lintpassed with six pre-existing warnings.pnpm run typecheckpassed across all four projects.Hosted build, test, and typecheck jobs all passed. This PR remains draft because the automation rules prohibit merging after any failed local run, even when the four failures are caused by missing Nixpacks and Docker Swarm infrastructure.
Risk is high because the cumulative PR includes schema, deployment, proxy, auth, and build behavior. Roll out only after a database backup and review of migration
0181. Roll back the application image first; do not reverse the migration after icon data is written without a deliberate migration plan.Checklist
canarybranch. The branch is based on the fork'smainand explicitly integrates upstreamcanary.Issues related (if applicable)
None.
Screenshots (if applicable)
Not applicable for this upstream integration PR.
Summary by CodeRabbit