|
|
|
|
|
by deastman
2365 days ago
|
|
Hi, Darren here - PDM for Runner (deastman@gitlab.com). Yes - as we mention on this page, https://docs.gitlab.com/runner/commands/#limitations-of-gitl..., there are limitations with the current exec implementation. We also have this issue https://gitlab.com/gitlab-org/gitlab-runner/issues/2797#prop... open on this topic. In reading the threads here, I will update that issue on GitLab with our latest thinking regarding implementation challenges, ideas, etc. At a high-level today, the Runner is really just a job execution engine for want of a better description. The Runner is focused on taking a job and executing it. So as we look at this problem of executing a pipeline locally, we have to think about all of the logic that's happening in the GitLab CI Rails app - stuff like artifacts passing for example. Then we have to figure out how to parse the .gitlab-ci.yml file. Ideas like, do we do this in the context of a specific project, or a connection to any GitLab API. So tons of pros and cons to consider for sure. Given the in-depth discussion on this topic, its clear that I and the team need to refocus on this topic sooner rather than later. In chatting with one of our lead backend engineers, his point of view is that " I totally agree. I use exec quite often and I'd love to have this command a first class citizen again." So I am going to spend some time in the next couple of days capturing some of the thoughts here and updating the issue in GitLab with our latest ideas and proposals. We definitely need to get this done, so any help from the community is welcome, as we think solving this is going be a bit of work and make take a few release cycles. |
|