This commit addresses two critical issues with Docker Compose service management:
## Issue 1: Duplicate Services Created on Image Change
When changing the image in a docker-compose file, the parser was creating new
ServiceApplication/ServiceDatabase records instead of updating existing ones.
**Root Cause**: The parsers used `firstOrCreate()` with `['name', 'image', 'service_id']`,
meaning any image change would create a new record.
**Fix**: Remove `image` from `firstOrCreate()` queries and update it separately after
finding or creating the service record.
**Changes**:
- `bootstrap/helpers/parsers.php` (serviceParser v3): Fixed in presave loop (lines 1188-1203)
and main parsing loop (lines 1519-1539)
- `bootstrap/helpers/shared.php` (parseDockerComposeFile v2): Fixed null check logic
(lines 1308-1348)
## Issue 2: UI Not Refreshing After Changes
When compose file or domain was modified, the Configuration component wasn't receiving
events to refresh its data, requiring manual page refresh to see updates.
**Root Cause**: The Configuration component wasn't listening for refresh events dispatched
by child components (StackForm, EditDomain).
**Fix**: Add event listeners and dispatchers to enable real-time UI updates.
**Changes**:
- `app/Livewire/Project/Service/Configuration.php`: Added listeners for `refreshServices`
and `refresh` events (lines 36-37)
- `app/Livewire/Project/Service/EditDomain.php`: Added `refreshServices` dispatch (line 76)
- Note: `app/Livewire/Project/Service/StackForm.php` already had the dispatch
## Tests Added
- `tests/Unit/ServiceParserImageUpdateTest.php`: 4 tests verifying no duplicates created
- `tests/Unit/ServiceConfigurationRefreshTest.php`: 4 tests verifying event dispatching
All 8 new tests pass, and all existing unit tests continue to pass.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This change introduces automatically generated `SERVICE_NAME_<SERVICE>`
environment variables for each service within a Docker Compose deployment.
This allows services to reliably reference each other by name, which is particularly
useful in pull request environments where container names are dynamically suffixed.
- The application parser now generates and injects these `SERVICE_NAME` variables
into the environment of all services in the compose file.
- `ApplicationDeploymentJob` is updated to correctly handle and filter these
new variables during deployment.
- UI components and the `EnvironmentVariableProtection` trait have been updated
to make these generated variables read-only, preventing accidental modification.
This commit introduces two new helper functions to standardize resource naming
for pull request deployments:
- `addPreviewDeploymentSuffix()`: Generates a consistent suffix format (-pr-{id})
for resource names in preview deployments
- `generateDockerComposeServiceName()`: Creates SERVICE_NAME environment variables
for Docker Compose services
Updated the default Nginx configuration function to enhance clarity and maintainability. Removed unnecessary redirection logic and added explicit handling for 404 errors, ensuring a more robust error management strategy. This refactor simplifies the configuration while maintaining essential functionality, contributing to a cleaner and more efficient setup.
- Removed the private property for application deployment queue ID in ApplicationDeploymentJob and utilized constructor property promotion.
- Added a tags method in ApplicationDeploymentJob to properly identify the worker running the job.
- Updated HorizonServiceProvider to handle cases where the deployment queue ID is blank, preventing potential errors during job processing.
- Cleaned up the isAnyDeploymentInprogress function by removing unnecessary whitespace.
- Simplified the job status retrieval process by consolidating logic into a single `getJobStatus` function.
- Removed redundant checks and methods from the `CustomJobRepositoryInterface` and `CustomJobRepository`.
- Updated the `getHorizonJobStatus` method in `ApplicationDeploymentQueue` to directly utilize the new `getJobStatus` function.
- Enhanced the `isThereAJobInProgress` method to improve clarity and maintainability.
- Updated the isAnyDeploymentInprogress function to check for running jobs based on the current hostname.
- Enhanced the logic to return true if any job status is 'unknown' and to provide a clearer output regarding the number of deployments in progress.
- Modified the cloud_upgrade.sh script to loop until the deployment status check confirms no ongoing deployments before proceeding with the upgrade.
