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

171–180 of 185 posts

Re: Blue Ocean

#171

Post by sytse »

merb wrote: post #159
sytse wrote: 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

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…

We spend a lot of development time fixing bugs. Over the last year GitLab has gotten a lot more stable. Of course it is not perfect and the rapid addition of new features creates new bugs.

The issue tracker is growing because we also keep feature proposals there.

GitLab CI doesn't poll the repository. The GitLab Runner does poll GitLab for new jobs. We're currently working on making sure that GitLab can deal with those requests more efficiently. Polling makes setting up Runners a lot easier for our users.

Not being able to retry half of your builds sounds very bad. Please contact support@ our domain and add a link to this comment to receive help with that.

It was a big thing to add CI to GitLab and we had a lot of concerns about it before we did so. But after doing it the improvements in the interface, CD functionality, Pages, review apps, auto deploy, and many other things convinced us that this is the right path.

GitLab will work with other tools but out of the box it will offer you a great experience. For the benefits of that please see https://about.gitlab.com/2016/11/14/idea-to-production/

Re: Blue Ocean

#172

Post by corney91 »

mtalantikite wrote: post #142
corney91 wrote: post #138

Earlier quoted context omitted.

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.

Ah, I see. Yeah, agreed on that one too then.

Re: Blue Ocean

#173

Post by sytse »

agibsonccc wrote: post #166
sytse wrote: post #146

Earlier quoted context omitted.

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.

We just don't use gitlab heavily enough yet :). We are mainly a JVM shop so the bias jenkins has for things like maven and what not out of the box is pretty appealing. I've been watching your integration play :). Maybe 1 day.

Thanks! I agree that great Maven support is key. We're working to integrate a package repository in https://gitlab.com/gitlab-org/gitlab-ce/issues/19095

Re: Blue Ocean

#174

Post by sytse »

mi100hael wrote: post #153
sytse wrote: post #147

Earlier quoted context omitted.

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 whe…

Interesting, thanks for the insight. Those are certainly valid reasons for things being the way they are, but I have to wonder how many GitLab installs are like mine: a single "git/build" server on a private network serving a small group of users. I'd wager the number of installs that fall into that category is fairly substantial, and in that situation the runner configuration feels pretty over-engineered.

I agree it is a tradeoff. It is very hard to make both local and remote easy. We opted to make the right thing the easy thing to do. That means it is harder to set up than Jenkins that default to local builds. But we hope the experience of https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma... is a lot easier than setting up build slaves in Jenkins https://wiki.jenkins-ci.org/display/JENKINS/Distributed+buil...

Re: Blue Ocean

#175

Post by mns06 »

dserodio wrote: post #155
msane wrote: post #26

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

It kind of did already. It used to live at https://jenkins-ci.org , and was moved to http://jenkins.io to communicate that it's not "only CI", but also CD.

It was also renamed once, from Hudson. https://en.wikipedia.org/wiki/Hudson_(software)#Hudson.E2.80...

Re: Blue Ocean

#176

Post by swozey »

sytse wrote: post #170
swozey wrote: post #148

Earlier quoted context omitted.

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.

If you use one 'catchall' repo for your random jobs you would only have to modify a file instead of creating a repo when adding a new job. Do you think this is acceptable considering the added convenience of having the job under version control?

So perhaps something like an infrastructure/tasks repo, then make various "environments" for assigning different env variables (like server IPs, etc). I'll fiddle around with this and see if its viable. I just really don't want to have to create a project/repo for every single little tiny task/report I want automatically done.

I like to run various reports, for example run a report monthly and diff my AWS/GCE firewall rules to show if anything that shouldn't have changed has changed then email if the there is a diff. Same with instance lists, load balancers, things of that nature. Then all of the server stuff, hourly snapshots using aws-cli or gcloud, yaddayadda.

Once the periodical thing is back in I can give that a shot. I've only used the travis style builds for about a year so I'm not very advanced with them. I think when I can do a when: monthly that will help greatly.

Re: ChatOps I've upvoted the ticket. I'd LOVE it if there was a slack: step that Gitlab could use that went beyond the checkboxes under integrations> - for instance I'd like the ability to echo whatever under a Slack step to a channel, for instance. I can do this buy making my own step, running a slack container and doing webhooks but that's clunkier than I'd like, especially when the GItlab server already has my slack tokens/etc. Right now I need to run a container that pulls that info to webhook to slack.

  slack:
    if: successful
    channel: deploys
    echo: "$buildtag has been deployed, you can access this      build at $server1 and $server2"
    curl: #posttodatadog "$buildtag released on $date"

Re: Blue Ocean

#177

Post by [deleted] »

oblio wrote: post #169
mtalantikite wrote: post #128

Earlier quoted context omitted.

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…

Jenkins is more than 10 years old :) Regarding plugins, you can just plop them in the plugins folder an start Jenkins.

[deleted]

Re: Blue Ocean

#178

Post by phaed »

oblio wrote: post #169
mtalantikite wrote: post #128

Earlier quoted context omitted.

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…

Jenkins is more than 10 years old :) Regarding plugins, you can just plop them in the plugins folder an start Jenkins.

What Jenkins should do is re-write all essential plugins as core functionality. That is one of the primary pain points people have.

Re: Blue Ocean

#179

Post by phaed »

oblio wrote: post #169
mtalantikite wrote: post #128

Earlier quoted context omitted.

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…

Jenkins is more than 10 years old :) Regarding plugins, you can just plop them in the plugins folder an start Jenkins.

What Jenkins should do is re-write all essential plugins as core functionality. That is one of the primary pain points people have.

Re: Blue Ocean

#180

Post by phaed »

anjc wrote: post #31

You'd have to imagine that the term Blue Ocean would be trademarked for contexts like this

Given the competition in the space, would it not be more aptly named Red Ocean?
Post reply on HN