News for hackers. Stuff that matters.
Re:Moving to GitLab: Yes, it's worth it by Snappy on Friday August 05, 2016 @06:21PM (#12236102)
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...

Re:Moving to GitLab: Yes, it's worth it by bisby on Tuesday August 09, 2016 @02:16PM (#12256634)
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.

Re:Moving to GitLab: Yes, it's worth it by Snappy on Wednesday August 10, 2016 @12:45PM (#12263103)
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#...

Re:Moving to GitLab: Yes, it's worth it by bisby on Wednesday August 10, 2016 @03:59PM (#12264403)
Thanks, this looks like it describes my use case exactly. I'll have to read into this more!