Snappy

Great suggestion, thanks!

Created https://gitlab.com/gitlab-org/gitlab-ce/issues/34248 to track.

A new issue on the CE issue tracker is usually the best place.

https://gitlab.com/gitlab-org/gitlab-ce/issues/new

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 that.

Now if you're following infrastructure-as-code, and your backup and other configurations are saved in version control, then of course GitLab supports that, but that's not explicitly GitLab CI.

GitLab CI does support deployment histories, easy rollback, etc.

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 same repo, or including it via a submodule, such that the chart would be a local file reference.

Sorry for the confusion!

To use a URL, I think you'd either have to push up the packaged chart as a .gzip file in your repo (which is annoying), or you'd have to package up the chart and create a GitHub release with the resulting gzip file to be able to reference it that way. In GitLab you might be able to point to a pipeline artifact[0] after packaging the chart using GitLab CI.

In one experimental project[1], I'm using GitLab Pages to package and publish the index. It works out surprisingly well, but has some shortcomings.

[0]: https://docs.gitlab.com/ce/user/project/pipelines/job_artifa... [1]: https://gitlab.com/charts/charts.gitlab.io

`helm install path/to/chart/directory`

You don't have to publish the chart. Installing from a directory in a GitHub repo works fine.

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

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 repo, and there's value in decoupling the chart and putting in a different repo. I'm fascinated to see which becomes best practice.

[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/29969

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 version when the configure itself (outside of the image tag) changes.

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/gitlab-org/gitlab-ce/issues/20199

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.

Thanks for that, lotryn, that might be my favorite quote today.

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://about.gitlab.com/direction/#deploy

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?

At least you're polite and well-spoken.

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/issues/20868

Wow, thanks for the kind words. GitLab has grown a LOT in the last year or so.

> 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 hearing directly from users and always want to improve the product, even if you don't pay for it or contribute code. :)

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.

There's an issue for that[1]. :) Add your vote if interested.

[1](https://gitlab.com/gitlab-org/gitlab-ce/issues/18054)

Sure, just sent you an email.

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 investors, but it probably didn't hurt. That and YC.

For a discussion on caching and artifacts, please see https://gitlab.com/gitlab-org/gitlab-ce/issues/21913.

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.gitlab.com/ce/ci/docker/using_docker_build.html#...

2: http://docs.gitlab.com/ce/ci/docker/using_docker_build.html#...

And with Heroku's beta support for Docker deployments, it's even easier.

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...

Great! Let us know if you have any feedback after you've tried them out.

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.

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 priority` labels and then sort your lists by `Priority`.

First off, I'll admit our documentation for caching needs improvement.

We do support caching of gem's and other file artifacts. There are tricks about file locations, but once you get the hang of it, it works well. See https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Ruby... for an example for Ruby. It's actually one of the sources for our new CI configuration templates!

But sometimes, you don't really want caching, you want artifacts. Caching is an optimization, but isn't guaranteed to always work, so you need to be prepared to regenerate any cached files in each job that needs them.

Artifacts, on the other hand, are guaranteed to be available. It's sometimes confusing because the name `artifact` sounds like something that is only useful outside of the build, like for downloading a final image. But artifacts are also available in between stages within a build. So if you "build" your application by downloading all the required modules, you might want to declare them as `artifacts` so that each subsequent stage can depend on them being there. There are some optimizations like declaring an expiry time so you don't keep artifacts around too long, and using `dependencies` to control exactly where artifacts are passed around. Again, complicated subject that is poorly documented. I'd be happy to help you figure it out for your use case (and then publish the learnings).