8000 Would you be open to a PR that adds in an option to use alternative templates? · Issue #714 · gcovr/gcovr · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Would you be open to a PR that adds in an option to use alternative templates? #714

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

Closed
frankwiles opened this issue Feb 10, 2023 · 5 comments · Fixed by #758
Closed

Would you be open to a PR that adds in an option to use alternative templates? #714

frankwiles opened this issue Feb 10, 2023 · 5 comments · Fixed by #758

Comments

@frankwiles
Copy link
Contributor

Hello!

We (REVSYS) have a client, a fellow Open Source project, that would like to use gcovr for their coverage reports. However, they would like to heavily adjust the styling to better suit their preferences and that of their project's website.

Would you all be open to a PR, if I did the work, to allow gcovr to support an --html output option but also honor a --template-dir flag to point at a different set of jinja2 templates?

@latk
Copy link
Member
latk commented Feb 10, 2023

Yes, this has been a long-standing feature request (see #25). In preparation of that feature, HTML generation was moved to Jinja, and user-defined CSS files were implemented in #380.

I'd be very happy if someone does the work of exposing the HTML templating system to end users.

However, the HTML writer is a bit of a mess, and it is unclear which variables and data structures are made available to the Jinja templates. I don't think gcovr can commit to any stability guarantees regarding the template structure, so that user-defined templates are likely to break for any gcovr updates.

There's also the issue that gcovr's testing methodology is fairly fragile, comparing rendered HTML files as strings (golden master testing). Even the smallest changes to the templates will require the test reference data to be updated.

So, being now aware of those potential issues, please go nuts and make gcovr better. It's very cool that you want to upstream improvements instead of forking!

In addition to the ability to completely override the set of templates, consider whether the following changes could also make sense:

  • overriding some but not all templates
  • reorganizing the default templates to be more easily extensible
  • making it clearer in the code which data is provided to which template/partial
  • upstreaming layout improvements into the default templates

@Spacetown
Copy link
Member

We have three kinds of html reports in the next release:

  • --html
  • --html-details
  • --html-nested

@latk mentioned in #687 (comment) that the --html-nested will replace the detailed report. Therefore I suggest following steps:

  • Remove the new option --html-nested and use --html-details instead (reduce report kinds).
  • Restructure the templates to have for each part of the report a own file.
  • Add option to define a own directory which is searched first for a template.

@frankwiles
Copy link
Contributor Author

So what I think might work best and have seen in other projects is simply adjusting the directory it looks for templates. Then the onus is on the customizer to copy the existing templates, as is, and adjust them as they see fit.

If template context changes over time with various releases it's again on the customizer to adjust their templates or stay pinned to an older version until they feel like doing it. It's not like anyone is going to be pushed too forcefully to update govr versions if what they have is working for them. Not a lot of security issues for example.

This covers the use case of just wanting to customize a single template, or the CSS, or all of it.

If I'd through the source correctly I believe all that needs to happen is:

Anything I may be missing?

@Spacetown
Copy link
Member

I think only templates() needs to honor the option. Defining a own directory and an explicit stylesheet doesn't make sense.

Restructuring the templates to have several files for each part of a page and one file for the page structure and a option to specify other search directories for the templates would be the best.
The user can then specify a directory where only the changed files need to be present, the rest is taken from the original directory.
In this case the option to specify a own stylesheet can be removed and handled via the new option.

@vinniefalco

This comment was marked as off-topic.

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

Successfully merging a pull request may close this issue.

4 participants
0