MR: Pending <!-- The first line of the MR must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, and the first description line of the MR should be `Issue: <Issue link with trailing +>` 3. `MR: No MR` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#1-to-1-relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description Currently, we support 2 types of components in a devfile - `container` and `volumes`. The `gl/inject-editor` attribute is used to identify which container component should be injected with the editor. However, when we make this check in our code, we do not check whether it is a `container` component; we only check for the presence of this attribute in any of the components. Thus, there is a possibility that someone could define the attribute in a `volume` component which would break this - https://gitlab.com/gitlab-org/gitlab/-/blob/5848f31b815919f481ca1a9e1c6b91a694608f98/ee/lib/remote_development/workspaces/create/post_flatten_devfile_validator.rb#L60 ## Acceptance Criteria - [ ] When check for the existing of `gl/inject-editor` attribute in the devfile, only check for `container` components. ## Technical Requirements TODO: Fill out or delete [If applicable, please list out any technical requirements for this feature/enhancement.] ## Design Requirements TODO: Fill out or delete [If applicable, please provide a link to the design specifications for this feature/enhancement.] ## Impact Assessment TODO: Fill out or delete [Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.] ## User Story TODO: Fill out or delete [Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.] <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->