In case you would like to shave a couple of seconds off per build, you might want to build a docker image with both luarocks and love already installed.

This would also be a great reason to test the awesome GitLab Docker Registry[1], which is also included in CE!

[1] http://docs.gitlab.com/ce/container_registry/README.html

We're working hard on making CI super easy to use and setup.

If you want to give it a spin, check out our recent blog post on starting from 0: https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/

I was trying to look into Gitlab Runner the other day. How decoupled is it from Gitlab itself? Would I be able to somewhat easily write a completely different UI, with a different framework/language (say, Django), hook it all up to Github/Gogs and use Gitlab runner for the jobs themselves?

Because if that's what it is, that is pretty kickass.

The Runner interfaces with GitLab through a pretty simple API, so you could do that.

One caveat is that we might introduce a new API by releasing a new version of GitLab and GitLab Runner at the same time, then you would need to upgrade you project to stay compatible.

BTW To ensure nobody is confused, you can use GitLab Runner to test all kinds of projects on all kinds of hardware. We're discussing developing an alternative to GitLab but reusing GitLab Runner.

AFAIK you would not be able to do that. I've asked the author of Runner to comment here.

Im using Jenkins right now to basically handle docker deployments. Without taking the time to actually read up on it in depth, does GitLab CI handle ways for me to essentially just pull prebuilt images and run them on a targeted server with desired settings? I'm already preparing to move to GitLab CI for images that I build myself (since Im already storing the Dockerfiles on gitlab)

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

That seems to be referring to using docker images as part of the build process.

Im referring to using docker images as the deliverable. I mostly want to just have a gui to do "docker pull x" "docker stop xcon && docker rm xcon" "docker run --name xcon -v /volumes/x/config:/var/www/config -p 8080:80 x" for me. There would technically be nothing to be stored in the gitlab repo here, except the config.

Replace the "docker pull x" step with docker build in the event that I'm using a dockerfile to build a custom image, which could trigger as a result of updating the dockerfile... but usually the dockerfile doesnt change, it just needs to be re-run to pull in upstream changes.

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

Thanks, this looks like it describes my use case exactly. I'll have to read into this more!

We also have xonotic on GitLab, it's quite awesome :)

Would love to hear your thoughts on developing a game using GitLab, anything we can improve in that regard?

[1]: https://gitlab.com/xonotic/xonotic

Well, unfortunately I don't have many contributors yet, so I can't speak much to the collaboration features. The only thing I can think of is that it would be nice if it were easier to get CI failures announced in Freenode channels. I haven't looked into it in a while, but last I checked it was a bit tricky to hook up push events into IRC.

All the minor complaints I had a while back have been addressed (not showing the readme as the splash page, and not being able to reply to issue emails) so I've been quite happy with it.

I also appreciate how force-pushes to master are disabled by default. The fact that my browser's Emacs key bindings don't get stolen by the issue textarea to do stupid markdown stuff is very much appreciated. (glares fiercely at github)

Very interesting! I remember trying your game a few months back, but I didn't have the time to really get into it.

I was thinking about making a game in Löve for a while now, but I have never done any automated testing with it.

Is there a good tutorial for that? Or do you feel like writing one? ;)

I highly recommend using Löve; the simplicity is very compelling.

I wrote a bit about testing on my blog, but it's more about the architecture of how the user-input system meshes with the internal reprogrammability. There's a bit about fuzz testing though: https://technomancy.us/180

Maybe I'll follow it up with a more detailed post specifically about automated testing in Löve since it seems to be not well-understood.

Thanks for the link. More information about testing with Löve (heh, "with Love") would be wonderful, I'm only used to Enterprise Java, I'm afraid.

I was pretty impressed how easy it was for me (a server newb) to setup my own GitLab CI on a AWS server. For my projects now it takes around 15 seconds from when I push to GitLab for it to be deployed.

This made GitLab hosted repos well worth it for me over github or bitbucket:

https://about.gitlab.com/gitlab-ci/

We recently launched pipelines, it is in beta right now: https://bitbucket.org/product/features/pipelines