Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jenkins Is Getting Old

itnext.io

Post reply on HN
Print view View original

311–320 of 340 posts

Re: Jenkins Is Getting Old

#311

Post by majkinetor »

lbotos wrote: post #187
majkinetor wrote: post #133

Earlier quoted context omitted.

Gitlab is awesome, its impressive what you get for free. Runners are nice, can run in powershell, bash, docker, vm , you name it. The main problem with runner is that you cant easily execute build script on the host. Exec command isn't very useful and AFAIK deprecated.

I'm confused at what you mean here. If you want to run things on the host you can run a bash runner, and you have full access to the machine. What do you want to do on the host?

There is gitlab-runner exec command which takes a ci yaml file and executes it, but it sux (A LOT), so they deprecated it.

This is not the same as taking a bash/powershell script and running it locally on runners host because gitlab inject into shell some stuff like secrets, env vars, artifacts, caches etc.

Some errors are VERY hard to reproduce when not on local executing environment.

Re: Jenkins Is Getting Old

#312

Post by majkinetor »

KaiserPro wrote: post #279
majkinetor wrote: post #133

Earlier quoted context omitted.

Gitlab is awesome, its impressive what you get for free. Runners are nice, can run in powershell, bash, docker, vm , you name it. The main problem with runner is that you cant easily execute build script on the host. Exec command isn't very useful and AFAIK deprecated.

You haave to install the runner on the target, then you can use exec, plus a switch to allow it to run as root. The key is it has to be configured on the target device _first_. Then you have a root shell on your target device (I leave the "should" as an exercise for the user ) But, It won't work using the free shared gitlab runners.

I use gitlab on premise and install runner via Chocolatey package I maintain: http://chocolatey.org/packages/gitlab-runner

Re: Jenkins Is Getting Old

#313

Post by majkinetor »

jennbriden wrote: post #147
majkinetor wrote: post #133

Earlier quoted context omitted.

Gitlab is awesome, its impressive what you get for free. Runners are nice, can run in powershell, bash, docker, vm , you name it. The main problem with runner is that you cant easily execute build script on the host. Exec command isn't very useful and AFAIK deprecated.

CodeShip is also a SaaS and is, "Forever free: You can use up to 100 builds per month for free, with unlimited projects and unlimited team members." We are also working at CloudBees to have CodeShip support the emerging Jenkins X Pipeline syntax (YAML that mirrors the functionality of the Jenkins Pipeline). This syntax was based on the Tekton project, driven by the Continuous Delivery Foundation and significantly inf…

100 builds per month ? I have more then that in a day for medium size projects!

No, nothing in the cloud, no system you don't fully control is an option in my IT business. Forever. The only thing I tolerate is something totally irrelevant most of the time, (like statuspage maybe), easily replaceable and package repositories (but only because you can install local proxy so once pulled is on premise FOREVER).

Re: Jenkins Is Getting Old

#314

Post by majkinetor »

chupasaurus wrote: post #285
hardwaresofton wrote: post #9

Disclaimer: I'm pretty biased towards Gitlab -- write about the things you can do it from time to time and they gave me some free swag once. Best CI I've ever used is Gitlab CI[0]. The runner is completely open source[1] and you can use your own runner with your gitlab.com (or local instance) projects -- set it up in an autoscaling group[2] for savings. I run https://runnerrental.club but Gitlab also recently release…

Multirepo pipelines behind a paywall is a good reason to say "No, thanks".

TBH, its easily done in shell via REST API. We use custom pipeline runner from simple Powershell scripts that works even better for us then default style.

We set all jobs to manual and then our script triggers them depending on commit message, person, moon phase etc.

But really, this should be in core. Its very hard to do multirepository stuff. Its not that easy to do mono repo stuff too - I really need a pipeline withint sub-project, a mother pipeline, option to run whatever one I want etc... Gitlb pipelines could be a lot better.

Re: Jenkins Is Getting Old

#315

Post by hardwaresofton »

tr-gitlab wrote: post #305
hardwaresofton wrote: post #77

Earlier quoted context omitted.

Inclusion of the free docker registry was also pretty visionary, and it's been a while since they added that -- it's crucial for just about all my new projects.

I'm the GitLab product manager for the Package, which includes the container registry. Thanks for the feedback! You can see the updated vision and direction for the container registry here: https://about.gitlab.com/direction/package/container_registr... If you have any questions or feedback, you can email me at at trizzi@gitlab.com. I'd love to hear more about how you are using the docker registry today and any impro…

Just saw this, thanks for the link to the vision! I can't say I have any great recommendations for the container registry but hopefully someone that does sees this.

Re: Jenkins Is Getting Old

#316

Post by hardwaresofton »

majkinetor wrote: post #314
chupasaurus wrote: post #285

Earlier quoted context omitted.

Multirepo pipelines behind a paywall is a good reason to say "No, thanks".

