Consider adjusting pkg build system

[coxley]

Are there any related issues?

There have been issues this would have solved beforehand such as: #107 #455 #130 #307

What operating system are you using?

N/A

What version of N1 are you using?

N/A

---

From the sounds of it, Nylas is currently packaged for .rpm and .deb in addition to OSX and Windows. For rpm and deb, they are packaged on a system running a distribution that uses it. My proposal would be, for Linux, to use FPM which supports outputting in many package formats.

If it's something where N1 must be built directly on the distro it's being packaged for (dependency names, output dirs, etc), using Docker to run distro-specific build scripts on an image for that distro works.

I've had a lot of success with package repositories like:

• Root contains a Makefile with test_$distro targets and CI system calls these and upload packages that end up in /dist/$distro/
• Repo contains folders: ./dist ./scripts ./src ./docker/$distro/Dockerfile. Dockerfiles must install requirements for FPM and everything else to build your package
• Calling a test target depends on a build target to build that distro's Dockerfile. Once built, the test target run a container of that image with the following properties: volume mounting $PWD as /repo, run command /repo/scripts/$distro.sh
• The script should run any commands necessary for building your package, install it, and then do a couple things to test it worked like running --help. If this passes, move package into /repo/dist/$distro/. If not, exit 1

The above may not be the absolute best way but it's quite low maintenance and makes building for and maintaining packages for various distros easier.

[mbilker]

Actually it builds both the .rpm and .deb under Ubuntu 12.04 since the compilers do not vary much and Electron is not built in CI.

Have you had success with FPM on Travis CI? Would it integrate well into the Grunt workflow for building N1?

[mbilker]

I am interested in this as well.

[coxley]

I don't have a ton of experience with Travis but assuming Docker is available to you from commands. Looking at: https://docs.travis-ci.com/user/docker/

Instead of Makefile targets the /repo/scripts/distro.sh docker run's could be ran in a list like that? I still have been fond of that general way of going about it.

As far as Grunt goes, I'm not really familiar. :(

[bengotow]

Hey folks—we'd be really interested in using FPM to output many package formats from Travis. I'm not sure using Docker is necessary—as part of the build process, you can install things on the Travis box. Maybe we could just add it to the packages list here (https://github.com/nylas/N1/blob/master/.travis.yml#L10)? It seems like FPM enables all of those packages to be built from a single linux machine?

We run Travis builds for pull requests, so if you want to submit a PR and try it out that'd be awesome! I think you'd want to replace the mkdeb and mkrpm tasks in our build flow (which currently do all sorts of awful manual things) with a call to FPM (https://github.com/nylas/N1/blob/master/build/tasks/mkdeb-task.coffee#L6)

[mbilker]

I am in support of this and would like to work on it, but currently I am quite busy.

Cypher is getting Windows support worked on right now.

[coxley]

Running in containers is helpful if the build process is affected by distributions differently, otherwise it's moot yeah.

I'm quite busy too but if I get a nice block of free time and get motivated I'll try to take a look. Otherwise I think @bengotow summed it up nicely enough for another bystander to take a try!