Live data from Hacker News

Blue Ocean

jenkins.io

121–130 of 185 posts

Re: Blue Ocean

#121
This is nice! I've been looking for a way to schedule deployments of multiple code bases at the same time, with automatic rollback support. Does this support that?

Re: Blue Ocean

#122

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?

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…

[deleted]

Re: Blue Ocean

#124
I love to hate Jenkins. Such a nice (and remarkably simple, for what it accomplishes) piece of software.

I've tried to replace it so many times, and so many times come to realize what an asset it is.

Re: Blue Ocean

#125
post #95
post #67

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

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/gitlab-ce/issues/25866

Re: Blue Ocean

#126
post #96

This look nice, is there a hosted version of BlueOcean? I've been looking into (preferably hosted) pipeline-based CD options because simple CIs like Travis and CircleCi are not really meant true CD. What does everybody recommend?

Jenkins isn't really CD either. I'd suggest looking at GoCD or spinnaker, though you'd have to host both yourself.

You can get away with using any of the CI tools to just run through pipelines (heck, you can do this with fancy bash scripts if you're a real masochist ;), so I guess you could use any of jenkins, CircleCI or Travis to run a pipeline. I guess it'll depend on how much you really don't want to manage a CD server yourself.

Re: Blue Ocean

#127
post #21

Earlier quoted context omitted.

GitLab CI has proper Docker support. You can set a default docker image for each runner `--docker-image ruby:2.1` or set one for the project in the .gitlab-ci.yml file. For more information see https://docs.gitlab.com/ce/ci/docker/using_docker_images.htm... Did you know GitLab also comes with a private container registry? https://about.gitlab.com/2016/05/23/gitlab-container-registr...

Also notable is services like docker-in-docker (and privileged docker containers) are allowed, which is a huge win over services like Atlassian's Pipelines. Without dind, it's really hard/annoying to us CI/CD to build docker images. But with Gitlab, they also provide a place to store docker images (the "registry") right next to your code, for free! At work, we're investigating moving to Gitlab for everything except i…

Thanks for your kind words for GitLab! Our JIRA support is pretty extensive https://docs.gitlab.com/ee/project_services/jira.html but extending it further is a priority. Felipe Artur is working on this full time. Consider creating an issue for group level integration, it sounds interesting.

Re: Blue Ocean

#128

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?

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 need to install that in an already running Jenkins setup, no? Currently, both this and the bypassing setup wizard seem like hacks to me.

Configuration of a critical piece of your infrastructure should never be a hack.

Re: Blue Ocean

#129
post #98

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 can "apt-get install jenkins" and go straight to the webui. Or are you talking about restoring a configuration as well?

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 relies on NFS. Which is basically the same as no HA story. For a piece of critical infrastructure this is very bad.

- Startup time is horrendous. If you build an AMI and put it in an autoscaling group to attempt to get some vague approximation of HA, boot times often tend to be so long that you need to increase your warmup health check a ton so the autoscaling group doesn't kill the server in an infinite loop.

Sure, you can ssh into your server and apt-get install it, but really you should be writing automation and not doing setups by hand.

So while it's nice to see some effort focused on the UI, since Jenkins relies on it almost exclusively, there are a lot of other fundamental problems.

I always try to use anything other than Jenkins unless forced to.

Re: Blue Ocean

#130
post #43

Earlier quoted context omitted.

how are you deploying secrets to your kuberenetes CI pipeline ? for example on a build, you create (I'm assuming) a new namespace. it seems you are using glusterfs for your persistentvolumeclaim.. why not gce-pd ?

Juenkins' Kubernetes plugin allows to mount secrets like with usual pods so we deploy test secrets just like we normally do production ones. As for glusterfs, our Nginx reverse proxy also has a cron job that runs letsencrypt automatic renewal once a week so it needs to be able to write those new certificates. Because we need to be able to run several reverse proxies, all with write persmissions (we run one at a time,…

Oh wow. I have never used glusterfs on GCE - how difficult was it to set up and manage it ?

What about ceph ?

Post reply on HN