Skip to content

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

Screenshot_2025-09-02_at_7.44.52_PM

Before After
Screenshot_2025-09-02_at_7.57.02_PM Screenshot_2025-09-02_at_8.06.39_PM

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 file tooling_container.log in the /projects/<clone_project>/ directory while the go-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.

Edited by Ashvin Sharma

Merge request reports

Loading