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.
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.
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.
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.
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].
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.
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.
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.
https://www.replicated.com/
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.