FWIW, and in case it helps anyone, I ran into an issue running the
tests on the universal master branch. I reliably got an "error code
ELIFECYCLE". For more details (such as they are), I've copied part of
the error log at the end of this email.
Googling the problem led to general advice to have a clean copy of the
code. Here's the cleaning operations, in sequence, that fixed the
problem. Note that all commands are issued at the "universal" directory.
1. Delete "node_modules"
2. Do git garbage collection: 'git gc --aggressive'
3. Make sure there are no files unknown to git, or, if there are, that
they are unrelated to the code. For example, on macOS the
".DS_Store" files are harmless.
4. Verify/clean the npm cache: 'npm cache verify'
5. Install a fresh copy of node_modules: 'npm install'
After that, running the tests worked for me. For example: 'npm run
test:node'.
Hope that useful.
Part of the log that shows the error:
...
13 verbose stack Error: gpii-universal@0.3.0 test:node: `node
node_modules/nyc/bin/nyc.js node tests/all-tests.js`
13 verbose stack Exit status 1
13 verbose stack at EventEmitter.<anonymous>
(/Users/clown/.nvm/versions/node/v8.10.0/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:285:16)
13 verbose stack at emitTwo (events.js:126:13)
13 verbose stack at EventEmitter.emit (events.js:214:7)
13 verbose stack at ChildProcess.<anonymous>
(/Users/clown/.nvm/versions/node/v8.10.0/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack at emitTwo (events.js:126:13)
13 verbose stack at ChildProcess.emit (events.js:214:7)
13 verbose stack at maybeClose (internal/child_process.js:925:16)
13 verbose stack at Process.ChildProcess._handle.onexit
(internal/child_process.js:209:5)
14 verbose pkgid gpii-universal@0.3.0
15 verbose cwd /Users/clown/Development/GPII/node_modules/universal
16 verbose Darwin 17.4.0
17 verbose argv "/Users/clown/.nvm/versions/node/v8.10.0/bin/node"
"/Users/clown/.nvm/versions/node/v8.10.0/bin/npm" "run" "test:node"
18 verbose node v8.10.0
19 verbose npm v5.6.0
20 error code ELIFECYCLE
21 error errno 1
22 error gpii-universal@0.3.0 test:node: `node
node_modules/nyc/bin/nyc.js node tests/all-tests.js`
22 error Exit status 1
23 error Failed at the gpii-universal@0.3.0 test:node script.
23 error This is probably not a problem with npm. There is likely
additional logging output above.
24 verbose exit [ 1, true ]
On 2018-03-14 1:55 PM, Tony Atkins wrote:
> Sorry! Forgot to include the list!
>
> T
>
> ---------- Forwarded message ----------
> From: *Tony Atkins* <t...@raisingthefloor.org
> <mailto:t...@raisingthefloor.org>>
> Date: 14 March 2018 at 11:35
> Subject: Re: [Architecture] Another Glorious Merge
> To: Steven Githens <swgit...@mtu.edu <mailto:swgit...@mtu.edu>>
>
>
> Hi, Steve.
>
> For the benefit of others, I'm going to interpret your question
> somewhat broadly and give some examples for a range of scenarios.
>
> If you only have node components, you just use nyc (possibly with an
> .nycrc configuration file), and let it handle instrumentation and
> reporting. For anything that isn't a monorepo, it usually does "just
> work".
>
> If you only have browser components, you use the gpii.testem grade
> provided by the gpii-testem package, which handles both
> instrumentation and reporting. If you haven't used gpii-testem but
> are familiar with Testem in general, you'd need to create a testem.js
> file to replace your previous testem.json
> <https://github.com/GPII/gpii-testem#usage-instructions>, and include
> the coverage client in your client-side includes
> <https://github.com/GPII/gpii-testem/blob/master/docs/coverage.md>.
> If you've used gpii-testem before, recent versions have small breaking
> changes, mostly around using a different syntax to represent the
> instrumentation config, and using different grades when you just want
> to collect coverage data but don't want to generate a report after the
> Testem run, as is the case when you want a "combined" coverage report
> across browsers and node.
>
> If you have both node and browser tests, it's a bit more involved. In
> short, you clean up before running all tests, run each set of tests
> without generating individual reports, and then generate a report
> after. My approach to date uses only npm scripts, and is covered in
> more detail in this guide:
>
> https://github.com/GPII/gpii-testem/blob/master/docs/advanced.md
> <https://github.com/GPII/gpii-testem/blob/master/docs/advanced.md>
>
> The recent work on universal gives one example of preparing a combined
> coverage report. I would urge everyone not to start with that .nycrc
> config file, which bends over backwards to work with a monorepo that
> doesn't match nyc's lerna-ish assumptions
> <https://github.com/istanbuljs/istanbuljs/issues/146>. Most of our
> work in non-monorepos should be able to get away without an .nycrc
> config file, or with a much much simpler one like we use in infusion
> <https://github.com/fluid-project/infusion/blob/master/.nycrc>.
>
> Anyway, do please check out the gpii-testem docs, et cetera and hit me
> up if there are any problems or questions. I am always happy to help.
>
> Cheers,
>
>
> Tony
>
> On 13 March 2018 at 18:56, Steven Githens <swgit...@mtu.edu
> <mailto:swgit...@mtu.edu>> wrote:
>
> That's awesome, thanks Tony and Antranig.
>
> So, if I want to add test coverage to my XYZed GPII module I would
> just include gpii-test and nyc in my dev dependences, add that
> .nycrc file, and then mimic these lines in my package.json, then
> my project will get full test coverage?
>
> https://github.com/GPII/universal/blob/master/package.json#L72-L80
> <https://github.com/GPII/universal/blob/master/package.json#L72-L80>
>
> Cheers to the Max,
> Steve
>
>> On Mar 12, 2018, at 12:16 PM, Antranig Basman
>> <antranig.bas...@colorado.edu
>> <mailto:antranig.bas...@colorado.edu>> wrote:
>>
>> Dear All -
>> This is to report another important milestone in improving our
>> quality infrastructure. This evening another significant branch
>> has been merged, itself representing more than 6 months work by
>> Tony Atkins but building on yet more work implementing similar
>> capabilities for Infusion and captured in other projects in our
>> ecosystem, including gpii-testem. As a result of this, we will
>> now have complete code coverage information pooled between our
>> web-based and node-based unit tests and integration tests, which
>> will greatly improve the efficiency of future code review.
>>
>> The code coverage reports can be browsed within the "reports"
>> directory created after a standard (successful) run of the "npm
>> test" task. We should be aiming to reach a baseline quality
>> target of around 90% branch coverage, which across most of our
>> implementation we do already. Once we reach this uniformly, we
>> should consider how further engineering cycles should best be spent.
>>
>> Similar capabilities will now be rolled out across our other GPII
>> projects, and also we will probably try to enroll in some form of
>> coverage dashboard so that this can be checked in an automated
>> way as part of our CI.
>>
>> Could everyone who has outstanding pull requests against
>> universal please merge them up against current master, and if
>> your work has contributed any further implementation files you
>> will need to explicitly list them against the peculiar patterns
>> found in the .nycrc file listed here (bug has been filed in the
>> upstream "istanbul" project which will hopefully make this
>> unnecessary one day):
>>
>> https://github.com/GPII/universal/blob/master/.nycrc
>> <https://github.com/GPII/universal/blob/master/.nycrc>
>>
>> This has been a long road with many awkward turnings due to
>> mismatched assumptions and inflexible implementations in the
>> tower of projects that we depend on, and let us all join in
>> congratulating Tony on the endurance and carefulness needed to
>> land this highly valuable work improving our project infrastructure.
>>
>> Cheers,
>>
>> Antranig.
>> _______________________________________________
>> Architecture mailing list
>> Architecture@lists.gpii.net <mailto:Architecture@lists.gpii.net>
>> https://lists.gpii.net/mailman/listinfo/architecture
>> <https://lists.gpii.net/mailman/listinfo/architecture>
>
>
> _______________________________________________
> Architecture mailing list
> Architecture@lists.gpii.net <mailto:Architecture@lists.gpii.net>
> https://lists.gpii.net/mailman/listinfo/architecture
> <https://lists.gpii.net/mailman/listinfo/architecture>
>
>
>
>
>
> _______________________________________________
> Architecture mailing list
> Architecture@lists.gpii.net
> https://lists.gpii.net/mailman/listinfo/architecture
--
;;;;joseph.
'Call me hobophobic, but I don't think two vagrants should be allowed to marry.'
- J. Tiedrich -
_______________________________________________
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture
