Skip to content

Conversation

kilianc
Copy link

@kilianc kilianc commented Apr 20, 2019

WIP, please do not merge yet

@kilianc kilianc force-pushed the fix/default-env branch 2 times, most recently from 9eb284b to 71c44e1 Compare April 20, 2019 19:38
@kilianc kilianc changed the title fix: do not override NODE_V8_COVERAGE if set fix: do not override NODE_V8_COVERAGE if set (#70) Apr 20, 2019
@kilianc
Copy link
Author

kilianc commented Apr 20, 2019

How do you want me to test this properly? I think is messing up the snapshots too

@kilianc kilianc force-pushed the fix/default-env branch 2 times, most recently from 0706789 to f4c9d66 Compare April 20, 2019 19:47
Copy link
Contributor

@shinnn shinnn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please do not merge yet

OK.

})

it('supports exeternally set NODE_V8_COVERAGE', () => {
process.env.NODE_V8_COVERAGE = './coverage/tmp_'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of overriding NODE_V8_COVERAGE of the whole process, use spawnSync() option to modify only this child process' environment.

process.argv = ['node', 'c8', '--foo=99', 'my-app', '--help']
const argv = buildYargs().parse(hideInstrumenteeArgs())
argv.tempDirectory.endsWith('/coverage/tmp_').should.be.equal(true)
process.env.NODE_V8_COVERAGE = ''
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume the original value is not '', as this test is run with c8.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can delete but that would create a side effect like setting it to ''. I can use beforeEach and store the original value. I am only doing it that particular test now.

@shinnn
Copy link
Contributor

shinnn commented Apr 20, 2019

While reviewing this, I found the existing test results are too fragile to add new specs... the snapshot of the first test affects the second one, the second affects the third, and so on.

I think we should make each tests more independent before implementing new features.

@kilianc, thanks for starting this work.

@kilianc
Copy link
Author

kilianc commented Apr 20, 2019

Ok, I'll keep this parked here. @ me when I can continue!

@shinnn
Copy link
Contributor

shinnn commented Apr 20, 2019

we should make each tests more independent before implementing new features.

#79

@shinnn
Copy link
Contributor

shinnn commented Apr 28, 2019

@kilianc Can you rebase this branch from master?

@bcoe
Copy link
Owner

bcoe commented Apr 30, 2019

👋 @kilianc it seems like this has stalled a bit, still a feature you need?

Could you explain your use-case for me, I don't quite understand why you'd want to run c8 without setting the variable that allows it to start collecting coverage.

@bcoe
Copy link
Owner

bcoe commented May 2, 2019

@kilianc this is looking pretty good to me, what work would you still like to do?

bin/c8.js Outdated
}

process.env.NODE_V8_COVERAGE = argv.tempDirectory
if (!process.env.NODE_V8_COVERAGE) {
Copy link
Contributor

@shinnn shinnn May 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which should c8 take precedence, when both NODE_V8_COVERAGE environment variable and --tmp-directory CLI flag are provided? The current implementation will choose NODE_V8_COVERAGE in this case.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--tmp-directory should win, but we default it to NODE_V8_COVERAGE if not set, we can get rid of this if statement probably

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can get rid of this if statement probably

👍

@kilianc
Copy link
Author

kilianc commented May 6, 2019

Could you explain your use-case for me, I don't quite understand why you'd want to run c8 without setting the variable that allows it to start collecting coverage.

Quite the opposite! I am trying to give full ownership of the env to the caller, in my case CI. Instead of having to re-pass in the env as arg just to have it set again.

I hope that makes sense

@kilianc
Copy link
Author

kilianc commented May 6, 2019

BTW, not sure what is going on with master but probably someone force-pushed because I can't pull anymore. I am trying to fix my branches and force push on this PR.

@kilianc
Copy link
Author

kilianc commented May 6, 2019

I resolved my git issues but the test suite is still not passing. Will work on it this weekend, but I think the test suite still has some isolation problem. Cheers!

@kilianc kilianc force-pushed the fix/default-env branch from cc6b673 to da41f80 Compare May 6, 2019 21:56
@bcoe
Copy link
Owner

bcoe commented May 7, 2019

@kilianc once I read up on your reasoning for this feature, I totally understand what you're going for 👍 excited to see this over the finish line; let me know if there's anything I can do to help.

const { output } = spawnSync(nodePath, [
c8Path,
'--exclude="test/*.js"',
'--clean=false',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the test suite still has some isolation problem.

Use --temp-directory option here to write coverage reports to a separate directory.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shinnn the goal of this test is indeed to use the env and not --temp-directory to set the path. Look at line 38!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, indeed.

@kilianc
Copy link
Author

kilianc commented May 8, 2019

@bcoe thanks, I think this is ready. Happy to fix anything that doesn't meet expectations :)

@bcoe
Copy link
Owner

bcoe commented May 13, 2019

@shinnn how are you feeling about this PR?

@bcoe
Copy link
Owner

bcoe commented May 16, 2019

@kilianc this look reasonable to me, but all the tests appear to be failing, any thoughts?

@bcoe bcoe added the blocked For blocked PRs waiting for something else to continue with review or land label May 19, 2019
@kilianc
Copy link
Author

kilianc commented May 20, 2019

@bcoe locally it was all passing, I'll try to rebase again! 🍺

@bcoe
Copy link
Owner

bcoe commented Jun 9, 2019

@kilianc just wanted to bump this up, haven't unfortunately had the cycles to dig into the issues myself.

Still something you'd like to land?

@kilianc
Copy link
Author

kilianc commented Jun 9, 2019

@bcoe it is, it's just bandwidth. I'll do my best to get this done in the next week or so! Thanks for the bump :)

@bcoe
Copy link
Owner

bcoe commented Jun 23, 2019

closing in favor of #122; I think there was just a bad entry in the snapshot, from prior runs of your tests.

@bcoe bcoe closed this Jun 23, 2019
@bcoe bcoe mentioned this pull request Jun 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

blocked For blocked PRs waiting for something else to continue with review or land

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants