Live data from Hacker News

Beyond CI/CD: GitLab's DevOps Vision (2017)

about.gitlab.com

51–60 of 72 posts

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#51

I don't get the beyond part, especially monitoring.... will Gitlab only have a Prometheus view in their UI or do they want to create their own monitoring? And when using own monitoring... this is a bit crazy... we have from day to day more and better Prometheus for that.

We're not going to create our own monitoring; we'll use Prometheus and other open source tools.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#52
post #43
post #39

Earlier quoted context omitted.

We're got some pretty complex pipelines, so much so that we've reached quite a few limitations. You can do all the things you've listed. But you can't build an arbitrarily complex DAG of tasks. Instead, you must order everything into a sequential list of 'stages'. Within a stage you have a list of jobs, which are run in parallel. This might be enough for your needs, but I'd like flexibility to express dependencies fo…

Can you nest stages? Say I want something like this: 1. Sequential: stage "build", build-type agent. 2. Sequential: stage "tests" (this is just a wrapper/container) 2.1 Parallel: stage "integration tests #1", integration #1-type agent 2.2 Parallel: stage "integration tests #2, integration #2-type agent 2.3 Parallel: stage "deploy and functional tests" (this is just a wrapper/container) 2.3.1 Sequential: stage "deploy…

It is with https://concourse-ci.org

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#53
post #2

Is anyone here using the Gitlab CI/CD for anything a bit more complex? I'm especially interested in a pipeline with parallel executions of different kinds of tests, maybe some manual checkpoint in there, a more complex chain with execution on different kinds of hosts or containers.

Last time I checked (a few weeks ago), Gitlab's CI/CD system is great for most use cases as long as you can describe your pipeline as a list of non-interactive tasks -- some of which may be parallelized -- that each can run in a Docker container. For one of the software projects I'm involved in, I have more complex needs. We release binaries for multiple platforms so our Jenkins master delegates certain tasks to slav…

> For one of the software projects I'm involved in, I have more complex needs. We release binaries for multiple platforms so our Jenkins master delegates certain tasks to slaves running on specific OSes. Then at the end the Jenkins master downloads the built artifacts from all slaves and publishes everything to our artifact hosting server. As far as I can tell, Gitlab CI does not support this.

GitLab CI/CD can certainly run jobs on different OSes, then have a final job consolidate those artifacts and publish to an artifact server. What part can't GitLab do?

> In future CI jobs I may even require user interaction, e.g. I may ask a human to sign off a report. I don't think Gitlab CI can do this.

GitLab CI/CD has manual jobs so a pipeline can wait for human sign off before proceeding.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#54

I would like to know what the goal for auto devops is... Will it be able to look at a project and compile it? For example: https://gitlab.com/postgres/postgres/-/jobs

Yes, it attempts to detect the language/framework, and build it. It doesn't work for all languages, and is based on Heroku buildpacks so has similar limitations. If autodetect fails, but some Heroku buildpack would work, you can specify it manually. Or, just include a Dockerfile and it'll build that instead.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#55
post #18

I like gitlab, but a mixed open source / closed source product is always going to be a challenge in terms of hearts and minds. Take this quote from the article. > The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source. So is all the stuff that gitlab builds on, like git, or ruby, or linux, that's all pretty advanced stuff I'd say.

Wow that really is a poorly worded phrase. If someone from GL is reading this, please fix that, it makes you look pretty bad. Just be honest and say you want to charge for advanced features, because there's little money to be made in open source and you're a business after all and want to pay your employees a living wage.

Yeah, that was poorly phrased, sorry.

One of the awesome aspects of being transparent by default: taking an internal conversation between three coworkers and making the recording and transcript public. I love being able to share our strategy publicly and talk about it openly.

While I can't change what I said, we can make the blog post more accurately reflect our beliefs as reflected on our Stewardship page[0]. There's no limit on what "deserves" to be open source. And, imho, GitLab has open sourced a ton of advanced functionality already.

