Live data from Hacker News

Blue Ocean

jenkins.io

91–100 of 185 posts

Re: Blue Ocean

#91
post #25
post #19

Earlier quoted context omitted.

IMO moving from Travis to Jenkins seems like a very disruptive change. As for me, I had used Travis just a bit, and same for Jenkins, and didn't like any of those options very much. So when my team needed to setup a CI solution, we ended up using GitLab CI, and it brings the best of both worlds: - Free service version if you use the GitLab.com deployment (granted, gitlab.com is a bit slow because it's the new thing a…

Honestly my experience is that SaaS / hosted CI is just generally annoying due to constant stability and performance (both transient and in general, eg. caching in Travis) issues. Self-hosted CI on the other hand requires a lot of resources, especially when you're not only testing Linux or BSD, but proprietary OSes (OSX, Windows, although the latter at least has the Edge images that work everywhere). Ultimately I fee…

> Ultimately I feel like the use of CI in many open source projects isn't very high due to constant annoyances and difficulty debugging the CI environment.

My perspective may be driven by the communities I'm involved in, but this seems wrong to me. From my experience I would say most open source projects use CI, particularly because so many of the bigger platforms (Travis, Circle, CodeShip) make it free for open source.

It is an extremely valuable resource when you consider the infrastructure and integration you get with absolutely no effort. Installing more obscure libraries or cutting edge releases can be a pain, but it is minuscule compared to the time it would take to provision, secure, and manage a group of containers for an open source project.

Re: Blue Ocean

#92
This looks great. Not because of the aesthetics, but because it finally acknowledges that Groovy is absolutely useless for Pipeline. I want to try out this new workflow.

Re: Blue Ocean

#93
post #16

Seeing how much people recommend other solutions, I've actually moved from Travis to Jenkins, and never looked back. Yes, Jenkins has its issues (crappy UX, poor/awkward docs), but where it shines is the fact it's self-hosted, so I can SSH onto the instance to debug a failing build or replay it with a modified Jenkinsfile on the fly. I'm quite proud of the current setup we have; We're hosting our app with Google's Co…

We are doing the exact same thing and also couldn't be happier :)

Re: Blue Ocean

#94
post #63

Earlier quoted context omitted.

These pipelines do not imply moving away from Sidekiq. Have you tried using the Omnibus package? It contains logic to make sure restarting Sidekiq is automatic. How much memory does GitLab have and how many users?

Only 5 users. We are using Gitlab from Bitnami which I'm sure is using the Omnibus package. Maybe they configure it differently. I'll check, thanks.

The Bitnami package indeed doesn't include any of this. I strongly recommend switching to Omnibus.

From https://about.gitlab.com/installation/ "One-click installers are frequently out of date and might not contain our Omnibus packages. An example of this are the Bitnami packages in the past couldn't be updated and are now much harder to update than the Omnibus packages. We advise to not use one-click installers but instead start an vanilla Ubuntu instance and use the recommended Omnibus package installation. This is almost as quick as a one-click install and you're sure of the latest version and easy upgrades."

Re: Blue Ocean

#95
post #67

Earlier quoted context omitted.

The problem with travis and the like is most do not support arbitrary builds. Drone for example is trying to sell itself as a "jenkins replacement" but has no concept of a build triggering arbitrarily, or that isn't intrinsically linked to a git repo. It's nonsense. Once you set up a bunch of tooling jobs on Jenkins it's very nice to be able to use it as some form of control center for a bunch of different operations…

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 this by setting a manual build that I just run occasionally, but what if I forget to run it for months? In Jenkins I could say "run this job for no reason whatsoever other than the fact that 30 days has gone since it last ran."

This IMO is a huge use case for Ops. At this point I'll likely need to run Gitlab and Jenkins which I really don't want to have to do.

Re: Blue Ocean

#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?

Re: Blue Ocean

#97
post #36
post #16

Seeing how much people recommend other solutions, I've actually moved from Travis to Jenkins, and never looked back. Yes, Jenkins has its issues (crappy UX, poor/awkward docs), but where it shines is the fact it's self-hosted, so I can SSH onto the instance to debug a failing build or replay it with a modified Jenkinsfile on the fly. I'm quite proud of the current setup we have; We're hosting our app with Google's Co…

FWIW, Circle CI offers the ability to SSH in to build nodes and free nodes for public projects

...sort of. I eventually rage-quit Circle and set up a Jenkins cluster because of all of the heisenbugs we found on Circle. Builds would fail 5-10% of the time for totally unreproducible reasons (for example, pip install into a venv would fail with a permission error), and you can't SSH into a build that's already failed. We very rarely had problems with Jenkins builds, and when we did, we could go look at the environment it had run in and diagnose what went wrong. I love Jenkins and would absolutely choose it over a hosted solution.

(We also went from paying $1k/mo to $0/mo, which is a very nice side effect)

Re: Blue Ocean

#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?

Re: Blue Ocean

#99
post #49

Earlier quoted context omitted.

I'm not sure I get the "provision Jenkins part". Slaves "self install" once you have a working SSH connection and the master is just a bunch of XML files.

Have you tried setting up the jenkins docker image? I'd expect an experience where it works out of the box, or works out of the box after setting up some environment variables. Actual experience: you need to manually click a wizard, and set up an admin password, or google and find a hidden github issue of an ansible playbook with a workaround how to make jenkins startable for the first time unattended. Just a bunch o…

Not in docker, but I've setup a Jenkins cluster up using chef. I agree it should be easier, but it is possible today.

Re: Blue Ocean

#100
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

I think one thing GitlabCI lost in taking inspiration from Concourse (amongst other tools!) was the centrality of resources. It wasn't obvious at first why this is so important, I and most others fixated on the other visible differences (containers for everything, declarative config, pipeline view etc). There are a lot of features that don't need to be added to the core because they can be resources instead. For git-…

Concourse is great and it was certainly an inspiration for GitLab CI.

What I liked most and what we're still working on are cross project triggers https://gitlab.com/gitlab-org/gitlab-ce/issues/16556

The use of resources sounds cool.

Post reply on HN