-
Notifications
You must be signed in to change notification settings - Fork 49
Open
Milestone
Description
As a BLIS Developer,
I want the launcher to swap the current filesystem link and restart the application services,
So that the update is finalized and the new version is served to the user.
Description
This is the final stage of the update workflow. After files are staged and migrations are complete, the launcher must re-point the current link from the old release directory to the new one and bring the web and database services back online.
Technical Constraints:
- Windows: Use a Directory Junction.
- Linux: Use a Symbolic Link.
- Order of Operations: The link must be fully updated before services are restarted.
AC
Scenario 1: Link Swap (Windows/Linux)
- Given the Apache and MySQL services are currently stopped
And a new release is ready in the releases/ directory
When the launcher triggers the final cutover
Then it must delete the existing current link
And create a new link (Junction on Windows, Symlink on Linux) named current pointing to the new release folder.
Scenario 2: Service Restoration
- Given the current link has been successfully updated
When the launcher attempts to bring the system back online
Then it must start the MySQL database service first
And then start the Apache web server service.
Scenario 3: Successful Update Verification
- Given the services have been restarted
When the launcher checks the status of the Apache and MySQL processes
Then it should confirm they are "Running"
And display a "Success" message to the user in the Avalonia UI.
Scenario 4: Error Handling
- Given the link creation or service restart fails
When an error is caught
Then the launcher must not report a "Success" state
And it must log the specific error (e.g., "Access Denied" or "Port in Use") to the update log.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels