Use NEXE to build single executable deployment of BIDS Validator CLI

[chrisgorgo]

https://github.com/jaredallard/nexe

It does not support crosscompilation, but Appveyor can be used for building Windows version. Linux version can be built on CircleCI. No solution for Mac OS X yet.

[chrisgorgo]

Some thoughts about multiplatform building using CIs (for electron, but still applicable) https://github.com/electron-userland/electron-builder/wiki/Multi-Platform-Build

[constellates]

I just added a PR for this issue. It uses nexe and builds and tests the executables on appveyor and circleci. Currently the executables get saved as CI artifacts.

We should probably add an automated release flow, but that might make sense as a separate issue. I briefly testing this https://github.com/aktau/github-release and it seems to be a good option. The one issue we may run into is race conditions when trying to release two executables from two separate CI systems.

Also I did test a binary built on linux/circle-ci and it seems to work fine on OSX. If you want some extra assurance they do have an OSX CI service now but it's not free or cheap https://circleci.com/pricing/#build-os-x .

[constellates]

One potential issue with this update is the nexe build adds 20-30 minutes to each CI run. We could move the nexe builds so they only run during deployment, but that would mean they're tested less.

[chrisgorgo]

TravisCI has free OS X containers we could use.

I wonder if it would make sense to create Releases manually via the GitHub interface. They could then trigger builds that would upload assets (compiled executables). See https://developer.github.com/v3/repos/releases/#upload-a-release-asset

[chrisgorgo]

This should work without problems. Main advantage of Circle is that the machines they provide are more powerful, but this does not matter much in context of this project.

On Wed, Oct 19, 2016 at 1:56 PM, constellates notifications@github.com wrote:

If it's not too much work and we want to take advantage of OSX containers it might make sense to move from circle-ci to travis. They also have built in github release tooling that looks pretty nice.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/INCF/bids-validator/issues/103#issuecomment-254938290, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOkp677dE2gn3U8wy52u8Y5EBy4ywaeks5q1oP-gaJpZM4H0eeH .

[constellates]

(oops I sent that last comment before finishing)

Then it might make sense to switch from circle-ci to travis if it's not too much work to move over. They also have tooling for github releases that looks pretty nice.

https://docs.travis-ci.com/user/deployment/releases/

As for manual releases, that could definitely work, but I'm not sure what we gain with manual releases vs just assuming any change to the master branch constitutes a new release. Either way we could trigger automated builds/releases/uploads.

[chrisgorgo]

Manual releases have the following advantages:

• no race conditions when uploading assets from multiple CI servers
• ability to provide semantic versioning and human readable changelogs
• no conflicts in package.json when multiple concurrent PRs try to bump the version number at the same time

The obvious disadvantage is that the process is more manual.

[constellates]

That makes sense and I think it will be easier to implement for now. I'll try to start testing this out soon. Let me know if you have a preference on the tag format for the releases otherwise I'll probably just start with "v" followed by the package.json version.

[chrisgorgo]

Yup - this sounds right.

On Thu, Oct 20, 2016 at 10:02 AM, constellates notifications@github.com wrote:

That makes sense and I think it will be easier to implement for now. I'll try to start testing this out soon. Let me know if you have a preference on the tag format for the releases otherwise I'll probably just start with "v" followed by the package.json version.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/INCF/bids-validator/issues/103#issuecomment-255166061, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOkpxYC5AIJhcUV8JVwbu_TE_dyW86dks5q156vgaJpZM4H0eeH .