Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CLI --context not used when multiprocessing is enabled(for child processes) #1079

Closed
s0undt3ch opened this issue Dec 9, 2020 · 4 comments · May be fixed by #1089
Closed

CLI --context not used when multiprocessing is enabled(for child processes) #1079

s0undt3ch opened this issue Dec 9, 2020 · 4 comments · May be fixed by #1089
Labels
bug Something isn't working question Further information is requested

Comments

@s0undt3ch
Copy link

Describe the bug
When running coverage and passing --context=foo, only the main process uses that foo static context.
Any sub-processes, which do get coverage because we're setting COVERAGE_PROCESS_START, will not use that foo context, instead, they report an empty context.

To Reproduce
How can we reproduce the problem? Please be specific. Don't just link to a failing CI job. Answer the questions below:

  1. What version of Python are you using?
    It's independent of the python version used.
  2. What version of coverage.py are you using? The output of coverage debug sys is helpful.
    5.3
  3. What versions of what packages do you have installed? The output of pip freeze is helpful.
    A lot, and I don't think they're related to this issue, but I can add that to the issue if strictly necessary.
  4. What code are you running? Give us a specific commit of a specific repo that we can check out.
    https://github.com/s0undt3ch/salt/tree/features/coverage-contexts
  5. What commands did you run?
nox -e 'pytest-zeromq-3(coverage=True)' -- -vv --run-destructive --run-slow --ssh-tests --log-cli-level=debug --showlocals tests/integration/modules/test_config.py --maxfail=1

Expected behavior
I would expect that the context passed through --context, to be "inherited" but any subprocess which has coverage enabled.
@s0undt3ch s0undt3ch added the bug Something isn't working label Dec 9, 2020
@s0undt3ch
Copy link
Author

I only see a fix for this, coverage set's an environment variable and when coverage.process_startup() is called, that environment variable is used to set the initial context.
Know a better way?

@s0undt3ch
Copy link
Author

@nedbat would you think adding the CLI parsed options as an env variable(json encoded?), which would then be used for when calling coverage.process_startup() a proper fix?
I have no issues providing a PR, as long as you see that it's the right path to take.

@s0undt3ch
Copy link
Author

Or perhaps, why don't we use Stowawy to also include the loaded coverage config(and use that config) instead of just the rcfile?

s0undt3ch added a commit to s0undt3ch/coveragepy that referenced this issue Jan 4, 2021
@s0undt3ch
Carry static context information into subprocesses
e92571b 
Fixes nedbat#1079
@s0undt3ch s0undt3ch mentioned this issue Jan 4, 2021
Open
@nedbat
Copy link
Owner

nedbat commented Jan 22, 2021

Hi, sorry I haven't responded yet.

In general, the command-line options are not passed to the subprocesses. I'm wondering why --context should get special treatment? Is there a reason you have to specify context on the command line? Another option is to use an environment variable to set the context, and then use variable expansion in the configuration file to set the context.

@nedbat nedbat added the question Further information is requested label Nov 15, 2021
@nedbat nedbat closed this as not planned Won't fix, can't repro, duplicate, stale May 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working question Further information is requested
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Carry static context information into subprocesses s0undt3ch/coveragepy
2 participants
@nedbat @s0undt3ch