Snappy

10 ms·

1. 31.▲
   by Snappy 9y ago

   That's great to hear; thanks for the feedback!
2. 32.▲
   by Snappy 9y ago

   Great suggestion, thanks! Created https://gitlab.com/gitlab-org/gitlab-ce/issues/34248 to track.
3. 33.▲
   by Snappy 9y ago

   A new issue on the CE issue tracker is usually the best place. https://gitlab.com/gitlab-org/gitlab-ce/issues/new
4. 34.▲
   by Snappy 9y ago

   I'm curious what you'd expect CI to do regarding running backups. Starting in 9.1, you can run CI pipelines on a schedule, so you could have nightly backups triggered by a CI job, but I would think there are better ways to handle
5. 35.▲
   by Snappy 9y ago

   Ah, I think I understand the confusion now. I guess you're wanting to do something like `helm install https://github.com/some/url` and that doesn't work. But I was assuming you were consuming the chart in the
6. 36.▲
   by Snappy 9y ago

   `helm install path/to/chart/directory`
7. 37.▲
   by Snappy 9y ago

   You don't have to publish the chart. Installing from a directory in a GitHub repo works fine.
8. 38.▲
   by Snappy 9y ago

   I hope eventually you can use environment-specific variables[1] in GitLab to manage your deploy variables. [1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20367
9. 39.▲
   by Snappy 9y ago

   You're not alone and it's great to see others thinking this way. We're looking at making it easier for people to bring-your-own-helm-chart[1] and have GitLab deploy it. There's value in keeping the chart in the project r
10. 40.▲
    by Snappy 9y ago

    Yeah, I'd think you'd want to take advantage of specifying the image tag as a variable rather than committing the image tag back to the repo. Kind of defeats the point of helm to hard code everything. :) Only bump the chart versio
11. 41.▲
    by Snappy 10y ago

    We're hoping to work with the community to support all container schedulers [1]. But right now we're focused on deepening the integration on Kubernetes so it's a great end-to-end experience. [1]: https://gitlab.com
12. 42.▲
    by Snappy 10y ago

    The video in the blog post is all on Kubernetes as well, ans shows off terminal, deploy boards, and monitoring; all on Kubernetes. It doesn't go into detail, of course, but it's great if you just want to see it.
13. 43.▲
    by Snappy 10y ago

    Thanks for that, lotryn, that might be my favorite quote today.
14. 44.▲
    by Snappy 10y ago

    Really glad to hear that! We're really excited about this direction and think it'll be a game changer for DevOps. Of course there's more to come. Take a look at our direction[1] and join in the discussion! [1] https:/&#
15. 45.▲
    by Snappy 10y ago

    I haven't played much with Rancher, but I'm really curious about it. I'd like to hear more about your setup. Perhaps you could even contribute a post on setting it up with GitLab CI?
16. 46.▲
    by Snappy 10y ago

    At least you're polite and well-spoken.
17. 47.▲
    by Snappy 10y ago

    Great feedback, thanks! This isn't exactly what you asked for, but we're seriously considering letting you "include" CI configuration from a central location. https://gitlab.com/gitlab-org/gitlab-ce&
18. 48.▲
    by Snappy 10y ago

    Wow, thanks for the kind words. GitLab has grown a LOT in the last year or so.
19. 49.▲
    by Snappy 10y ago

    > We're using their free hosted service, and so I'm reticent to ask for these sorts of changes by opening issues unless I want to at least attempt to contribute the code for it. Please feel free to open issues anyway. We love h
20. 50.▲
    by Snappy 10y ago

    You can also switch your container registry to use S3, which might be more cost-effective. I'm not positive if GitHost.io supports that, but it likely does.
21. 51.▲
    by Snappy 10y ago

    There's an issue for that[1]. :) Add your vote if interested. [1]( https://gitlab.com/gitlab-org/gitlab-ce/issues/18054 )
22. 52.▲
    by Snappy 10y ago

    Sure, just sent you an email.
23. 53.▲
    by Snappy 10y ago

    GitLab is a remote-only company, so really, we're EVERYWHERE! There's still a NL entity, but now there's a US entity, and maybe more countries coming. I can't comment whether Sid had to move to the Valley to reach inve
24. 54.▲
    by Snappy 10y ago

    For a discussion on caching and artifacts, please see https://gitlab.com/gitlab-org/gitlab-ce/issues/21913 .
25. 55.▲
    by Snappy 10y ago

    Thanks for clarifying. I'm pretty sure you can do everything you want here. You could install a runner on your production box and run those commands within a deploy job. Two options for configuring the runner: 1: http://docs
26. 56.▲
    by Snappy 10y ago

    And with Heroku's beta support for Docker deployments, it's even easier.
27. 57.▲
    by Snappy 10y ago

    Yes, using prebuilt images is easy. Basically, just add `image: ruby:2.3.1-alpine` to a job, for example. Docs: http://docs.gitlab.com/ce/ci/docker/using_docker_images.html...
28. 58.▲
    by Snappy 10y ago

    Great! Let us know if you have any feedback after you've tried them out.
29. 59.▲
    by Snappy 10y ago

    Great feedback! You might want to take a look at upcoming Issue Boards ( https://gitlab.com/gitlab-org/gitlab-ce/issues/17907 ) and see if that works for you.
30. 60.▲
    by Snappy 10y ago

    Priority labels aren't enough for you? ( https://about.gitlab.com/2016/06/22/gitlab-8-9-released/#pri... ) We're using P1, P2, etc. internally, but you could easily use `urgent` and `high priorit