11–20 of 30 posts
Unfortunatelly there is still no way to run CI file locally which is major turn down. Deprecated `exec` command is hell to use. I should be able to install runner on developers machine and just run and debug pipeline there, with or without Gitlab server present.
You can run CI files locally. Just install a GitLab runner and run it through the command line.
Interesting addition of Conan support right into GitLab. > For any development organization, having an easy and secure way to manage dependencies is critical. Package management tools, such as Conan for C/C++ developers, provide a standardized way to share and version control these libraries across projects. > In GitLab 12.6, we are proud to offer Conan repositories built directly into GitLab. Developers can now publ…
Earlier quoted context omitted.
I am particular about how I code my builds so they are portable. I like debugging locally, its faster. Gitlab-Ci does not encourage this and I usually end up refactoring my colleagues code all the time to this end. Not sure if having a runner is the proper solution to this problem. Off the cuff I feel like there are better ways to go about it if I where making a CI server from scratch. Like only allowing single Docke…
Gitlab executes shell commands, you can and should run those locally to debug. If your putting complex build logic inside gitlab definitions then perhaps you’re doing it wrong - “make test” or “make release” should be all that Gitlab runs.
Earlier quoted context omitted.
Gitlab executes shell commands, you can and should run those locally to debug. If your putting complex build logic inside gitlab definitions then perhaps you’re doing it wrong - “make test” or “make release” should be all that Gitlab runs.
Right, my point was that I shouldn't need to enforce this. Gitlab yaml allows and often goes out of its way to encourage non-portable practices.
My point is your complaint seems more general than Gitlab itself.
Unfortunatelly there is still no way to run CI file locally which is major turn down. Deprecated `exec` command is hell to use. I should be able to install runner on developers machine and just run and debug pipeline there, with or without Gitlab server present.
> Unfortunatelly there is still no way to run CI file locally which is major turn down. You can run CI files locally. Just install a GitLab runner and run it through the command line.
Notice: Not all features of .gitlab-ci.yml are supported by exec. [2]
[1]: https://gitlab.com/gitlab-org/gitlab-runner/issues/2710 [2]: https://docs.gitlab.com/runner/commands/#gitlab-runner-exec
Unfortunatelly there is still no way to run CI file locally which is major turn down. Deprecated `exec` command is hell to use. I should be able to install runner on developers machine and just run and debug pipeline there, with or without Gitlab server present.
Deprecated `exec` command is hell to use Curious what makes it hell to use? Unfortunatelly there is still no way to run CI file locally which is major turn down I don't think thats correct. As you mention there is `exec`. Do you know of better alternatives?
As I mentioned above, exec is no longer maintained and has missing features.
Earlier quoted context omitted.
Right, my point was that I shouldn't need to enforce this. Gitlab yaml allows and often goes out of its way to encourage non-portable practices.
But... it just runs shell commands. It doesn’t encourage you to do more complex things, especially compared to other CI systems like Jenkins. My point is your complaint seems more general than Gitlab itself.
a. They will write an inline script. Solution: Rip it out into a file.
b. Each Job is using a different container. Solution: use Docker with mapped volumes or we all have the same machines (this might not be possible for some workloads) and only use a single container. Why not run the shell directly you may ask? b.1 Each container has a different environment and my machine has one. b.2 Some things do not run natively on my machine that do on theirs.
c. Variables are defined in the yaml instead of the scripts. Solution: Make a local .env file see b.
So sure, a local gitlab runner us probably best patch here. But I am imagine if someone made a container runtime specifically for this then wrapped that in a CI config it could be very ergonomic. Which is what I would explore if I where to write a IC today. I am sure some build system today already does this...
Things outside (kindof) of Gitlab's control that I might as well complain about while I am here:
d. And regardless, there are transient dependencies everywhere (which I blame the all language creators for really, mfs :P ). So everything gets fucked eventually anyhow. Wouldn't it be nice if you could whip out a three year old project, run the build, and its exactly as you left it?
e. People thinks all right to allow for mutable versions so I have to asdjnasdaskdjasdlasjdl;askjd;asldkj = asdasdljkdasl;kdjlaskdjaslkjd some non-human readable hash if I am feeling paranoid.
d. and e. are firmly in the language creators hand I believe. But Gitlab does offer artifact repositories (which are non-portable and could also easily could be). Gitlab could also save dependency trees in different languages. But really I would gripe to the tool/language creators.
I am thankful for this release. It finally fixed two major issues that had plagued Gitlab for us for a long time: - The "Rebase" button now actually seems to work reliably with no cases of endless spinning to report in the few tens of button presses so far for me (we merge fast-forward only). Hoping this is not a fluke and will not regress in the future. - The "Hide whitespace changes" button works again after breaki…
Is that actually happening anywhere? I've only ever seen projects where issue raising rate is correlated to project size. It doesn't matter if it's mature - change requests, debatable bugs, feature requests, etc. just continue to be raised forever.
Unfortunatelly there is still no way to run CI file locally which is major turn down. Deprecated `exec` command is hell to use. I should be able to install runner on developers machine and just run and debug pipeline there, with or without Gitlab server present.
Deprecated `exec` command is hell to use Curious what makes it hell to use? Unfortunatelly there is still no way to run CI file locally which is major turn down I don't think thats correct. As you mention there is `exec`. Do you know of better alternatives?
I currently use task system with Gitlab to make any job in 1-3 lines. Then I can easily replicate build locally. The task engine is either installed on runner's host itself or run inside docker container.