deastman

Hi Darren here PM for Runner.

Yes if you compare just the price of a compute minute, then it is fair to state that the per-minute price is more than other services or do-it-yourself Runner on public clouds. And, of course, with GitLab, you can easily attach a self-managed Runner to a group or project, as there are no limitations or additional pricing that would prevent you from doing so.

However, we believe that the value of the GitLab SaaS solution will save you additional overhead costs over the long term compared to a do-it-yourself build environment. And we will continue to add more value to GitLab SaaS in the coming months, which your developers will immediately be able to use.

Darren here - PM for GitLab Runner. At this time, we aren't considering adding Podman to GitLab SaaS Runners on Linux. I created this issue, so please add comments there so we can continue the discussion.

https://gitlab.com/gitlab-org/gitlab/-/issues/370522

Hello - I am the product manager for GitLab Runner. The SIGTERM-related issues have been quite complex due to the different execution environments in which the Runner can operate. Can you add the details of your use case and workaround to the issue below? We need to take another look at this functionality, given the various reports of inconsistent behavior with long-running processes.

https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27443

Can you open an issue in the gitlab-runner project? It would be great if one of our engineers that focuses on the Kubernetes executor can weigh in.

https://gitlab.com/gitlab-org/gitlab-runner/-/issues

Is this on GitLab.com Shared Runners or your own? Also - go ahead and raise an issue with the details in the runner project so we can take a closer look.

https://gitlab.com/gitlab-org/gitlab-runner/-/issues

ok ping me on the epic link below. @DarrenEastman is the GitLab handle and let me know what compute class you are needing. We are planning to pivot soon on getting various compute types available on GitLab.com Shared runners.

https://gitlab.com/groups/gitlab-org/-/epics/2426

Hi Carlos, Darren here, PM for runner. Can you provide a bit more insight in terms of some of the challenges that you are having with hosting your own runners? In regards to testing CI locally, did you mean having the ability to validate that a pipeline is fully functional prior to pushing your commit to GitLab?

Hi - can you create an issue in the gitlab-runner project? It would be great so that we can investigate further.

https://gitlab.com/gitlab-org/gitlab-runner/-/issues

Today, for our Linux Runners on GitLab.com, those Runners are currently offered only on one machine type, Google Compute n1-standard-1 instances with 3.75GB of RAM. Our current Windows Runners on GitLab.com are Google Compute n1-standard-2 instances with 2 vCPUs and 7.5GB RAM. In the future, for Linux and Windows Runners, we will offer more GCP machine types. For our soon to launch macOS Build Cloud beta, we are planning to start with one virtual machine size and then possibly offer different machine configurations at GA.

So as you get going initially with GitLab SaaS, you don't have to set up your Runners for your first CI/CD jobs. Then, depending on your requirements, and as your use cases evolve, you can easily set up your own Runners but still benefit from the included minutes.

Darren Eastman - Product Manager GitLab Runner

We define Pipeline minutes as the execution time for your pipelines. You bring up an interesting point, though. So today, for our Linux Runners on GitLab.com, those Runners are currently offered only on one machine type, Google Compute n1-standard-1 instances with 3.75GB of RAM. Our current Windows Runners on GitLab.com are Google Compute n1-standard-2 instances with 2 vCPUs and 7.5GB RAM.

In the future, for Linux and Windows Runners, we will offer more GCP machine types. For our soon to launch macOS Build Cloud beta, we are planning to start with one virtual machine size and then possibly offer different machine configurations at GA.

And yes - the virtual machine used for your build on GitLab.com are dedicated only to your pipeline job and immediately deleted on job completion.

Finally, the only way to know how long your current build job will take on a GCP n1-standard-1 compared to the 8-core machine is to run the job and compare the results. I assume that your 8-core machine is probably a physical box, so you should of course, get better performance than a 1-2 vCPU VM.

A few reference links:

https://docs.gitlab.com/ee/user/gitlab_com/#shared-runners

https://gitlab.com/groups/gitlab-org/-/epics/1830

https://gitlab.com/groups/gitlab-org/-/epics/2426

Darren Eastman: Product Manager GitLab Runner

Can you raise an issue in the GitLab Runner project? This way we can take a closer look at the errors you have experienced.

And no, we don't do this on purpose in order to have you buy more minutes.

https://gitlab.com/gitlab-org/gitlab-runner/-/issues

Darren Eastman - Product Manager GitLab Runner

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.