TBH, its easily done in shell via REST API. We use custom pipeline runner from simple Powershell scripts that works even better for us then default style. We set all jobs to manual and then our script triggers them depending on commit message, person, moon phase etc. But really, this should be in core. Its very hard to do multirepository stuff. Its not that easy to do mono repo stuff too - I really need a pipeline wi…

I find it very easy to make multi-repo stuff, I've also wrote about it: https://vadosware.io/post/fun-with-gitlab-ci

Also, running pipelines in different projects and whenever you want is accessible from the web interface... It could be cleaner, but IMO adding even more syntax to the YAML file can also be a rabbit hole -- CURL from the script section seems like not a bad middle ground.

Am I misunderstanding what is being referenced?

Re: Jenkins Is Getting Old

#317

Post by hardwaresofton »

chupasaurus wrote: post #285
hardwaresofton wrote: post #9

Disclaimer: I'm pretty biased towards Gitlab -- write about the things you can do it from time to time and they gave me some free swag once. Best CI I've ever used is Gitlab CI[0]. The runner is completely open source[1] and you can use your own runner with your gitlab.com (or local instance) projects -- set it up in an autoscaling group[2] for savings. I run https://runnerrental.club but Gitlab also recently release…

Multirepo pipelines behind a paywall is a good reason to say "No, thanks".

Multi repo pipelines are not paywalled? I can have one repo trigger jobs in another today, I've written about it a little bit: https://vadosware.io/post/fun-with-gitlab-ci/

Am I misunderstanding what you meant?

Re: Jenkins Is Getting Old

#318

Post by chupasaurus »

majkinetor wrote: post #314
chupasaurus wrote: post #285

Earlier quoted context omitted.

Multirepo pipelines behind a paywall is a good reason to say "No, thanks".

TBH, its easily done in shell via REST API. We use custom pipeline runner from simple Powershell scripts that works even better for us then default style. We set all jobs to manual and then our script triggers them depending on commit message, person, moon phase etc. But really, this should be in core. Its very hard to do multirepository stuff. Its not that easy to do mono repo stuff too - I really need a pipeline wi…

I know about this way, but it's basically building CI upon CI, doesn't sound good from any perspective.

Re: Jenkins Is Getting Old

#319

Post by aryc19 »

tterrace wrote: post #162
kalessin wrote: post #125

Earlier quoted context omitted.

Doesn't buildbot have dynamic workers implemented as latent workers? [1] What do you mean by underpowered buildbot steps? Are you implementing your own step classes? [1] https://docs.buildbot.net/current/manual/configuration/worke...

I'm not on buildbot nine (I think the new waterfall UI is a big regression), but what that is describing looks like a statically defined list of workers that scale up and down dynamically. What I'm looking for is the ability to add and remove workers at will, without having to add them to the configuration list and restart the master. In terms of underpowered build steps, I have several fairly complicated, 1k-2k line…

One way to scale up / down workers in Buildbot is to have more workers defined in the configuration than actually needed with generic names (e.g. worker1, worker2, etc) and then start / stop them when required.

Agree with you on the waterfall UI regression. It seems console view is preferred than waterfall in the recent versions. It's slower than waterfall UI though.

Re: Jenkins Is Getting Old

#320

Post by chupasaurus »

hardwaresofton wrote: post #317
chupasaurus wrote: post #285

Earlier quoted context omitted.

Multirepo pipelines behind a paywall is a good reason to say "No, thanks".

Multi repo pipelines are not paywalled? I can have one repo trigger jobs in another today, I've written about it a little bit: https://vadosware.io/post/fun-with-gitlab-ci/ Am I misunderstanding what you meant?

Answered to other sibling comment, could elaborate further for you though.

In order to pull other pipelines through Gitlab's API, you have to build another CI on top of an existing one. What I mean is that you're making the a pipeline to handle projects, but there's a catch - you have to run another pipeline to set the variables in the One pipeline to rule them all because you can't override variables from the jobs themselves! And the main pipeline would run a bunch of scripts to pass variables and handling the state.

Now let's compare that to other systems from my experience. Jenkins way: one Groovy script (might be written as a special job type from UI or through VCS) to do the job with some fancy features like pause to confirm the next step from the CI's Web UI, full control of everything. Teamcity way: either could be made from UI (with reverse dependency chain because you need to start connecting pipeline from the last jobs to first) or write yours from scratch with Kotlin DSL (there's still no direct support for pipelines[1]), you can handle the process through dependency settings and by setting variables from the jobs themselves. [2] An example of Teamcity approach. (black boxes are there because of my NDA)

[1]https://blog.jetbrains.com/teamcity/2017/02/kotlin-configura...

[2]https://imgur.com/a/jkid47J

edit: added picture.

edit2: added link to TC blog and rewrite the link to a screenshot.

Post reply on HN