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.
Beyond CI/CD: GitLab's DevOps Vision (2017)
51–60 of 72 posts
Re: Beyond CI/CD: GitLab's DevOps Vision (2017)
#52Earlier 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…
Re: Beyond CI/CD: GitLab's DevOps Vision (2017)
#53Is 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…
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)
#54I 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
Re: Beyond CI/CD: GitLab's DevOps Vision (2017)
#55I 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.
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."
Re: Beyond CI/CD: GitLab's DevOps Vision (2017)
#56Is 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.
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)
#57Slightly 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…
Re: Beyond CI/CD: GitLab's DevOps Vision (2017)
#58Earlier 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…
Re: Beyond CI/CD: GitLab's DevOps Vision (2017)
#59I 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…
Re: Beyond CI/CD: GitLab's DevOps Vision (2017)
#60Earlier 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.
https://docs.gitlab.com/ee/ci/pipelines.html#pipeline-graphs