{"action":"created","issue":{"url":"https://api.github.com/repos/Project-OSRM/node-osrm/issues/126","repository_url":"https://api.github.com/repos/Project-OSRM/node-osrm","labels_url":"https://api.github.com/repos/Project-OSRM/node-osrm/issues/126/labels{/name}","comments_url":"https://api.github.com/repos/Project-OSRM/node-osrm/issues/126/comments","events_url":"https://api.github.com/repos/Project-OSRM/node-osrm/issues/126/events","html_url":"https://github.com/Project-OSRM/node-osrm/issues/126","id":122346024,"number":126,"title":"Stay in sync with osrm-backend more easily","user":{"login":"springmeyer","id":20300,"avatar_url":"https://avatars.githubusercontent.com/u/20300?v=3","gravatar_id":"","url":"https://api.github.com/users/springmeyer","html_url":"https://github.com/springmeyer","followers_url":"https://api.github.com/users/springmeyer/followers","following_url":"https://api.github.com/users/springmeyer/following{/other_user}","gists_url":"https://api.github.com/users/springmeyer/gists{/gist_id}","starred_url":"https://api.github.com/users/springmeyer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/springmeyer/subscriptions","organizations_url":"https://api.github.com/users/springmeyer/orgs","repos_url":"https://api.github.com/users/springmeyer/repos","events_url":"https://api.github.com/users/springmeyer/events{/privacy}","received_events_url":"https://api.github.com/users/springmeyer/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-12-15T19:24:47Z","updated_at":"2016-02-18T18:42:37Z","closed_at":null,"body":"Problem:\r\n\r\n - Currently osrm-backend development moves fast and node-osrm development is infrequent.\r\n - This means that any changes need to keep node-osrm working pile up and have more cost to debug/fix when the time comes to release a new node-osrm version\r\n\r\nGoals:\r\n\r\n - When osrm-backend changes (`develop` branch) we want to be notified if it breaks node-osrm `develop/master` branch\r\n - This will reduce the cost in keeping node-osrm working since we will have a timely sense of why the break occurred and on what osrm-backend commit.\r\n\r\nPotential solutions:\r\n\r\n1) Just check node-osrm into osrm-backend fully or as a submodule\r\n\r\n- pro: easy to do, could then re-use the osrm-backend build for building node-osrm against\r\n- con: makes osrm-backend travis runs more complex / add dependencies, requires all core developers know about node.js, builds node-osrm in an environment that is not portable/able to be published as binaries (without changes)\r\n\r\n2) Trigger rebuilds of node-osrm whenever the osrm-backend `develop` branch succeeds\r\n\r\n - pro: keeps clean separation\r\n - con: will require some extra orchestration between repos\r\n\r\nIt looks like this \"orchestration\" has been done before and we could try http://eng.rightscale.com/2015/04/27/dependent-builds-in-travis.html.\r\n\r\n/cc @TheMarex @daniel-j-h @danpat @mikemorris"},"comment":{"url":"https://api.github.com/repos/Project-OSRM/node-osrm/issues/comments/185853871","html_url":"https://github.com/Project-OSRM/node-osrm/issues/126#issuecomment-185853871","issue_url":"https://api.github.com/repos/Project-OSRM/node-osrm/issues/126","id":185853871,"user":{"login":"springmeyer","id":20300,"avatar_url":"https://avatars.githubusercontent.com/u/20300?v=3","gravatar_id":"","url":"https://api.github.com/users/springmeyer","html_url":"https://github.com/springmeyer","followers_url":"https://api.github.com/users/springmeyer/followers","following_url":"https://api.github.com/users/springmeyer/following{/other_user}","gists_url":"https://api.github.com/users/springmeyer/gists{/gist_id}","starred_url":"https://api.github.com/users/springmeyer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/springmeyer/subscriptions","organizations_url":"https://api.github.com/users/springmeyer/orgs","repos_url":"https://api.github.com/users/springmeyer/repos","events_url":"https://api.github.com/users/springmeyer/events{/privacy}","received_events_url":"https://api.github.com/users/springmeyer/received_events","type":"User","site_admin":false},"created_at":"2016-02-18T18:42:37Z","updated_at":"2016-02-18T18:42:37Z","body":"I've been thinking more about the two options above. I feel like option 1 is the ideal route.\r\n\r\nOption 2 of tying together travis builds would be brittle and not solve another key problem: locally developers of osrm-backend would benefit from instant feedback if refactoring has broken node-osrm (and not just depending on slow travis runs).\r\n\r\n@TheMarex - can you let me know what you think about my thoughts below and provide signoff on bundling node-osrm in osrm-backend?\r\n\r\n> pro: easy to do, could then re-use the osrm-backend build for building node-osrm against\r\n\r\nThis is proven and was dead easy to do and immediately reduced duplicated logic around test data setup. Prototype of pulling node-osrm into osrm-backend in process over at https://github.com/Project-OSRM/osrm-backend/compare/bundle. The things that were trimmed, for reference, are: https://gist.github.com/springmeyer/f958fe3bdde83244af34\r\n\r\nNext actions on this are to look into cmake integration so that we could actually compile node-osrm when you do `cmake ../ && make` (This would not be used for published node-osrm builds but rather to ensure build breakages are always obvious).\r\n\r\nAs far as the CONS previously sketched I'll break them now:\r\n\r\n> makes osrm-backend travis runs more complex\r\n\r\nBarely. The node-osrm build is very fast and light and the tests run quickly. So this will add minimal time and complexity overhead to the build times.\r\n\r\n> add dependencies\r\n\r\nOnly node.js which is easy to install on travis so this is not an issue.\r\n\r\n> requires all core developers know about node.js\r\n\r\nMy understanding is that we want to consider [having osrm-backend use Node.js/Node-osrm for faster testing](https://github.com/Project-OSRM/osrm-backend/issues/1973) so this is okay and ultimately an advantage.\r\n\r\n> builds node-osrm in an environment that is not portable/able to be published as binaries (without changes)\r\n\r\nThis is actually an advantage. Having node-osrm and osrm-backend tests both run using the same dependencies will help us debug failures quicker and in isolation.\r\n\r\nWe can then add a script that can be run locally and tested via a travis job that builds both osrm-backend and node-osrm against portable static libraries from mason (or some other source) so that we can:\r\n \r\n  - Have instant feedback whether those dep versions behave the same\r\n  - Have the ability to publish portable node-osrm binaries easily from an osrm-backend commit.\r\n\r\nOne gocha is that we don't want to have dozens of travis jobs building node-osrm for lots of node versions. To tame that complexity I propose node-osrm only support the latest Node.js LTS release. So we would have one travis job that builds and packages against node 4x.\r\n\r\n/cc @danpat @lbud"}}