What does HackerNews think of Docker-OSX?

> At Apple things have gotten way worse. Trying to automate release building is practically impossible and will require hours or CI pipeline debugging with error messages that don't mean what they say.

This isn’t Apple’s fault… every build system sucks up a decent amount of time during initial setup. You can cut down massive amounts of time between iterations by adding some common optimizations:

1. Cache artifacts when that step or job succeeds, so if a subsequent step/job fails, you can adjust it and start up where you left off, using the caches artifact to restore the workspace state. This complicates debugging efforts and I personally don’t do any optimization until the pipeline is reliably green each time. I just deal with slow builds and switch to other stuff or work ahead while they run.

2. Fail fast. The CI run should bail out if any critical steps don’t pass, so anything further down doesn’t run for no reason, burning compute time and delaying queued jobs waiting for a runner. While developing the pipeline, watch the logs and when you see something you don’t like, slap the cancel button, or collect a couple things you need to change and iterate with passes with 2-3 changes.

3. Use adequately spec’s hardware. Xcode is resource heavy and compiles need plenty of memory and cpu cores. Play around with what is a good compromise between power and cost. See if your project builds faster with more cpu cores, or faster cpu cores, etc.

4. Cache build dependencies. Mac builds have cocoapods or something close to that, and whatever that package system pulls down can be reused between builds, just remember that cache issues are a pita to spot, reproduce, and regression test, so I’d again not add this in until you’re green.

5. Write your pipeline steps in a regular bash script. Then make your CI jobs and steps just execute the shell scripts. This allows you to develop them all locally, executing the script/step you need and then CI becomes just a wrapper to glue it all together and do some caching and optimization. The more of the process you can work on locally the less you have to run on CI and wait for. Once the scripts are all working locally, wire them into CI and see what breaks. ProTip: whatever breaks on CI due to missing software, deps, configurations, is going to break for any new hire engineer trying to get up and running, so document those things and make sure your getting started readme has them, and you’ll make new hires onboarding suck less :)

As for useful error messages, or lacktherof, I’d like to introduce you to programming, we’ve been waiting for you ;) but for real, useful error messages are the rare exception, and many apis are this way. That’s not to say it’s ok, but you kinda gotta learn to work around it. I’m sure there is enough context to point you in the right direction. Also, the errors might be from random pieces in your build pipeline and not necessarily from the actual Xcode build, so make sure you know what is erroring in addition to what the error is trying to say.

> At least Googles process is quite simple and can be dockerized.

One man’s simple is another man’s “practically impossible”. Simple comes from familiarity/exposure which builds knowledge and confidence. Anyway, you can totally run your builds in docker if you want to, and many do, but I’d personally not introduce more complexity until you have your pipelines running the slow way with the least amount of mental modeling to do. Once you know it all works, then have a go at running the build you know is good, inside a docker container (which in this case is just packing up kvm/qemu/libvirt to facilitate the running of a vm back on the host, but it means you can run mac containers on Linux runners, which will be much cheaper than Mac runners since those are usually Mac hardware)

https://github.com/sickcodes/Docker-OSX

> Also why do I have to pay Apple $125 a year when it costs $100 in the US? The exchange rate from CHF to USD should be in my favor.

Couple theories. 1. They have additional processing or tax expenses when dealing with your currency which they aren’t going to eat the cost of. 2. The higher price could be to deter abuse if for some reason there is an abnormal amount originating from accounts who pay with that currency.