8 ms·
This looks like an improvement over what Jenkins 2.0 provides and I wish you guys good luck. I have used and vouched for Jenkins in several companies and some
by cfontes 8y ago
This looks like an improvement over what Jenkins 2.0 provides and I wish you guys good luck.
I have used and vouched for Jenkins in several companies and some decent sized licenses were bought mainly because of my input.
But to me, Cloudbees has done a major dick move making the stages not restartable in Jenkins 2.0, among other things. E.g: Dropping stage view out of nowhere and focusing only in Blue Ocean. I complained about in the channels that I had at the time and the response was, it's going to be unsupported from now on.
It's a super squechy thing to have such a useful feature bundled with a bunch of support and useless stuff that I don't care, and then charge me per node. I am migrating away from Jenkins into GoCD after close to 10 years using it, and don't get me wrong I don't feel happy doing this, but it's hard to justify it.
Fortunately the future looks bright, there are several interesting solutions available, Argo is super interesting to me, looking forward for Argo CD!
- oblio 8y agoThey've changed their mind because of the community backlash: https://issues.jenkins-ci.org/browse/JENKINS-45455 https://issues.jenkins-ci.org/browse/JENKINS-45455
- cfontes 8y agoThank you I did not know about that. Last time I checked with the sales guy it was not going to happen. I hope they improve their ways, it's a nice tool and I invested a lot of my time into it, but right now GoCD is my default option from now on.
- moritzplassnig 8y agoIf you have more feedback, I'm happy to connect with one of the PMs or somebody from the Jenkins OSS team. I'm the founder/CEO of Codeship and we got acquired by CloudBees earlier this year. And I want to make sure that Jenkins + all CloudBees products get better :)
- cfontes 8y agoI did not know about it, I actually own and use a couple t-shirts from you guys, Codeship is very nice! Congratulations to all of you! Last year I was in contact with the Jenkins team and had a couple of meetings to discuss the things mentioned above and some more. The developers where very nice and interested, I know they were doing their best but the problem was my problems where not top priority, and I saw some problems solved over the months but I completely lost my will to help when blue ocean started and Stage view was abandoned, the super dick move of restarting stages as well. It was not a small deployment mind you, the system was a critical one (payments) with multiple sites and all the works, not a small license as well, I left that company but before leaving we were already migrating away. We had a complete pipeline dependent on it, we were an early adopter of the whole JenkinsFile (A developer myself I pushed hard for it) and stage view even without being awesome was already part of our way of working. We wanted more features that I was already discussing and bugs fixed, out of the blue they change to a completely different thing that was pretty but didn't solve any of my old problems, and that will have it's own problems and was/is not even close to complete. I just feel I wasted my time, I don't plan to make that mistake again. But I hope Jenkins X can improve on the past mistakes and become a contender again.
- moritzplassnig 8y agoThank you :) Sorry to hear about those issues. I shared your feedback with a couple of people, and we will work hard on being more mindful when making such changes going forward.
- oblio 8y agoIf you're interested I could provide UX blockers and annoyances from someone who has worked with Jenkins for close to 10 years now. Most of them would be about the UX around declarative pipelines and the frustrations around Configuration as Code with Jenkins.
- moritzplassnig 8y agoThat would be awesome. Could you email me at mo@codeship.com? I will connect you with the right person.
- kohsuke 8y agoCreator of Jenkins & CTO of CloudBees here. Thanks for using Jenkins for close to 10 years and sorry to see you move on, but I just want to correct the record here because I don't think the time line of events and your description are accurate. First, pipeline stages have never been restartable in Jenkins from the beginning of Jenkins Pipeline. It wasn't as if we started with restartable stage and decided to close-source it at one point. From the very beginning, it was a feature we exclusively developed for CloudBees products. From time to time, we do move some features from products to Jenkins. As somebody later in the thread pointed out, in JENKINS-45455 we are doing just that. Another example of this from early days is the folders feature, which is now used by many. Any company building enterprise products on top of OSS will likely keep some features in products. And for any given person, only some of those features are likely useful. So while I understand the frustration of "that feature should be in OSS" or "I should be able to just get this one thing for a small price", I don't think there's anything inherently bad about these practices. As for Pipeline stage view, it is still available today, and IIRC it is also still a part of Jenkins 2 default experience. Now, you are right that, as a contributor of the project, CloudBees is focused on pushing Blue Ocean forward. We think Blue Ocean solves the problem of pipeline result comprehension a lot better, and we'd rather make one solution better as opposed to work on two separate things that solves the same problem simultaneously. That is not to block other people from carrying the pipeline stage view forward, though, if anyone is willing. I hope that helps,
- cfontes 8y agoHello there, thanks for building jenkins (or hudson?) you are an absolute hero. Feel free to correct me, here is my take on it. You are right the restarting in the declarative was not open, then closed. But I didn't say that, I said not having it was a dick move. My point is a Stage is just an alias for a Job (or multiple) for the regular Joe who doesn't work on Jenkins code. That was always restartable at any time in my pipelines (Delivery Pipeline Plugin, Build Pipeline plugin, etc...). So when we started writing the old and new pipelines as code we assumed the feature would be the same, while learning the new DSL at the time it was not clear that it was not, at least to us. Lot's of people thought the same the link below is an example of it. This was 2016 if I am not mistaken, it's now open source and congratulations for changing that as I said when it was pointed out to me, but I am not following the topic anymore. I have no problem with the business, as I said I vouched for it, and in the end they brought the licenses. My problem was, the main reason to buy it was not support or something juicy like Cloudbees cluster management features, It was that we wanted restarts. Is it bad? Absolutely not. But it's not something that made me feel happy. I just think it was not a thing I could easily communicate with the people making the decisions, was like punishing engineers for a problem that they can't solve, give managers a reason to buy it, Cluster management is a nice one, Automatic backups another, having miserable engineers is a terrible one. About Stage view, I was frustrated from training support and others to use it on a complex pipeline just to see a new tool take over and from what I remember it was a very fast switch. There was no gain in changing to Blue Ocean at the time, as our restarts where not working on it. So we had one UI that worked without support and another that didn't with it. Again I am not following it the topic anymore, so this might be fixed by now. https://issues.jenkins-ci.org/browse/JENKINS-33846 https://issues.jenkins-ci.org/browse/JENKINS-33846
- theptip 8y agoHow are you liking GoCD? I've been looking for an alternative to GitLab for a while.
- sytse 8y agoWhat can we improve in GitLab that would make you stay?
- kerny 8y agoNo OP, but IMHO GitLab is getting quite heavyweight and that's why people are looking for more lightweight alternatives.
- InternetOfStuff 8y agoSytse, thanks a lot for being present in the community. It's most appreciated, and I always look forward to your comments. With regards to your question: I agree with user kerny. Stop packing stuff on top. What I want from Gitlab is to use it to manage my repos. If you improve that aspect (which is already fine though IMO), you'll make me happier. If you improve Gitlab integration with other CI tools, you'll make me happier. If you improve your CI solution (which I found lacking when I evaluated it 1.5 years ago -- no idea how it's now), I still won't use it -- I explicitly don't want to rely on one, integrated solution. In my experience, such integrated solutions are fine for a while, until they aren't. My use cases tend to expand to things the integrated solution doesn't provide, and them I'm stuck. Do one thing, and do it well. Doing yet more things detracts from Gitlab's appeal. Personally, I wouldn't mind you utterly removing Gitlab's CI tool (I know, not gonna happen, and that's fine -- just saying).
- pas 8y agoGitLab does one thing. And GitLab CI/CD does one other thing. GitLab Image Registry does yet an other thing pretty well. And GitLab Omnibus also does one thing. (It bundles those.) Making it more configurable (as in makeing more features disable-able) would be nice though.