postStart commands should run in project directory
Issue: postStart commands should run in project directory (#555948 - closed)
What does this MR do and why?
This change adds support for specifying working directories when running commands in remote development workspaces. Previously, all commands would run from the container's default WORKDIR location, but now developers can specify a workingDir
option in their devfile configuration to control where each command executes.
The implementation includes several key improvements:
- Added
workingDir
as a supported option for exec commands in the restrictions enforcer - Created a helper module to identify the main component in a workspace configuration
- Modified script generation to change to the specified working directory before executing commands
- For commands without an explicit working directory, the system now defaults to the project's source directory when running on the main component
- Updated test fixtures to demonstrate both scenarios: commands with explicit working directories and commands that use the default project path
The change ensures backward compatibility while giving developers more control over command execution context, which is particularly useful for build scripts, package managers, and other tools that need to run from specific directories within a project.
References
Screenshots or screen recordings
Previously the post start commands would execute in the container's default working directory but after this change the main container's post start commands by default will execute in the cloned project directory
Before | After |
---|---|
![]() |
![]() |
How to set up and validate locally
- Setup workspaces locally following this guide
- Checkout this branch and add a devfile with a post start command to any of your projects.
- Example devfile:
schemaVersion: 2.2.0
components:
- name: tooling-container
attributes:
gl/inject-editor: true
container:
image: "registry.gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/ubuntu:22.04"
endpoints:
- name: http-3000
targetPort: 3000
exposure: internal
secure: false
- name: go-container-1
attributes:
overrideCommand: false
container:
image: "alpine:latest"
command: ["tail", "-f", "/dev/null"]
commands:
- id: go-container-command-1
exec:
component: go-container-1
commandLine: /bin/sh -c 'mkdir go-container-dir'
workingDir: /projects
- id: tooling-container-command
exec:
component: tooling-container
commandLine: /bin/sh -c 'echo "TOOLING CONTAINER COMMAND" > tooling_container.log'
events:
postStart:
- go-container-command-1
- tooling-container-command
- Then go to
http://gdk.test:3000/-/remote_development/workspaces
and create a new workspace for that project. - Open the workspace, check that the postStart commands are executed correctly and that the
tooling-container-command
creates the log filetooling_container.log
in the/projects/<clone_project>/
directory while thego-container-command-1
executes in the/projects
directory.
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.