## Overview The job API responds with a an array of [steps](https://gitlab.com/gitlab-org/gitlab-runner/blob/38b5dcbcf56525cc024debecf2021ddda5256be1/common/network.go#L175-181) which we use to build the user [`script`](https://gitlab.com/gitlab-org/gitlab-runner/blob/38b5dcbcf56525cc024debecf2021ddda5256be1/shells/abstract.go#L444) and [`after_script`](https://gitlab.com/gitlab-org/gitlab-runner/blob/38b5dcbcf56525cc024debecf2021ddda5256be1/shells/abstract.go#L602). In https://gitlab.com/gitlab-org/gitlab/issues/38352#note_264198104 & https://gitlab.com/gitlab-org/gitlab/issues/39089#note_259412690 we are proposing to extend the steps so that we can run scripts generated from `.gitlab-ci.yml`. ## Proposal Accept more type of `steps` that the Rails can generate and run these scripts inside of the build context, meaning if it's inside Docker executor it will run the script inside of the build container. A few things that need to be considered: 1. Should we add any kind of validation of the [`StepName`](https://gitlab.com/gitlab-org/gitlab-runner/blob/38b5dcbcf56525cc024debecf2021ddda5256be1/common/network.go#L176), if we do this kind of validation of "known steps" every time rails creates a new step we have to sync up, which can be complex because it would depend on the Runner version 1. How should the timeout work 1. Should the script be executed as part of the user script, or in a separate context, meaning it would not have any environment variables that [`before_script`](https://docs.gitlab.com/ee/ci/yaml/#before_script-and-after_script) & [`script`](https://docs.gitlab.com/ee/ci/yaml/#script). This might not work at all since in https://gitlab.com/gitlab-org/gitlab-runner/issues/6411 we are planning to execute it in a different environment