3 ms·

For me the big problems with CI setups tend to be: - They're often slow - They're often proprietary - They're often dealing with secrets which limits who can

For me the big problems with CI setups tend to be: - They're often slow - They're often proprietary - They're often dealing with secrets which limits who can work on them - You generally can't run them locally So the feedback cycle for working on them is incredibly long. And working on them is therefore a massive pain.

sharkjacobs 2y ago
> You generally can't run them locally I recognize that this is such a disincentive for me taking the initiative to fiddle with and learn about anything like this
- vintermann 2y ago
  Same goes for anything "enterprisey". Last time I set up a big project, I made a commitment that "we should be able to check out and build this whole thing, for as long as humanly possible".
pipes 2y ago
The local part is my big problem too. I used azure Dev ops in work. I find clicking through the UI to be a miserable experience, Id love to have it running locally so I could view inputs and outputs on the file system. Also yaml is an awful choice, no one I know enjoys working with it. The white space issues just get worse and worse longer your files get.
tempodox 2y ago
> 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.

sharkjacobs 2y ago

> You generally can't run them locally I recognize that this is such a disincentive for me taking the initiative to fiddle with and learn about anything like this

vintermann 2y ago
Same goes for anything "enterprisey". Last time I set up a big project, I made a commitment that "we should be able to check out and build this whole thing, for as long as humanly possible".

pipes 2y ago

The local part is my big problem too. I used azure Dev ops in work. I find clicking through the UI to be a miserable experience, Id love to have it running locally so I could view inputs and outputs on the file system. Also yaml is an awful choice, no one I know enjoys working with it. The white space issues just get worse and worse longer your files get.

tempodox 2y ago

> 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.