HN user
I'm the Chief Product Officer at Replicated https://www.replicated.com/
I'm just a bit biased (I work for Replicated), but yeah, this is exactly what Replicated does.
I don't want to get all salesy here, but I'm happy to answer any questions you have, or connect you with folks for a demo, etc.
So that's what they've been doing with all the Heroku people they've been hiring.
Thanks for the suggestion. It spun out of a feature in our main product, but I admit that as a standalone project, it's a bit too broad of a name. It's already caused some confusion in the Kubernetes Slack.
Hi HN,
We (Replicated) are getting ready to launch a new open source project, Troubleshoot, and I'd like your early feedback. It's basically a set of two `kubectl` plugins that provide the ability to run preflight checks before installing an application and generate support bundles after installing an application.
It's been part of Replicated's products, but now we're making it available as a separate open source project in hopes that others may find it useful for their own projects, or even just for debugging your own Kubernetes clusters.
Thanks for bringing this up. As mentioned in our blog post on the subject (https://about.gitlab.com/blog/2019/07/30/gitlab-acquisitions...), we'll consider other types of acquisitions, but this is a streamlined process specifically for soft-landings. I've opened an issue to clarify this on the handbook page. https://gitlab.com/gitlab-com/corporate-development/issues/4
Also created https://gitlab.com/gitlab-org/gitlab-ce/issues/52779 to discuss not making Auto DevOps pipelines show failure at all.
FWIW, if you disable Pipelines and push another commit to the repo, you'll clear the failed icon from the project page. The project page only shows the last commit and the failed status is associated with the specific commit, not the project as a whole.
The profile page, however, doesn't seem to update. My guess is that it's a caching problem. I've logged https://gitlab.com/gitlab-org/gitlab-ce/issues/52780 for this.
That is weird behavior. Here's an issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/52778
Maven repository is coming in 11.3!
Definitely not. Presumably the gold subscription would be associated with a group for your open source projects, and your personal private projects would be completely separate (and free, just with Core functionality).
FWIW, if you created the connection between GitLab and GitHub for your project before 10.6, you'll have to remove the connection and then re-add it to get the push-based mirroring to happen. Otherwise, yes, it will still poll.
Thanks for pointing this out. Changed with https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/....
Advancedness is not a criteria in open sourcing or not open sourcing. There are advanced features that are open source, such as Review Apps[0]. There are basic features that are proprietary, such as File Locking[1]. The criteria we use to decide which version the features go in are documented on our stewardship page[2].
[0] https://about.gitlab.com/features/review-apps/ [1] https://about.gitlab.com/features/file-locking/ [2] https://about.gitlab.com/stewardship/#what-features-are-ee-o...
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."
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.
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.
We're not going to create our own monitoring; we'll use Prometheus and other open source tools.
From https://docs.gitlab.com/ee/install/kubernetes/, the best way to run GitLab on Kubernetes today is the gitlab-omnibus chart:
https://docs.gitlab.com/ee/install/kubernetes/gitlab_omnibus...
It's in beta, with some limitations on it's production-worthiness - basically that the Postgres Helm chart that it depends on isn't configured as well as the Postgres built into regular Omnibus.
I know it's confusing that we've got several charts, but we're trying really hard to reduce that down to one as quickly as possible.
My issue comment drafts are always persisted locally and not lost on refresh. Not sure why you're seeing otherwise. It is supposed to work that way. If you're seeing otherwise, please consider opening an issue.
Thanks for the feedback. Here's an issue to track the request: https://gitlab.com/gitlab-org/gitlab-ce/issues/14664 and I added it to our Missing features section with https://gitlab.com/gitlab-com/www-gitlab-com/commit/ddfc9ee1....
We're definitely doing a lot with Kubernetes, especially within CD, but it's not completely exclusive. We usually provide powerful primitives that can be used for anything, but make it easier if you're using Kubernetes.
Take monitoring for example. You can add Prometheus monitoring to (nearly) anything. But if you happen to use it with Kubernetes, we'll grab a bunch of data automatically. If not, you may have to configure it yourself.
We're not trying to replace your local editor. We know you love them. But there are still lots of reasons and situations where a web IDE is perfect and beneficial.
A web IDE is a great start, and as Sid already pointed out, at GitLab we'll ship an IDE deeply integrated with version control (and CI, CD, monitoring, etc.) in 2018.
But that only covers part of the problem. A lot of the post revolves around newer concepts of realtime as exemplified by Google Docs. Specifically I mean:
* Realtime
* Collaborative
* Versionless
An IDE is obviously realtime, but our focus is on single-user realtime, at least initially. CodeEnvy, Koding, and others have created shared editing environments, so maybe that's a pattern that works. But that still doesn't sound like what the author is really looking for. These are editing environments built on top of git so require the same branch and commit model. e.g. if you forget to commit your changes, anyone looking at the code outside of your (shared, collaborative, online) environment won't see it.
I've been wondering for a while what the next iteration of VCS (or DVCS) is going to be, and I have a hunch it will involve realtime.
What would it look like if the underlying VCS was realtime itself? If it worked like Google Docs?
I imagine it kind of like Google Docs's "suggesting" mode, where edits are shown on the mainline, but as suggestions which can be accepted or rejected. That's kind of like merging a merge request or pull request. But it doesn't seem to scale well. Imagine a doc with hundreds of simultaneous suggestions on the same code, especially stale suggestions that you aren't going to merge, but aren't ready to delete either. Would you switch between groups of suggestions/suggesters (like you would switch branches)? Would you just not work with long branches? I mean, that's an anti-pattern anyway. And don't even think about branches of branches or applying a patch to the last N stable branches. But if you're doing continuous deployment to a web product, those patterns don't apply anyway.
Would being forced to see all the suggestions trigger latent OCD and cause people to clean them up constantly? Or would it turn out not that bad because you're only seeing simultaneous changes on a single page at a time?
That brings up another challenge, changes that spread across many different files, but need to be considered together to make sense. Google Docs rarely have that problem. Maybe that means that it's inherently incompatible. Maybe it just needs a new solution we haven't seen yet. One idea comes to mind: the way recent editors show a mini-map of a file, and when you search, all search hits are highlighted on the mini-map. Extend that in some way so that when I'm looking at one suggestion, related suggestions are highlighted for me. I don't know, might be a dumb idea, but the point is that some thinking out of the box might solve this.
Google Docs (and realtime collaborative editing in general) were such a game changer that people flocked to it even though it was seriously under-featured compared to Word. Sure, tons of enterprises are still on Word, and there's a bit of a gap between companies that have embraced Docs or not. But for those that did, it's changed how we work. Keeping everyone in sync is far more important than having 10,000 options for making words follow a curve in 3D.
I wonder if some realtime version control, applied to code, will open up new ways of working we can't even conceive of today, and we'll slowly forget that we once loved the branch and commit model.
To be clear, you can do this with hosted GitLab.com as well.
Thanks! We're excited for you try it out too! And as always, send feedback or create issues for anything you see that needs improvement.
Thanks for the feedback!
As you know, we're constantly improving the performance.
There's an issue for CI performance (https://gitlab.com/gitlab-org/gitlab-ce/issues/21624), please add any specific feedback you have there.
For pipeline documentation, please consider creating an issue if you have any specific feedback. We'd love to know what we can improve there.
We do offer .gitignore templates, so I assume you mean to offer them during project creation. Please see https://gitlab.com/gitlab-org/gitlab-ce/issues/19468 and add any feedback.
That's a good point. We (GitLab) use it mostly as a templating system as well. It's a step up from piping `sed` output to `kubectl`. But we have our own tools for managing redeploys and rollbacks.
FWIW, the next version of GitLab's Auto Deploy will use Helm under the hood (and let you bring-your-own-chart).
FWIW, GitLab CI also has an agent architecture so you can run the build agents (which we call runners) on your own infrastructure, on Linux, macOS, Windows, FreeBSD, Linux ARM, Docker, etc.
Thanks for the feedback. Maybe next time we talk about it, we'll be more clear about the features.
That's great to hear; thanks for the feedback!