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

Blue Ocean

jenkins.io

Post reply on HN
Print view View original

141–150 of 185 posts

Re: Blue Ocean

#141

Post by thinkmassive »

agibsonccc wrote: post #120

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…

I'm in a similar situation with needing to build ARM images on native hardware. Jenkins is great!

Re: Blue Ocean

#142

Post by mtalantikite »

corney91 wrote: post #138
mtalantikite wrote: post #129

Earlier quoted context omitted.

I'd guess the OP means restoring configs and the fact that Jenkins setups tend to turn into snowflake servers. Here are some issues: - State is stored on the filesystem across a bunch of XML files, rather than in a DB. - Configuration of Jenkins itself happens primarily from the UI rather than in config files. This makes it very difficult to provision automatically. - No HA story. Or there is a workaround and it reli…

I agree Jenkins isn't the easiest to automate but surely the fact that it's all XML files makes it easier than a database -- using config management you can install Jenkins and template out the necessary configuration file(s). I much prefer systems that use files instead of the db for configuration...

Configs should be in config files, state in a database. They are coupled in Jenkins and both are on the filesystem, mainly in XML files that are undocumented. Sorry if I wasn't clear about that.

Re: Blue Ocean

#143

Post by mitchty »

dserodio wrote: post #135
mitchty wrote: post #101

Earlier quoted context omitted.

The ansi output color plugin doesn't work with output. Nor the build timestamp plugin. The PR interface only works with Github, should also work with bitbucket pull requests. And the most annoying, when blue ocean is tailing a job thats running, it uses 100% cpu on safari. Those are the biggest issues I find with it as of today, otherwise its great for a manager mode until then.

> when blue ocean is tailing a job thats running, it uses 100% cpu on safari Also on Chrome and Firefox

Hadn't tried those yet but thanks for confirming its not just Safari! I was in a meeting and running a tail and wondering why my fan was going nuts.

Re: Blue Ocean

#144

Post by vorg »

karlmdavis wrote: post #115
kodfodrasz wrote: post #38

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?

FWIW, if you fight through the "undocumented features," Jenkins actually ends up being one of the best tools out there to manage via Ansible or whatnot. The Groovy/Java API for Jenkins is incredibly powerful, and by adding Groovy scripts to the /var/lib/jenkins/init.groovy.d/ directory, you can configure just about anything. Maybe this will be helpful? Here's the Ansible config I've built for a Jenkins deployment I m…

Apache Groovy also has "undocumented features", e.g. from your scripts:

  matchingSecret = secrets.find { secret -> secret.id == id }
can be written as:

  matchingSecret = secrets.find { it.id == id }
Those scripts look fairly basic, without any looping. Perhaps Java 8 with lambdas, or Kotlin could be used instead.

Re: Blue Ocean

#145

Post by msane »

i386 wrote: post #74
msane wrote: post #26

This looks great. After this the next step for Jenkins should be to change the name.

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.

Re: Blue Ocean

#146

Post by sytse »

agibsonccc wrote: post #120

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.

Re: Blue Ocean

#147

Post by sytse »

mi100hael wrote: post #137
petepete wrote: post #9

Earlier quoted context omitted.

I think the consensus is that Jenkins offers more power and flexibility at the cost being more complicated to set up. GitLab CI is easier to get up and running with and superbly integrated with GitLab (as one would hope).

I dunno, I found the opposite. Jenkins is an easy stand-alone package that I can just install & immediately navigate to the UI. GitLab-CI requires you to install & configure & link "runners" in a manner that I found less intuitive.

We're always interested in making that experience better. The reason that it is more complex than Jenkins in the first place is that we think the builds should happen on another instance than the one GitLab is running on. I've seen running the builds on the Jenkins machine lead to many problems. Hence the need for our process that we try to make easier than setting up Jenkina build slaves while still being secure when working on the public internet.

Re: Blue Ocean

#148

Post by swozey »

sytse wrote: post #125
swozey wrote: post #95

Earlier quoted context omitted.

The lack of arbitrary jobs in Gitlab is one of my huge pet peeves regarding it. I've used Gitlab-ee for a year now and really enjoy it for CI/CD stuff. But sometimes I want to throw up a quick shell job that is something super simple, like backing up a database, cleaning up docker images, things like that. I'm used to storing these in Jenkins/Bamboo so that they aren't left hidden on a server in a cron job. I can do…

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.

Re: Blue Ocean

#149

Post by bryanlarsen »

agibsonccc wrote: post #120

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…

Yup, we switched to Jenkins a while back for a similar reason. We're changing a bunch of our tooling for a new project because we can, but we didn't even consider switching out Jenkins. It's ugly but it works and it isn't worth figuring out anything else. The promise of Blue Ocean and the new declarative pipelines helps a lot although we probably won't bother trying it out until it's out of beta.

Re: Blue Ocean

#150

Post by jacques_chester »

agibsonccc wrote: post #120

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…

IBM engineers ensured that Concourse can run on linux/ppc64le. There are also Mac workers and, I believe (based on looking across the office to a Windows-facing team) Windows as well.

The only reason it's possible is because Concourse uses the Garden API for container management; in turn Garden can create real or I-can't-believe-it's-not-real containers for the target platform if there's a backend for it.

Post reply on HN