Hi Tony, Thanks for the additional information, very insightful! I agree we shouldn't impact people's workflow if it can be avoided.
The approach of keeping a separate repo/package for building Docker artifacts is the one we started with. It allows the DevOps team more flexibility but it's a bit "detached" from the developer's main workflow. That being said, it's now usually preferred to have the Dockerfile with the app repo so everybody is working with the same configuration that will be shipped to production. Some discussion about this: https://github.com/GPII/universal/pull/327 In this case this is a minor issue we can adapt in the automation layer without much effort (as it seems this step is only required for development). Thank you, Giovanni On 07/04/2017 05:23 AM, Tony Atkins wrote: > Hi, Giovanni. > > Although in my own work I would probably choose to make this a "pretest" step > (and possibly a "prepublish" step as well), I know lots of us prefer to open > the browser tests that can run in a plain old browser in a plain old browser > (perhaps with MAMP or python hosting the content). Moving this out of > "postinstall" would require people who work that way to know about and > execute a particular step beforehand, and we should only do that if we either > can't avoid it, or if enough people agree to live with the extra step. > > In this case, it seem like a bad idea to copy over part of a repository and > then expect its scripts to work at all. How are people supposed to know that > the next required postinstall step they add is or isn't acceptable for your > work with Docker? How are they supposed to know whether any of the code > they're writing will have its dependencies, configuration files, et cetera in > Docker? To me, this seems like the kind of thing that should either be > handled: > > 1. In a separate package that takes care of bundling up content for Docker, > with its own tests and versioned dependencies. > 2. In the packages being bundled for release, with tests that verify that the > Docker image passes some subset of the existing tests (i.e. the node tests). > > My gut feel is that the first is cleanest, but I can also see this being the > kind of thing that lives at some higher level, like as a script and tests > within the monorepo project. > > Cheers, > > > Tony > > On Mon, Jul 3, 2017 at 5:12 PM, Tirloni, Giovanni <[email protected] > <mailto:[email protected]>> wrote: > > Hello, > > While working with our Docker containers I noticed the "postinstall" > step started to fail if the whole repository wasn't copied at build time: > > ---- > $ node scripts/browserifyTestDependency.js > module.js:487 > throw err; > ^ > Error: Cannot find module > '/home/node/node_modules/universal/scripts/browserifyTestDependency.js' > ---- > > > Not copying the whole repository allows us to cache Docker layers more > efficiently. However, it means things like browserifyTestDependency.js won't > exist at `npm install` time. > > I would just like to confirm if this is a pure dev dependency that can > be ignored for production images. If that's the case, I'll use > `--ignore-scripts` to bypass the 'postinstall' scripts. > > Alternatively, could this step be transparently moved into any of the > 'test' scripts? > > Thanks, > Giovanni > > _______________________________________________ > Architecture mailing list > [email protected] <mailto:[email protected]> > http://lists.gpii.net/mailman/listinfo/architecture > <http://lists.gpii.net/mailman/listinfo/architecture> > > _______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
