4 ms·

> You generally can't run them locally GitLab CI gives you local runners. You can completely self-host CI.

Joker_vD 2y ago
Well, yes, but aren't those runners have different configuration than the runners that are actually deployed and used by your company's CI/CD?
- tempodox 2y ago
  Wat? Our company's CI is GitLab CI, self-hosted. What other runners would we need?
  - Joker_vD 2y ago
    The local ones, mentioned in the original comment that we've been discussing in this thread? The local runner, executing on the developer's machine.
    - tempodox 2y ago
      Of course it makes no difference whether that runner runs on our local CI host or on my dev machine.
      - Izkata 2y ago
        I think GP got confused, it's not running the runners locally, it's running the CI steps locally (see the other sibling replies). For example, running tests locally exactly the same way as in the runner - sometimes I have to open a debugger in the middle of a test to see what exactly went wrong. Our tests run in gitlab in a particular docker image, and I've been adding a "make test" that runs the same tests in the same image locally, with additional flags to have full interactivity so the debugger works if needed.
Plasmoid 2y ago
It's not self hosting. It's can I run the build from my local command line and get the same results.
- tempodox 2y ago
  How is running those runners on our own hosts (locally) not self-hosting?
  - mdaniel 2y ago
    Spoken like someone who has not tried what you are describing. There are two moving parts to your response: a locally hosted runner awaits jobs from GitLab itself, which doesn't help running _locally_, and the other part is that -- back when it existed! -- trying $(gitlab-runner exec) was not a full fledged implementation of the GitLab CI concepts, making it the uncanny valley of "run something locally." However, as of v16 there is no more exec https://gitlab.com/gitlab-org/gitlab/-/issues/385235 https://gitlab.com/gitlab-org/gitlab/-/issues/385235 which I guess is good and bad. Good in that it not longer sets improper expectations that it could have plausibly done anything, and bad in that now it joins GitHub Actions[1] in not having any _local_ test strategy aside from "boot up gitlab/gitlab-ce && echo good luck" 1: yes, I'm acutely aware of the 3(?) implementations/forks of nektos/act that claim to do GHA but, again, readme is not software and I can tell you with the utmost certainty they do not do as advertised
    - Joker_vD 2y ago
      Not to mention that the rest of the environment is missing: e.g. you probably can't push to e.g. the organization's Docker registry/Artifactory/whatever from you local dev machine (if it's even visible from your machine in the first place). And those are arguably the most interesting parts that you want to test the integration with.

Well, yes, but aren't those runners have different configuration than the runners that are actually deployed and used by your company's CI/CD?

tempodox 2y ago
Wat? Our company's CI is GitLab CI, self-hosted. What other runners would we need?
- Joker_vD 2y ago
  The local ones, mentioned in the original comment that we've been discussing in this thread? The local runner, executing on the developer's machine.
  - tempodox 2y ago
    Of course it makes no difference whether that runner runs on our local CI host or on my dev machine.
    - Izkata 2y ago
      I think GP got confused, it's not running the runners locally, it's running the CI steps locally (see the other sibling replies). For example, running tests locally exactly the same way as in the runner - sometimes I have to open a debugger in the middle of a test to see what exactly went wrong. Our tests run in gitlab in a particular docker image, and I've been adding a "make test" that runs the same tests in the same image locally, with additional flags to have full interactivity so the debugger works if needed.

Plasmoid 2y ago

It's not self hosting. It's can I run the build from my local command line and get the same results.

tempodox 2y ago
How is running those runners on our own hosts (locally) not self-hosting?
- mdaniel 2y ago
  Spoken like someone who has not tried what you are describing. There are two moving parts to your response: a locally hosted runner awaits jobs from GitLab itself, which doesn't help running _locally_, and the other part is that -- back when it existed! -- trying $(gitlab-runner exec) was not a full fledged implementation of the GitLab CI concepts, making it the uncanny valley of "run something locally." However, as of v16 there is no more exec https://gitlab.com/gitlab-org/gitlab/-/issues/385235 https://gitlab.com/gitlab-org/gitlab/-/issues/385235 which I guess is good and bad. Good in that it not longer sets improper expectations that it could have plausibly done anything, and bad in that now it joins GitHub Actions[1] in not having any _local_ test strategy aside from "boot up gitlab/gitlab-ce && echo good luck" 1: yes, I'm acutely aware of the 3(?) implementations/forks of nektos/act that claim to do GHA but, again, readme is not software and I can tell you with the utmost certainty they do not do as advertised
  - Joker_vD 2y ago
    Not to mention that the rest of the environment is missing: e.g. you probably can't push to e.g. the organization's Docker registry/Artifactory/whatever from you local dev machine (if it's even visible from your machine in the first place). And those are arguably the most interesting parts that you want to test the integration with.