-
Notifications
You must be signed in to change notification settings - Fork 3
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.
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
Code coverage intel analysis #298
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #298 +/- ##
==========================================
+ Coverage 69.97% 70.21% +0.23%
==========================================
Files 18 20 +2
Lines 986 1128 +142
==========================================
+ Hits 690 792 +102
- Misses 296 336 +40 ☔ View full report in Codecov by Sentry. |
ef27b5b
to
1b543fd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only had a quick look but there is something in the design I don't like (if I got it right).
I don't think we need both the "build_option" entry in the config.yaml and the codecov command.
I can't think of a test case to run benchcab tests with a code compiled with Debug option (the runs are too long to do with Debug). So the build_option
entry is only here to ensure we can compile with code coverage on when running the coverage command. But setting build_option
and the coverage command are independent of each other.
So what happens if I forget to set build_option
before running the coverage command? Shouldn't the coverage command force building with the code coverage options instead of being dependent on an independent entry in the config file?
Actually, I'm not sure how the codecov command is to be used. Are we supposed to have run benchcab first (benchcab run) with code coverage options on for the compilation and then run benchcab codecov
?
Are you assuming we aren't going to check the code coverage manually?
Oh I see, so I thought we wouldn't have to rebuild
Yes, after the jobs are completed
I thought
Both options above make the relationship explicit. Happy to hear alternative designs/requirements. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for implementing the core functionality Abhaas.
I think adding a benchcab codecov
subcommand is how I would approach the code coverage generation step as well.
I think I agree with Claire that specifying build_option
isn't required for code coverage and is a bit outside the scope of the PR. I also recommend trying to keep changes minimal in the Model.build
method as that functionality will eventually be replaced with spack
.
Instead of enabling code coverage via build_option
, have you considered introducing a global codecov
option? This could either be a configuration file option (e.g. codecov: true
) or a command line option for the relevant subcommands (e.g. benchcab run --codecov
where --codecov
is propagated to other commands like build
, fluxsite-submit-job
, etc).
src/benchcab/model.py
Outdated
if compiler_id != "ifort": | ||
msg = f"""For code coverage, the only supported compiler is `ifort` | ||
User has {compiler_id} in their environment""" | ||
raise RuntimeError(msg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this necessary? The compiler will throw an error if it cannot recognise the given compiler flags. This would also exit with an error when trying to run code coverage using Intels ifx
compiler which isn't desired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that is true, although it was decided that it would be clearer if benchcab
gave the error message before passing in to the compiler (I can also add check for ifx
). @ccarouge thoughts?
src/benchcab/model.py
Outdated
with self.modules_handler.load([internal.DEFAULT_MODULES["cmake"], *modules]): | ||
|
||
# $FC is loaded after compiler module is loaded, | ||
# but we need runs/ dir relative to project rootdir | ||
env_fc = os.environ.get("FC", "") | ||
self.logger.debug( | ||
f"Getting environment variable for compiler $FC = {env_fc}" | ||
) | ||
build_flags = self.get_build_flags(mpi, build_option, env_fc) | ||
env_fc = None | ||
|
||
with chdir(path_to_repo): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice if we didn't have to split the with
statement in two. If you remove the inspection of the FC
environment variable you should be able to query the CMake arguments outside the with
statement entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, will make the with
statement in 1 line if compiler_id
isn't required.
I think it would be better to have |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made a few minor suggestions but overall I'm happy with it. Approving
I see (implemented the respective changes) and tested. I'll squash the commits once ready to be merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
679729b
to
f4c3c19
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to go. Just a minor change if you want to add it before merging.
b65c2df
to
1dcd270
Compare
Resolves #91
Description
benchcab gen_codecov
for running code coverage analysis for all runs grouped by each realisation's Intel build. Runs only ifcodecov: true
inconfig.yaml
. Added as a workflow step in fluxsite runs.config.yaml
keyword (codecov
) - which provides the compiler build flags to rungen_codecov
later onNote: As of now,
codecov
analysis is only supported w.r.t.fluxsite
tasksTesting
On the following
config.yaml
file, runbenchcab
:After the job has completed, run the code coverage utility:
On inspection, it generates the files as expected at
runs/codecov/R0/
.