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

301–310 of 340 posts

Re: Jenkins Is Getting Old

#301

Post by chinhodado »

cpitman wrote: post #226
chinhodado wrote: post #199

Earlier quoted context omitted.

I'm not sure that's what I needed. For example, I wanted to trigger a job only for a merge request, and only if the target branch of the merge request is e.g. master. Is that possible? Trigger a job only for a MR is possible, but I don't know how to further do the later branch filtering.

When using a merge_request pipeline, GitLab defines additional variables for the run. That includes `CI_MERGE_REQUEST_TARGET_BRANCH_NAME`. So it would look something like this: job: only: refs: - merge_requests variables: - $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

Oh wow I didn't know you can do conditionals with variable like that. I'll give it a try later, thanks!

Re: Jenkins Is Getting Old

#302

Post by boleary-gl »

kuschku wrote: post #273
jl-gitlab wrote: post #255

Earlier quoted context omitted.

GitLab product director for CI/CD here - thanks so much for the feedback, everyone. It's really great to read how much you're getting value out of what we built. We have an overall CI/CD direction page up at https://about.gitlab.com/direction/cicd which you can drill down into the individual stages plans from. Feedback is always welcome, we love building things in partnership with real users. You can reach me at jaso…

Have you started working on providing a UI for the XML test result artifacts produced in CI runs? They are displayed in merge requests but not anywhere in the normal CI pipeline UI and I'd live to be able to see those and see what works and what doesn't.

GitLab Product Manager for Verify (CI) here (who works for the Director above ).

Yes - that's something we want to get to this year. We call it "CI Views" right now but we want to expose better all the types of test results that get collected by GitLab. Today for XML (JUnit) results, you can see what fails in the merge request with https://docs.gitlab.com/ee/ci/junit_test_reports.html.

But we want to make the XML, JSON or HTML output of _any_ type of test first class with CI Views: https://gitlab.com/gitlab-org/gitlab-ce/issues/35379

Re: Jenkins Is Getting Old

#303

Post by boleary-gl »

paulcarroty wrote: post #269
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…

NO debug overs ssh, why I still use CircleCI.

GitLab Product Manager here

I'm not super familiar with Circle CI's SSH debugging, but we do have a feature called "Interactive Web Terminals" https://docs.gitlab.com/ee/ci/interactive_web_terminal/.

This allows you to connect to a terminal in the running job on GitLab CI for debugging. Would love to understand how this does or does not meet your use-case here.

Re: Jenkins Is Getting Old

#304

Post by kuschku »

boleary-gl wrote: post #302
kuschku wrote: post #273

Earlier quoted context omitted.

Have you started working on providing a UI for the XML test result artifacts produced in CI runs? They are displayed in merge requests but not anywhere in the normal CI pipeline UI and I'd live to be able to see those and see what works and what doesn't.

GitLab Product Manager for Verify (CI) here (who works for the Director above ). Yes - that's something we want to get to this year. We call it "CI Views" right now but we want to expose better all the types of test results that get collected by GitLab. Today for XML (JUnit) results, you can see what fails in the merge request with https://docs.gitlab.com/ee/ci/junit_test_reports.html . But we want to make the XML, J…

Yes, but that only works for the merge request view so far, are there plans to add a view of these to each CI job, so even if something on master fails, I can see the results?

Re: Jenkins Is Getting Old

#305

Post by tr-gitlab »

hardwaresofton wrote: post #77
Yhippa wrote: post #47

Earlier quoted context omitted.

I haven't checked out Gitlab in a long time. My, they've come a long way! I love a lot of what I'm seeing including the Web IDE and their bias towards making CI/CD a priority.

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 improvements you'd like to see made to the product.

Re: Jenkins Is Getting Old

#306

Post by oblio »

vorg wrote: post #300
oblio wrote: post #282

Earlier quoted context omitted.

