[swift-dev] Dockerized Swift, Build Times and Other Notes Regarding CI

[Max Moiseev]

Hi Tom,

> With docker compose, the following commands:
> 
>> docker build -t swift-dev-image .
>> docker create -it --name development -v /my/absolute/path/to/swift:/container/mount-point swift-dev-image
>> docker start -ai development
> 
> Become:
> 
>> docker-compose up

Fair enough (for some reason I’ve never thought of using compose for a single container, but it totally makes sense).
Let’s see what you’ll come up with! 👍

max

> On Dec 18, 2015, at 7:06 PM, Thomas Catterall <me at swizzlr.co> wrote:
> 
> Hi Max,
> 
> Thanks for your reply and encouragement! I will do just that.
> 
> Docker volumes allow you to specify volumes to mount inside the container; where this shines is mounting host directories into the container, so that one can edit files on the host and see the changes reflected immediately in the container.
> 
> Docker-compose does a lot of things, but in particular its benefit is that it can encapsulate a lot of configuration for a container. One example of that configuration is the above volumes feature, which is normally a pain to write out on the command line. Another is the usual dance of building an image, creating the container, and then starting and stopping it with the correct state. With docker compose, the following commands:
> 
>> docker build -t swift-dev-image .
>> docker create -it --name development -v /my/absolute/path/to/swift:/container/mount-point swift-dev-image
>> docker start -ai development
> 
> Become:
> 
>> docker-compose up
> 
> 
> In my research I have however discovered that this kind of mounting is quite flaky/nonexistent for certain docker hosts, in particular OS X, however there are indeed plugins for docker that use rsync to achieve the desired effect, so it's still quite doable. I'll look into it.
> 
> Regarding alternate systems, yes, that would be amazing! Docker base images are rarely reflective of general Linux distributions, so caution is needed when trying to apply them as a way of checking compatibility, but certain fundamental things are possible such as checking Ubuntu 14 vs 15, centOS, Debian, Fedora at a core level. It would be interesting, however, to create functional test suites using full distro base images (I'm sure they exist) that can then have the packages installed on them as a way of verifying a wide array of configurations in an automated fashion.
> 
> I think for now my objective will be to provide a quickstart docker image and docker-compose, using a metarepo with submodules to achieve the desired effects.
> 
> I would be very, very interested in hearing from Swift developers about ways of accelerating time to development by providing build intermediates.
> 
> Best,
> 
> Tom
> 
> Sent from my iPhone
> 
> On 18 Dec 2015, at 21:25, Max Moiseev <moiseev at apple.com <mailto:moiseev at apple.com>> wrote:
> 
>> I personally think it would be of great help to newcomers to have a containerized development environment to quickly start experimenting. Non-newcomers would also benefit from it by being able to test their changes on different versions of Linux, for example.
>> 
>> I would prepare a set of scripts and Dockerfile’s in a separate repo to start with, and at least add a link to it to Swift’s main ‘README’ via a PR to see what the community has to say. Maybe an extra paragraph in 'system requirements’?
>> 
>> On a slightly more technical note, can you elaborate a bit more on why you’d need a docker-compose? If only for volumes to be in a separate container… Maybe I’m missing something.
>> 
>> thanks,
>> max
>> 
>>> On Dec 18, 2015, at 12:34 PM, swizzlr via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> 
>>> Hacking on Swift
>>> 
>>> Just as it’s possible to build Swift in a docker container so too is it possible to actively develop the language in a Linux environment, while still benefitting from any local affordances you may have. If there is interest from the core team, I would be happy to contribute a meta-repo of Swift, submoduleing all the repos and supplying a docker-compose file which would enable developers to provision a development machine while being able to mirror local changes over to the machine. Similarly, “preheated” images could be built which would eliminate the need for a fresh build when first starting on the project.
>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151221/c693ec23/attachment.html>