I sat down to claw my way through blog posts, examples, and docker’s documentation to come up with a way to build and test Swift Package Manager on Linux as well as the Mac.
There are a number of ways to accomplish this; I will just present one. You are welcome to use it or not and any variations on the theme should not be difficult to sort out.
First, you’ll need a docker image with the Linux swift toolchain installed. IBM has a swift docker image you can use, and recently another was announced and made available called ‘swiftdocker‘ which is a Swift 3.0.2 release for Ubuntu 16.04. I riffed on IBM’s code and my previous notes for creating a swift development environment to build the latest master-branch toolchain into an Ubuntu 16.04 based image. If you want to follow along, you can snag the Dockerfile and related scripts from my vagrant-ubuntu-swift-dev github repo and build your own locally. The image is 1.39GB in size and named swiftpm-docker-1604.
SwiftPM is a bit of a special snowflake compared to other server-side swift software – in particular, it’s part of the toolchain itself, so working on it involves some bootstrapping so that you can get to the moral equivalent of swift build and swift test. Because of that setup, you leverage a script they created to get run the bootstrapping: Utilities/bootstrap.
SwiftPM has also “moved ahead” a bit and leveraged newer capabilities – so if you want to build off the master branch, you’ll need the swift-3.1 toolchain, or the nightly snapshot release to do the lifting. The current 3.0.2 release won’t do the trick. The nightly snapshots are NOT released versions, so there is some measure of risk and potential breakage – it has been pretty good for me so far – and necessary for working on SwiftPM.
On to the command! To build and test swiftpm from a copy of source locally
docker run -t --rm -v $(pwd):/data:rw -w /data swiftpm-docker-1604 \ /bin/bash -c "./Utilities/bootstrap && .build/debug/swift-test --parallel"
To break this down, since Docker’s somewhat insane about command-line options:
-tindicates to allocate a TTY for this process--rmmakes the results of what we do ephemeral, as opposed to updating the image-v $(pwd):/data:rwis the local volume mount that makes the current local directory appear as/datawithin the image, and makes it Read/Write-w /dataleverages that volume mount to make/datathe current working directory for any commandsswiftpm-docker-1604is the name of the docker image that I make and update as needed/bin/bash -c "..."is how I pass in multiple commands to be run, since i want to first run through the bootstrap, but then shift over to using.build/debug/swift-test --parallelfor a little more speed (and a lot less output) in running the tests.
The /bin/bash -c "..." bits could easily be replaced with ./Utilities/bootstrap test to the same end effort, but a touch slower in overall execution time.
When this is done, it leaves the “build for Linux” executables (and intermediate files) in the .build directory, so if you try and run it locally on a Mac, it won’t be happy. To be “safe”, I recommend you clear the .build directory and rebuild it locally if you want to test on MacOS. It just so happens that ./Utilities/bootstrap clean does that.
A few numbers on how (roughly) long this takes – on my mid-2012 MacBook Air
- example command above: 5 minutes 15.887 seconds
- using
/bin/bash -c "./Utilities/bootstrap test": 6 minutes, 15.853 seconds - a build using the same toolchain, but just MacOS locally: 4 minutes 13.558 seconds
Rhonabwy 