Add support for container specific post start events

Issue: Add support for container specific postStart ev... (#553096 - closed)

What does this MR do and why?

Note This MR is rebased onto postStart commands should run in project directory (!203029 - merged)

With this MR we are now enabling container specific postStart events. Previously all the postStart commands for every container were aggregated into these 2 script file

• gl-run-internal-blocking-poststart-commands.sh
• gl-run-non-blocking-poststart-commands.sh

which were then executed by each container. This meant duplicate execution of commands and overwriting of log files. Now each container will have its own version of the poststart-commands script and will contain only the commands that were defined for that container.

The gl-run-internal-blocking-poststart-commands.sh will only be executed for the main container which has the gl/inject-editor: true attribute set in the devfile. This script file hosts internal workspace initialization commands such as cloning the project, starting sshd daemon, starting vscode server etc.

Secondary containers will have their own versions of the gl-run-non-blocking-poststart-commands.sh which will be mounted in /workspace-scripts/<component-name>/

This code change improves how development workspace logs are organized and managed. Previously, all log files were stored in a single directory, but now they're organized into separate folders for each component (container) in the workspace.

The main improvements include:

1. Better log organization: Log files are now stored in component-specific subdirectories (like /logs/component1/, /logs/component2/) instead of all being mixed together in one folder.

2. Smarter script execution: The system now identifies which component is the "main" one and only runs certain initialization scripts (like starting SSH server or VS Code) on that main component, avoiding duplicate processes.

3. Component-aware file paths: All script files and log paths now include the component name, making it easier to track which component generated which logs or ran which scripts.

4. Cleaner code structure: The changes extract common functionality into a shared helper module, reducing code duplication and making the system easier to maintain.

These changes make it much easier for developers to debug issues in their workspaces since they can now easily find logs specific to each component, and the system avoids running duplicate background processes across multiple containers.

References

• Poststart feature MR: Add support for container specific post start e... (!198027 - merged)
• Discussion that lead to this issue: &15602 (comment 2588476647)

Screenshots or screen recordings

Before (workspace_logs)	After (workspace_logs)

Before (workspace_scripts)

After (workspace_scripts)

How to set up and validate locally

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.