161–170 of 185 posts
Earlier quoted context omitted.
Glad you think so! Not sure about the name change though - we're pretty attached to it!
I honestly think it holds the project back.
The end users of Jenkins are techies who dont really care about the name if the product does the job.
Earlier quoted context omitted.
I think there are two aspects to arbitrary builds: 1. Periodic jobs (not linked to a pushed commit) 2. Not linked to a git repo At GitLab we try to have 'infrastructure as code'. We think builds should be under version control to allow for collaboration. But periodic jobs make a lot of sense and it is discussed in https://gitlab.com/gitlab-org/gitlab-ce/issues/2989
well I know you have great idea's but sadly a lot of the focus of gitlab at the moment is either monetizing with EE (which I can understand, I need to develop for my income aswell..) and the other with adding features to CE (which of course leads to the first). Sadly this does not fix bugs. And the issue tracker of gitlab-ce grows and grows and the CI is not really stable. The new permission model was great, but brea…
My last note is on your mention of the growing issue tracker. The issue tracker is not only about defining bugs and problems, but also about idea exploration. To my knowledge the more GitLab will be known, the more it will grow. It is everyones best interest to let it flourish, but in an organised way. We are hard at work in that area as well! For example, we have dedicated Issue Triage Specialists which keep track and answer a lot of the newly created ones.
They should rethink the deployment model instead. You cannot provision jenkins unattended without 3rd party hacks and undocumented features. Until this is fixed I recommend avoiding it, as you'll get pet servers. This is totally retrograde to the devops mindset. Now why should I not use that mindset if that proves to be productive at other parts of work?
Bonus is that you did not have to use the awful Jenkins UI. Though Blue Ocean looks interesting
They should rethink the deployment model instead. You cannot provision jenkins unattended without 3rd party hacks and undocumented features. Until this is fixed I recommend avoiding it, as you'll get pet servers. This is totally retrograde to the devops mindset. Now why should I not use that mindset if that proves to be productive at other parts of work?
>You cannot provision jenkins unattended What do you mean by this ? what needs attending?
Earlier quoted context omitted.
What's wrong with Java?
Resource usage, especially RAM. And I say this as a longtime Jenkins admin.
https://jenkins.io/blog/2016/11/21/gc-tuning/ is the state-of-the-art / why doesn't Jenkins set all this by default.
Esoteric use case from someone in AI: Jenkins is the only CI we've been able to use even as an open source project due to needing gpus. CI and things like special hardware is a "semi-common" edge case and a big reason to have something self hosted. Referencing other comments here: We've also found periodic builds and arbitrary jobs to be a must as well. A lot of providers out there support most of the basic stuff out…
In GitLab CI you can use any machine for a build as long a you can install GitLab Runner on it. We kept the design of that simple with few dependencies and it is written in Go.
The new release of GoCD, 16.12, is also filled with amazing UI improvements. It's great to see Jenkins making Pipelines as first class citizens.
I'm a Concourse nut, which was partly inspired by GoCD. I'm not sure Jenkins is really making pipelines first class in the same way GoCD or Concourse do. In particular, there will be a painful period where some plugins work well and some don't, because plugins are difficult to cleanly compose. Disclosure: I work for Pivotal, which sponsors Concourse development.
Earlier quoted context omitted.
What's wrong with Java?
Restrictive licensing and then there's the fact it is a huge memory hog. I have Blue Ocean running on a home lab with 16GB RAM and Jenkins + SSH slave drains almost all the resources. Also - GitLab Travis / CircleCI etc being quite trendy/new remember that if you need to extend Jenkins you're dealing with a legacy product.
Something isn't legacy just because there's something newer out there. Or everything is legacy :)
Earlier quoted context omitted.
If I understand you correctly, you are talking about managing Jenkins configuration as code. For that, see * configure jobs as code ( https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin ) * system configuration as code ( https://issues.jenkins-ci.org/browse/JENKINS-31094 ) and its current prototype ( https://github.com/jenkinsci/system-config-dsl-plugin ) * bypassing setup wizard ( https://issues.jenkins-ci.or…
And this is one of the major shortfalls of the Jenkins mindset. Everything is a plugin and an afterthought from the main design of the system. Something as crucial as configuring the system should be a top design priority, not shoved into a plugin 5 years after the launch of the project. So, great, there is a plugin to deal with configuration. How do I bootstrap my infrastructure? If it's a plugin, it sounds like I n…
Regarding plugins, you can just plop them in the plugins folder an start Jenkins.
Earlier quoted context omitted.
Thanks for being a customer of GitLab EE and great to hear you enjoy the CD/CD stuff. Sounds like you really need the possibility to run job with a periodic interval. Does https://gitlab.com/gitlab-org/gitlab-ce/issues/2989 that I mentioned before address all you need? Chatops sounds cool, it would be nice to have a slash command to trigger a build. I've created a feature proposal for it https://gitlab.com/gitlab-org…
Periodic jobs is great for overnight regression testing, things of that nature and the few examples I gave above. That'll be a great (re)addition. But still, the ability to create random jobs like in Jenkins without having to create a repo, etc would be a huge plus along with easing ops teams into performing server maintenance via CI.