-1

I want to look at the results of code coverage in a script that then decides whether it is ok for the user to proceed. Does pants have this functionality? Is there any way to do this other than piping it into an external file and parsing?

Right now it prints everything to stdout, which isn't the best for what I'm trying to do. On top of that, when I do pipe to another file, I don't get the actual code coverage, just the compilation pants does up the it, like so

    09:55:36 00:00 [main]
               (To run a reporting server: ./pants server)
09:55:36 00:00   [setup]
09:55:37 00:01     [parse]
               Executing tasks in goals: bootstrap -> imports -> unpack-jars -> jvm-platform-validate -> deferred-sources -> gen -> resolve -> resources -> pyprep -> compile -> test
09:55:37 00:01   [bootstrap]
09:55:37 00:01     [substitute-aliased-targets]
09:55:37 00:01     [jar-dependency-management]
09:55:37 00:01     [bootstrap-jvm-tools]
09:55:37 00:01     [provide-tools-jar]
09:55:37 00:01   [imports]
09:55:37 00:01     [ivy-imports]
09:55:37 00:01   [unpack-jars]
09:55:37 00:01     [unpack-jars]
09:55:37 00:01   [jvm-platform-validate]
09:55:37 00:01     [jvm-platform-validate]
09:55:37 00:01   [deferred-sources]
09:55:37 00:01     [deferred-sources]
09:55:37 00:01   [gen]
09:55:37 00:01     [antlr-java]
09:55:37 00:01     [antlr-py]
09:55:37 00:01     [jaxb]
09:55:37 00:01     [protoc]
09:55:37 00:01     [ragel]
09:55:37 00:01     [thrift-java]
09:55:37 00:01     [thrift-py]
09:55:37 00:01     [wire]
09:55:37 00:01     [go-thrift]
09:55:37 00:01   [resolve]
09:55:37 00:01     [ivy]
09:55:37 00:01     [coursier]
09:55:37 00:01     [go]
09:55:37 00:01   [resources]
09:55:37 00:01     [prepare]
09:55:37 00:01     [services]
09:55:37 00:01   [pyprep]
09:55:37 00:01     [interpreter]
09:55:37 00:01     [build-local-dists]
09:55:37 00:01     [requirements]
09:55:37 00:01     [sources]
09:55:37 00:01   [compile]
09:55:37 00:01     [compile-jvm-prep-command]
09:55:37 00:01       [jvm_prep_command]
09:55:37 00:01     [compile-prep-command]
09:55:37 00:01     [compile]
09:55:37 00:01     [zinc]
09:55:37 00:01     [jvm-dep-check]
09:55:37 00:01     [go]
09:55:37 00:01   [test]
09:55:37 00:01     [test-jvm-prep-command]
09:55:37 00:01       [jvm_prep_command]
09:55:37 00:01     [test-prep-command]
09:55:37 00:01     [test]
09:55:37 00:01     [pytest-prep]
09:55:38 00:02     [pytest]
                   tests/python/pom_manager:all                                        .....   SUCCESS
                   tests/python/pom_manager:pom_util_test                              .....   SUCCESS
                   tests/python/pom_manager:pom_manager_test                           .....   SUCCESS
                   tests/python/pom_manager:pom_worker_test                            .....   SUCCESS
                   tests/python/pom_manager:pom_validator_test                         .....   SUCCESS
                   tests/python/pom_manager:lc_util_test                               .....   SUCCESS
09:55:38 00:02     [junit]
09:55:38 00:02     [go]
               Waiting for background workers to finish.
09:55:38 00:02   [complete]
               SUCCESS
sf8193
  • 575
  • 1
  • 6
  • 25

1 Answers1

0

For anyone who comes across this issue later, I found out that pants stores an html file of all the code coverage which was easy enough to parse.

E_net4
  • 27,810
  • 13
  • 101
  • 139
sf8193
  • 575
  • 1
  • 6
  • 25
  • could you provide a link to the documentation for this, if it exists? Where is that file located? are you using pytest? how is this integrated with your CI system? – Daniel Kravetz Malabud Apr 25 '19 at 19:33
  • @DanielKravetz it was py.test. documentation: https://www.pantsbuild.org/python_readme.html the file is dependent on your command, mine was `./pants py.test --coverage=auto path_to_target` which created a 'dist' directory with a bunch of xml/html files with info on all of the unit tests ran. and this would create a folder inside my directory that had a ton of info on the tests it ran. One of these was index.html, and then there were more specific ones past that. I included this as part of a script that checks code-coverage on jenkins, although I doubt that matters – sf8193 Apr 28 '19 at 02:04
  • Thank you for the information. In our case, we tried to also use PANTS for the frontend, but the nodejs plugin has lots of room for improvement. We simply decided to ditch a build tool altogether for now. – Daniel Kravetz Malabud Apr 29 '19 at 11:06