I always use http://gitolite.com , thats enough. nb: I dont see the point of the graph about numbers of questions on SO. A high level of questions = A lot of problem, no :)?
gitolite + redmine = sweetness.
What’s Next for Gitlab CI: Auto DevOps
71–80 of 91 posts
Re: What’s Next for Gitlab CI: Auto DevOps
#72Earlier quoted context omitted.
I just updated the NixOS gitlab package from 8 to 9[0]. It was a nightmarish experience. There are 5 microservices : - gitlab (the core) - gitlab-sidekiq (a work queue) - gitlab-workhorse (provides the frontend) - gitaly (a git wrapper that caches stuff) - gitlab-shell (a shell spawned when doing your git clone) Those are written in either go or ruby. Sometimes mixing the two in the same repository. In the main gitla…
Please use the official Omnibus packages to ensure that upgrades are less likely to break. I think we use toml for the Runner since it is written in Go and should be deployed on another server. The rest is mostly in yml files although we trying to move as much as possible to the UI to make it more user friendly.
> Please use the official Omnibus packages to ensure that upgrades are less likely to break.
That would be almost precisely against the whole idea of NixOS.
Re: What’s Next for Gitlab CI: Auto DevOps
#73You know, this feature looks really cool, but the branding "Auto DevOps" seems like word-cloud clickbait and does not actually describe any distinguishing characteristics of the feature. DevOps is already a fuzzy area; what is Auto DevOps? It's at least another order of magnitude of semantic ambiguity.
Re: What’s Next for Gitlab CI: Auto DevOps
#74Pretty sure both GitHub Enterprise and BitBucket Server are the dominant self-hosted Git solutions.
You're directly contradicting the article. Got any evidence?
Re: What’s Next for Gitlab CI: Auto DevOps
#75Earlier quoted context omitted.
As GitLab user, I think the concern for me is split focus. For everywhere there's a tightly integrated built-in tool (issues, CI, container registry, etc), there also needs to be a separate, parallel effort to create, maintain, and document a sufficiently rich plugin interface that a third party can create a similarly tightly integrated experience when plugging in something external. Basically, they build the hooks b…
GitLab CI started as a separate project, but team saw more benefits from integrating into a single product as it's much easier to provide tightly integration without the overhead of communication and APIs. There are places in the workflow that can't just support a hook for an external integration. While CI is integrated, it does not force you to use it, and there are ways to integrate with external solutions. While C…
Sure, and I get all that— it definitely makes things easier for the creators and maintainers of the software, and it's easier to deploy it too, so it's a win for small shops who aren't yet committed to a lot of other tools, or are fine with being committed to an "omakase" experience where everything is okay and nothing is best-of-breed.
But there are definitely some customers who are sidelined by this approach. Atlassian is pretty committed to tools that talk to each other with documented APIs (Jira, Confluence, Bamboo, Bitbucket/Stash), and for large organizations, that's often a better fit.
Re: What’s Next for Gitlab CI: Auto DevOps
#76Earlier quoted context omitted.
A few things: I think you're using too much hyperbole -- it's all relative, and if you think Gitlab's UI is the bottom of the pile, you haven't used enough software and truly seen what bad UI looks like. I'm not saying UI doesn't matter, I'm just saying what they have is workable (and can get better, and they've expressed that they care to improve it). Email, IDE, Editors are not the same as your code hosting, testin…
> Email, IDE, Editors are not the same as your code hosting, testing, deployment tool Why should hosting, testing, and deployment be handled by the same tool (as opposed to tools that handle each need individually)?
That's a good question -- and of course, the answer is it depends. Having small focused tools is great, but that's only when the substrate/platform that lets you combine them is suuuuper good/standardized/well-designed.
`cat file.txt | sort | uniq` is excellent, but I think a lot of the ergonomics of that kind of small/focused tool reusability is due to the super low friction of using pipe, and how well STDIN, STDOUT, and STDERR work behind the scenes. This kind of falls apart when you try and string together web services.
In my opinion, Gitlab's inclusion of so many parts of the process is good because it saves you from having to manage all the other tools, and it gives you answers for the complete process (where it's possible you could get painted into a corner depending on which focused tools you picked to do some pieces of the process, and have to write your own glue or go on a long search).
Re: What’s Next for Gitlab CI: Auto DevOps
#77Earlier quoted context omitted.
I've used Gitlab for personal projects on a small homelab server. I ran the VM with about 1GB of Memory and 1 vCPU (a Core i3 if I recall correctly). Loading a page could load almost instantly but most of the time it did load after 2 or 3 seconds. Gitlab does not work well when resources are scarce, it does require a bit of a beefy server to get fast and reactive, atleast in my experience. I've found Gitea/Gogs to be…
Part of this is due to Gitlab's being a Rails app. Large Rails applications are many things, but resource efficient isn't one of them. It's just the nature of the language.
I wish they would rewrite it to something else. Yes, the app is very likely not CPU bound, but I just can't find myself believing in ruby+rails to ever be "fast". However, I'm also very biased against rails so I generally try to ignore the fact that it's a rails app.
Re: What’s Next for Gitlab CI: Auto DevOps
#78I always use http://gitolite.com , thats enough. nb: I dont see the point of the graph about numbers of questions on SO. A high level of questions = A lot of problem, no :)?
Yep, gitolite is awesome, it's so lightweight you can use pretty much any leftover PC to host repos for an entire company. I also use cgit for a fast and easy git web interface and ReviewBoard for code reviews.
If I remember correctly gitlab initially started as a frontend for gitolite.
Re: What’s Next for Gitlab CI: Auto DevOps
#79I always use http://gitolite.com , thats enough. nb: I dont see the point of the graph about numbers of questions on SO. A high level of questions = A lot of problem, no :)?
I really like gitolite, except how you need to add users and SSH keys through a git repository. I'd prefer just plain configuration files that I could manage with my configuration manager.
I've wasted so many hours trying to convince Windows user that they don't need any passwords for gitolite, they just need to check that Pageant is running and has the right key loaded :D
Re: What’s Next for Gitlab CI: Auto DevOps
#80For some reason, different parts of the Gitlab CI software expect different names for the runner binary-- possible names are gitlab-ci-multi-runner and gitlab-runner. If you set up a runner in a VM and want to upload artifacts, for some reason Gitlab CI requires you to install gitlab-ci-multi-runner on the VM guest (even though it is the host that is actually the runner). But when you do that, you have to actually go…
Thanks for your feedback, we're seriously considering all the input from the community, wherever it is coming from.
Talking about artifacts retention policy, we actually support defining an expiration date and we're also considering to add a maximum number in the future. You can find discussions about this topic in https://gitlab.com/gitlab-org/gitlab-ce/issues/23777 and https://gitlab.com/gitlab-org/gitlab-ce/issues/19208: in these issues there are also problems and consideration about having this feature implemented.
Feel free to jump in and push your ideas!