Fix bug for devfile with multiple container components

What does this MR do and why?

This MR is the 16.8 backport for Multi container devfile bug fix (!143022 - merged) .

Issue: Gitlab Workspaces - API backend locks up with s... (#437887 - closed)

Problem

If a devfile had multiple container components, the volume wasn't getting mounted to each of these containers. This causes problems while generating the Kubernetes resources.

Solution

Refactor the code to ensure the volume(containing the source code) is mounted to each container components.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

• Create a project with the following devfile

schemaVersion: 2.2.0
variables:
  registry-root: registry.gitlab.com
components:
  - name: tooling-container
    attributes:
      gl/inject-editor: true
    container:
      image: patnaikshekhar/go-ssh:1
      env:
        - name: KEY
          value: VALUE
      endpoints:
      - name: http-3000
        targetPort: 3000
  - name: database
    attributes:
      gl/inject-editor: false
    container:
      image: mysql
      env:
        - name: MYSQL_ROOT_PASSWORD
          value: "my-secret-pw"
      endpoints:
      - name: mysql
        targetPort: 3306
        exposure: none
        protocol: tcp

• Create a workspace from the said project.
• Ensure the volume that gets mounted(containing the project's code) is accessible in all container and any file written from one container can be seen by the other.

# change kubernetes namespace to the one just created for the workspace
POD_NAME=$(kubectl get po --no-headers -o custom-columns=":metadata.name")

kubectl exec -it $POD_NAME -c tooling-container -- sh

$ ls -lart /projects
total 16
drwxr-xr-x 3 gitlab-workspaces root 4096 Jan 30 04:43 testing-remote-development
drwxrwxrwx 4 root              root 4096 Jan 30 04:43 .
drwxr-xr-x 3 gitlab-workspaces root 4096 Jan 30 04:43 .gl-tools
drwxr-xr-x 1 root              root 4096 Jan 30 04:44 ..

$ touch /projects/TEST.md

kubectl exec -it $POD_NAME -c database -- sh

sh-4.4$ ls -lart /projects
total 16
drwxr-xr-x 3 5001 root 4096 Jan 30 04:43 testing-remote-development
drwxr-xr-x 3 5001 root 4096 Jan 30 04:43 .gl-tools
drwxr-xr-x 1 root root 4096 Jan 30 04:44 ..
-rw-r--r-- 1 5001 5001    0 Jan 30 04:51 TEST.md
drwxrwxrwx 4 root root 4096 Jan 30 04:51 .

As you can see, we wrote a file TEST.md from the tooling-container and we can see that file in the database container.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
• The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
• This MR has a severity label assigned (if applicable).
• Set the milestone of the merge request to match the target backport branch version.
• This MR has been approved by a maintainer (only one approval is required).
• Ensure the e2e:package-and-test-ee job has either succeeded or been approved by a Software Engineer in Test.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

• Refer to the patch release runbook for engineers and maintainers for guidance.
• Ask questions on the #releases Slack channel (internal only).