Fix: Update post start behaviour for workspace
What does this MR do and why?
Update post start behaviour for workspace
Internal post start commands which clone the project, start sshd, start init tools are not backgrounded anymore. This prevents from the workspace being marked ready prematurely.
Before executing any user-provided commands, we will wait for the workspace to be marked ready. This will be backgrounded to not block the workspace from being marked ready.
References
- Move workspace project cloning to post start (!192345 - merged)
- #538207 (comment 2539861363) (discussion thread for the regression)
Screenshots or screen recordings
Before (Workspace Marked Ready before completely initialized) | After (Workspace Marked Ready - Initialized) |
---|---|
![]() |
![]() |
![]() |
![]() |
Post Start command stdout logs
Remote Development Smoke Test Suite
How to set up and validate locally
- Setup workspaces locally following this guide
- Checkout this branch
- Edit
ee/lib/remote_development/workspace_operations/create/internal_poststart_command_clone_project.sh
put asleep 1m
after line37
(This replicates the behaviour of cloning medium/large repos) - Run
gdk restart
so the script changes are reloaded - Then go to
http://gdk.test:3000/-/remote_development/workspaces
and create a new workspace - The workspace might take longer than usual to be 'Ready' but that is because of the sleep statement we added in the clone_project script which is now a blocking command and the workspace is marked ready only when this command finishes, which is the correct behaviour.
- Open the workspace when it is marked ready, workspace should open with vscode loaded instead of the error page we saw previously
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Edited by Vishal Tak