CI Steps Phase: Users can run steps in their own execution environment
## Problem The initial version of the step runner is deployed as a Docker image. This requires customers to use a GitLab runner executor that supports Docker containers, and it requires them to run the CI/CD job inside the step runner Docker container instead of their own Docker container, VM or other execution environment. ## Success criteria - Customers can supply the `image` on a CI/CD job that uses steps. ## Out of scope - Running steps in various Runner executors will be handled in a subsequent epic, https://gitlab.com/groups/gitlab-org/-/epics/16962+ - Running steps on different operating systems will be handled in a subsequent epic, https://gitlab.com/groups/gitlab-org/-/epics/15074+. ## Example ```yaml my-job: image: alpine:3.18 run: - name: blue-green-deploy step: gitlab.com/my-steps/deploy inputs: target: blue artifact: bundle.zip ``` ## Proposal The step runner should be installed into the runner execution environment. Step runner should start as a service on a known port. GitLab runner will connect to the Step runner using gRPC to start jobs, follow logs, check status of jobs, and receive results of completed jobs. ## Reference This phase relates to `Phase 3: steps, steps everywhere!` in https://gitlab.com/gitlab-org/step-runner/-/issues/112#note_2044603629.
epic