[mosh-devel] Mosh OS X package build on Travis

[john hood]

On 10/31/16 10:46 AM, john hood wrote:
> On 10/31/16 12:41 AM, Jim Cheetham wrote:
>> Quoting john hood (2016-10-31 17:12:06)
>>> Alas, we will not get any kind of repeatable builds out of this, Travis
>>> constantly updates their build images and we update to current Homebrew
>>> for dependencies on every build.
>>
>> That's the worst bit. Using external services that are *unlikely* to attack
>> your process is generally just fine, as long as there is a way to verify their
>> output.
> 
> The repeatability is of course no worse than what we've got now :)
> 
>> Perhaps you could use Travis to report in the buildability of a revision,
>> and the source of a 'nightly build' version, but keep a repeatable
>> build chain for official releases?
> 
> We already use Travis for CI builds on Linux and OS X.  I could of
> course maintain a build VM for Mosh releases and snapshot it for each
> release build, but having to maintain it (OS X upgrades, Xcode upgrades)
> for Mosh's fairly infrequent releases is a significant burden for a
> small project, and it would bring us full circle to manually-maintained
> private builds.
> 
> We can at least report the Travis image id (I think this is already in
> the build log) and the Homebrew version + Git revisions, and other tool
> versions.  Homebrew has a way to dump its configuration ('homebrew info
> --json=v1') which may or may not be complete.
> 
> The elephant in the room is that we're trying to improve builds for a
> binary-only, proprietary OS with relatively ad-hoc installation,
> configuration, packaging, etc.

I've had some more thinking on this, and I'm getting over the
you-piled-what?-onto-my-tasklist reaction.

There's a number of separate pieces to this problem:

* Fully automating the OS X build and installing its build deps.  This
is a pretty basic first step to all the rest of it, and what I am trying
to do with Travis.

* Reporting: describing exactly what was built, how it was built, what
dependencies were used, other environmental factors.

* Repeatability: getting the same thing twice in a row :)

* Reproducibility:  making it possible, maybe even easy, for you to get
the same thing out of a build that I did.

* Trusted build infrastructure:  in theory a reproducible build reduces
the need for this.  In practice...yeah, we should do that.

A lot of this stuff amortizes nicely if you are a distribution or
package management system.  We're trying to do just one package, only
for OS X (and not our many other platforms), and not even for all OS X
users.

My current OS X package manager of choice is Homebrew.  It seems they've
done some work towards reproducible builds internally, but it's not
clear at all how you might reproducibly install Homebrew, or do
non-Homebrew builds reproducibly with Homebrew deps.  I just put a query
out on that.

It would be nice if Homebrew or Macports or some other package system
could build standalone apps, and had reproducible builds.

Another alternative might be to abandon package managers entirely for
release builds, and build our dependencies ourselves.  Xcode might have
some useful capabilities in this area, I haven't looked.  This may
require separate, clean OS X instances for package builds.

This isn't going to happen instantly.  One approach to the trust issue
here might be to just cop out-- stop doing OS X package builds and tell
people to build their own, until we get this stuff into better shape.

Have I missed anything obvious?  (Yes.)  Have any of you got wisdom on
dealing with this stuff in an OS X environment that you can share?
(Please!)

regards,

  --jh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/mosh-devel/attachments/20161102/cc5be560/attachment.bin