Debugging Pipelines/Groovy is horrible. The stacktraces are horrible. You don't even get a line number for the error! Also, the documentation badly needs updates and examples. (Also, amusingly, we chatted a bit by mail on April 25th 2018, but there was no follow up on your side, I guess priorities changed...)

You can use the YAML-like declarative syntax [1] instead to configure the pipelines for 90% of what you do, and just use Apache Groovy for the more complex logic, or interfacing with plugins. [1] https://jenkins.io/doc/book/pipeline/syntax/

I am using the declarative syntax. It's just as horrible to debug. Play around with it a bit, delete some characters, misconfigure it. You won't even get a line number, just as I said.

Re: Jenkins Is Getting Old

#307

Post by digitalsushi »

jennbriden wrote: post #142

Hello, I see a lot of great feedback in this post. I am a product manager working at CloudBees, the primary corporate sponsor of Jenkins. Jenkins is now in the Continuous Delivery Foundation as well. While it is easy to bash on an inanimate object, there are some very dedicated and empathetic people who care deeply about the project. Some of those people do this work in their off-hours and some to this work as part o…

cloudbees shop here - i can say that because of how fragile the plugin environment is, we never, ever update our jenkins - we cant, we would spill money out the instant it went offline. so every few years we just roll out a new jenkins and force the devs to migrate to it, slowly, also over the course of years. every half a decade the cycle restarts. ok, we have been through exactly one of these, but it's a full cycle and starting up again. this has always been the biggest pain point, developers begging for a new plugin they cant have because updating a dependency is forbidden. so they either dont, or they do, by: making their own island ci/cd, or doing it so poorly, just as much risk comes into jenkins as it would rolling the dice on an untested upgrade.

Re: Jenkins Is Getting Old

#308

Post by jniedrauer »

sytse wrote: post #209
jniedrauer wrote: post #146

Earlier quoted context omitted.

Do you self-host gitlab? I'd definitely consider moving but it would also mean moving my source control.

If you are on GitHub you can use GitLab CI with that https://about.gitlab.com/solutions/github/

Oh, excellent. This is promising.

Re: Jenkins Is Getting Old

#309

Post by jdhzzz »

I work at a big enterprise that uses Jenkins. We support a large group of legacy applications and the waterfall type development processes that lately have been papered over with agile-lite. I work about 80% of the time administering (Cloudbees) Jenkins. I have lived through Freestyle projects, migrating to Job DSL, and now we are moving to declarative pipelines in shared libraries. I agree with 95% of the article's pain points. Still, I'm a fan, perhaps because each iteration is significantly less painful from the previous one.

Still Jenkins works well for us in our environment. Our waterfall style development processes make for ops-friendly, cookie-cutter type builds: one deployable asset per repository, one deploy target, all projects laid out the same way... Jenkins shared libraries provide powerful ways to capture the commonalities among the projects and provide a way for us to manage them centrally, while providing some (small) flexibility for customizations by the developement teams. Shared libraries also allow the ability to test changes using selected versions (branches) of the pipeline for specific builds. Looking forward to what's next (I still have a few mortgage payments to make...).

Re: Jenkins Is Getting Old

#310

Post by boleary-gl »

kuschku wrote: post #304
boleary-gl wrote: post #302

Earlier quoted context omitted.

GitLab Product Manager for Verify (CI) here (who works for the Director above ). Yes - that's something we want to get to this year. We call it "CI Views" right now but we want to expose better all the types of test results that get collected by GitLab. Today for XML (JUnit) results, you can see what fails in the merge request with https://docs.gitlab.com/ee/ci/junit_test_reports.html . But we want to make the XML, J…

Yes, but that only works for the merge request view so far, are there plans to add a view of these to each CI job, so even if something on master fails, I can see the results?

Not sure if it will make the first iteration (as merge request centric workflow will be "first")...but I agree the vision should include the ability to see the tests on any pipeline.
Post reply on HN