But "GitLab Inc. is a for profit company that balances the need to improve GitLab Community Edition (CE) with the need to add features to GitLab Enterprise Edition (EE) exclusively in order to generate income."

[0] https://about.gitlab.com/stewardship/

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#56
post #6
post #3

Is it just me or is gitlab becoming more and more bloatware? Is it realy a good idea to bundle everything in one application? Why do i need an integrated artifact management with solutions like sonatype nexus? Is it worth it to add an "awesome environment for ops" on top of kubernetes? why add this complexity? Dont get me wrong, i like gitlab and use it since the beginning. I just have a problem with this "munch it a…

Gitlab in a way suffers from being open source. Their open source product is so good and includes so many features (even a full featured CI/CD pipeline!), that they need something big to justify their paid version. So I don't blame them. You can disable a lot of stuff that eats away your memory.

> You can disable a lot of stuff that eats away your memory.

Can you give some examples, and/or a link? I like using Gitlab as an easily portable, one-docker-container-and-you're-running hosting service, so it would be nice to make it more lighteweight.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#57
post #7

Slightly offtopic from what the article focuses on, but the thing that bothers me about all these built-in CI/CD things in software like Gitlab is that people seem to be perfectly content with building an artifact and then just ... pushing it out. In traditional deployments that may be some kind of "copy this thing over SSH and make it go!", in Kubernetes-land it's more like "lets just modify this API-state to point…

What about Helm?

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#58
post #43
post #39

Earlier quoted context omitted.

We're got some pretty complex pipelines, so much so that we've reached quite a few limitations. You can do all the things you've listed. But you can't build an arbitrarily complex DAG of tasks. Instead, you must order everything into a sequential list of 'stages'. Within a stage you have a list of jobs, which are run in parallel. This might be enough for your needs, but I'd like flexibility to express dependencies fo…

Can you nest stages? Say I want something like this: 1. Sequential: stage "build", build-type agent. 2. Sequential: stage "tests" (this is just a wrapper/container) 2.1 Parallel: stage "integration tests #1", integration #1-type agent 2.2 Parallel: stage "integration tests #2, integration #2-type agent 2.3 Parallel: stage "deploy and functional tests" (this is just a wrapper/container) 2.3.1 Sequential: stage "deploy…

Yes, that should be doable but not quite how you have it sketched out. See here: https://docs.gitlab.com/ee/ci/pipelines.html

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#59
post #24
post #18

I like gitlab, but a mixed open source / closed source product is always going to be a challenge in terms of hearts and minds. Take this quote from the article. > The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source. So is all the stuff that gitlab builds on, like git, or ruby, or linux, that's all pretty advanced stuff I'd say.

> The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source. Did they actually say that...? I only went to the page to confirm this and it appears true. Sounds like next time I choose self-hosted Github alternative, I should exclude Gitlab from my options - based on their approach so far, it feels like they really do mean this kind of contemptuous atti…

In your opinion, what is a valid reason for software to be non-open source? Sure, saying the software doesn't "deserve" to be open source might be a bit extreme, but I keep seeing the sentiment on HN that free and open source is the only allowable route and people who want to charge for their software are to be demonized. I'm curious under what circumstances you think it is allowable for a company to profit off of software their engineers were paid to write?

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#60
post #50
post #43

Earlier quoted context omitted.

Can you nest stages? Say I want something like this: 1. Sequential: stage "build", build-type agent. 2. Sequential: stage "tests" (this is just a wrapper/container) 2.1 Parallel: stage "integration tests #1", integration #1-type agent 2.2 Parallel: stage "integration tests #2, integration #2-type agent 2.3 Parallel: stage "deploy and functional tests" (this is just a wrapper/container) 2.3.1 Sequential: stage "deploy…

No, you can define jobs and stages. Stages run one after the others and all jobs inside the same stage will run in parallel, that's it, unless you start triggering remote jobs but then it becomes a lot let maintainable.

I don't have personal experience with this, but it seems to be that OP could have done this using their pipelines and maybe the graphs?

https://docs.gitlab.com/ee/ci/pipelines.html#pipeline-graphs

Post reply on HN