Are idempotent builds possible?

Is it currently possible to get idempotent builds with ember-cli and its dependencies (node,bower). If so how are people achieving this?

The craziness of the node dependency tree seems to make it implausible to check everything into source, not to mention compiled dependencies are different between our development environment and production since we can’t currently get ember-cli to work well on docker/containers.

➜  app git:(master) du -sh node_modules    
280M	node_modules
➜  app git:(master) du -sh bower_components
 12M	bower_components

can you elaborate on what this means?

Currently, if you do ember build ember build you will get identical output.

Are you more concerned about the fact that npm’s shrinkwrap feature doesn’t work correctly, so have reproducible builds across different machines has issues?

this is surprising, as I believe our CI uses containers …

@stefan sorry for the lack of clarity. I mean the entire build process for an ember-cli application, so a fresh checkout on a new developers machine or on our CI that includes a npm install and bower install step. When this occurs at any point in time X after the code is committed we have no guarantee of what is actually going to happen with the default setup.

This seems like a highly critical aspect of developing Ember applications (and any other npm dependent apps) in organizations that have something to lose(money, data,etc), so I am thinking some in this community have already solved this problem or at least duct taped it for the time being.

From my research the possible set of things people are doing:

  1. Checking in their node_modules directory.
  • This seems insane to me (size, compiled binaries, doesn’t actually give idempotency b/c of weirdness w/ npm rebuild)
  1. Using shrinkwrap
  • You and others say this is broken. I don’t fully understand the tradeoffs or how broken it is and in what way.
  1. Some shrinkwrap replacement
  1. shrinkwrap + some shrinkwrap enhancement library

I was speaking with @mixonic about this at last nights NYC meetup, and looking to lock down where this issue stands and what’s missing. My intention in starting this thread is to see if there is anyone out there in Ember-land using this stuff successfully, what are the pitfalls, etc.

On containers:

I think we could probably get our app to build on CI as well, but we would do so by dropping docker features that we want to use in development and do easily for every other app we work with.

My checklist is:

  • Use the ‘standard’ docker tools for dev on OS X. (docker-machine, docker-compose, boot2docker, virtualbox)
  • Mount my application code as a volume so I can edit it on my host machine (Mac)
  • Ability to cache dependencies so that I dont need to redo npm/bower install build step when I only change app code.
  • Build in a similar timeframe to building on the host machine.

If anyone has a Dockerfile they can share that achieves this that would be awesome. The specific hurdles we have seen are around virtualbox filesystem being very slow with the number of symlinks created while running ember server, and the inability to mount our application code because of the inclusion of node_modules and bower_components within the project path. File system events also do not get triggered within the container so we need to use --watcher=polling but that seems OK to me.

Moved this discussion here since it is a separate issue.

this is an NPM issue, we must raise with them. (It has but, that is the best venue for this discussion)

@stefan the purpose of my post is to seek the perspective of the community on how these issues are being resolved now in their organization in the context of their ember-cli and Ember.js investments.

I can’t imagine for example Square is OK with deploying an Ember app and not knowing whether what they build in their CI for deployment is the same as what their developers tested and intended to deploy.

From your perspective, why is shrinkwrap broken?

the primary reason is, the truth of node_modules tree lives in node_modules, but not in shrinkwrap.json. shrinkwrap.json is only consulted for new installations, not for syncing installs.

the last time I used shrinkwrap this scenario trolled me and my team constantly, if it is fixed now (maybe i missed this fix, lots of improvements in npm recent) then i will be extremely happy.

  1. Stef and Jake working on my-cool-startup
  2. Stef and Jake both have my-cool-startup checked out
  3. it contains RSVP 3.0.14
  4. Stef realizes this, and updates npm install --save 3.0.18 (and shrinkwraps)
  5. Stef pushes
  6. Jake pulls, does npm install
  7. Jake doesn’t realize, but because he already had RSVP installed, he did not get the one specified in shrinkwrap.json
  8. pain and bugs etc etc

Now, it is possible (assuming shrinkwrap) has no other bugs, and tests and extremely good for CI to benefit from shrinkwrap.json unfortunately it is bonkers that developers can troll themselves and each others with the existence of shinkwrap.json. I believe it must become the canonical truth.

So something we have done to slowly improve the npm dep issues, is use ember-cli-dependency-checker to assert that when you boot your app, that the dependencies you have are actually the ones specified in package.json. I believe we could extend this checker, to prefer shrinkwrap.json for its source of truth. This may be how we mitigate most of the shrinkwrap pains i have had in the past.