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.

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

Already on GitHub? Sign in to your account

Use Jinja2 templates for HTML generator #234

merged 2 commits into from
Mar 18, 2018


Copy link

@latk latk commented Mar 5, 2018

Previously, the HTML generator used string.Template as a rendering mechanism. Now, Jinja2 is used as a rendering engine. The Jinja2 language is very versatile and should make all of this more maintainable. Jinja is documented at

This adds Jinja2 as a hard dependency! However, that shouldn't be a problem when installing normally through pip or manually using the Jinja2 supports all of our supported Python versions.

The templates were moved to the gcovr/templates directory, so they no longer obfuscate the Python source code. Added benefit: useful syntax highlighting when editing the templates 馃槏

The row-level templates were folded into their main templates, and are no longer rendered separately.

Jinja does slow gcovr down a bit. When running the test suite on my computer, this went from ~21s to ~28s. Initializing Jinja lazily reduced this to ~23s which is probably an acceptable tradeoff. Note that the test suite is not representative of real-world use as it covers many small projects and probably over-emphasizes startup time.

This PR was based on prior work by @lu-zero in #25 and #43. Thank you Luca for forging a way.

Based on this change, improving the HTML should be easier. E.g. I want to add an option to store the CSS in a separate file and remove the inline CSS which (a) simplifies the HTML tests and (b) solves the Jenkins CSP problem (#125).

this is the minimum necessary change to switch the template engine 鈥
actual benefits will follow later
Copy link

codecov bot commented Mar 5, 2018

Codecov Report

Merging #234 into master will increase coverage by 0.07%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #234      +/-   ##
+ Coverage      84%   84.08%   +0.07%     
  Files          11       11              
  Lines        1194     1200       +6     
  Branches      248      248              
+ Hits         1003     1009       +6     
  Misses        131      131              
  Partials       60       60
Impacted Files Coverage 螖
gcovr/ 94.19% <100%> (+0.14%) 猬嗭笍

Continue to review full report at Codecov.

Legend - Click here to learn more
螖 = absolute <relative> (impact), 酶 = not affected, ? = missing data
Powered by Codecov. Last update 12e0ec0...dd63f48. Read the comment docs.

The gcovr/templates/* files are loaded on-demand for HTML output. The
row-templates were folded into the main HTML templates.
@latk latk mentioned this pull request Mar 5, 2018
@latk latk merged commit dd63f48 into gcovr:master Mar 18, 2018
latk added a commit that referenced this pull request Mar 18, 2018
@latk latk removed the needs review label Mar 18, 2018
@latk latk deleted the html-templates branch May 20, 2018 19:37
Copy link

fletort commented Oct 3, 2018

Any doc for this feature somewhere ?
How select which template is used in the command line ?

Copy link
Member Author

latk commented Oct 3, 2018

Hi @fletort, the templates are not currently exposed to users but are loaded from the package data that is included in gcovr. Because all of this is internal, there is no documentation.

I'd be open to a PR that makes the templates configurable, but the HTML generation code is a bit of a mess. We'd have to define a clear and stable data model that is made available to the templates. I don't want to do that right now because I'm likely to change this data model in the medium future, e.g. to make the reports more themable via CSS (compare #25, #125, #277).

Related to this, the default templates need some love anyway. E.g. they are still using table-based layout. So far I have shied away from fixing that because a very large number of integration tests would have to be updated. The current templates were written to introduce the minimal amount of test changes. They were not designed to be extensible.

If you'd like to work on user-defined templates, please open an issue to discuss the proposed design of the command line flags, the template structure, and what kind of variables should be made available to the templates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging this pull request may close these issues.

None yet

2 participants