but this no longer seems to work.

Is there a way to accomplish this?

Or to get

term-missing

coverage reports so I can see which lines are missed?

I've tried

./pants test.pytest --options="cov-report html" path/to/my/build:target

and

./pants test.pytest path/to/my/build:target -- --cov-report html

oh, snap. Never mind. After looking up the more specific options documentation for

test-pytest-coverage-output-dir

it becomes clear that the html output is being written to the project

dist

directory

Greeetings. I am expecting the code coverage support in pants for Python tests to respect the

# pragma: no cover

comment when calculating coverage.

However, it does not appear that this is correct

I've marked a number of functions and classes with the comment, but my coverage numbers remain unchanged.

Am I mistaken in expecting this to work? Or is there perhaps a way to specify code not to cover that I have not yet found?

we use pytest-cov under the hood, but it looks like we might be stomping on the configuration for that: https://github.com/pantsbuild/pants/blob/master/src/python/pants/backend/python/tasks2/pytest_run.py#L208-L211

that probably needs to include

pragma: no cover

probably worth an issue or PR

@rough-minister-58256 I posted to the dev google forum. I've got a PR ready that implements a --coverage-config-file option for tests.pytest

you pass a path to a file and it overrides that default coverage config that is hard-coded.

I wanted to make sure it was wanted before making the PR, but I've got it working locally

I'd love to extend it so that one could set something like `coverage_config="path/to/config/.coveragerc" in a

python_tests

target definition

That would be ideal.

Then the configuration would be ensured consistent across builds

and you could do things like omit certain files, include others, set specific line patterns to ignore, etc.

@rough-minister-58256 https://groups.google.com/forum/#!topic/pants-devel/zPuLE1HZlxk

will the pants bintray be providing macOS 10.13 (High Sierra) binaries any time soon?

We started getting the " has changed since startup!" error messages in our builds yesterday around mid day, and I'm sort of at a loss for where to begin investigating what's going on. No changes to the box or to our pants version or anything like that, that I'm aware of. Any thoughts on where to start looking?

e.g.,

/var/lib/pants/jenkins/workdir/home/jenkins/workspace/C/pantstheon-PR/.pants.d/compile/zinc/252d64521cf9/src.java.com.allclearid.dto.shared.shared/66b7aa626b02/src.java.com.allclearid.dto.shared.shared.analysis) has changed since startup!

pants 1.2.1

@fast-nail-55400 answered on https://github.com/pantsbuild/pants/issues/5044

thx

Hopefully somebody can help me out. I’m sure it’s just my lack of understanding the system. I’m trying to setup pants with some golang projects. In the root of the repo I have several folders that contain separate projects

$GOPATH/src/domain.example/[project_folder]/[root_of_repo]/[project1]
$GOPATH/src/domain.example/[project_folder]/[root_of_repo]/[project2]
$GOPATH/src/domain.example/[project_folder]/[root_of_repo]/[project3]

In my pants.ini I have

[source]
source_roots: {
    'project1': ['go'],
    'project2': ['go'],
    'project3': ['go']
  }

When I attempt run buildgen I get

Can only BUILD gen for a single Go local sources source root,

Is there something I’m missing? or should the source_roots be setup differently?

the default sourceroot patterns are

src/$lang/

and

src/main/$lang/

... see https://www.pantsbuild.org/setup_repo.html#source-roots for more info

but more generally, go is a little bit special. there is a page about it here: https://www.pantsbuild.org/go_readme.html

so the pattern here would likely be

src/go/relevant.domain/