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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for reading report arguments from .netconfig #374

Merged
merged 1 commit into from
Sep 8, 2020
Merged

Conversation

kzu
Copy link
Contributor

@kzu kzu commented Aug 26, 2020

The http://dotnetconfig.org/ format allows unifying configuration with
other .NET core tools, making it easier to maintain multiple tool settings
in a centralized fashion.

By leveraging the format, ReportGenerator gains:

  • Simplified command line args in CI scripts (just run without parameters
    most of the time)
  • Support for hierarchical configurations
  • Standard way of updating and managing those configurations, via the
    dotnet config tool, such as dotnet config --add reportgenerator.reporttype Html

The configuration is shared uniformly between the CLI and MSBuild task, for
consistency. Updated the documentation too to showcase the new functionality.

@kzu
Copy link
Contributor Author

kzu commented Aug 26, 2020

The feature was explicitly added as a fallback for missing arguments, but that can be changed if desired. That is, none of the config-driven values are taken into account if the same argument has already been provided (via CLI or MSBuild).

It might be worth exploring whether some configurations could actually augment the provided arguments (i.e. plugins, filters?). So that the configured ones are added to the ones in the CLI/MSBuild args.

@kzu kzu marked this pull request as draft August 27, 2020 04:38
kzu added a commit to dotnetconfig/dotnet-config that referenced this pull request Aug 27, 2020
Most shouldn't need strong-named assemblies, but some might so,
we will just strong name ¯\_(ツ)_/¯.

Been fighting for many hours to workaround it using StrongNamer
and what-not for danielpalme/ReportGenerator#374
without success. So, just declare defeat and move on.
@kzu kzu marked this pull request as ready for review August 27, 2020 06:53
@kzu kzu marked this pull request as draft September 1, 2020 15:30
@kzu
Copy link
Contributor Author

kzu commented Sep 1, 2020

Converting to draft until the (somewhat dependent) PRs are merged:

#376
#377
#378

That would bring back this PR to a single commit.

@danielpalme
Copy link
Owner

I merged #376, #377 and #378 into the develop branch.
This branch is currently equivalent to the master branch.
I will merge back to master once everything is ready to create a new release.

If you merge develop into your config branch, you should be able to continue your work.

@kzu kzu marked this pull request as ready for review September 5, 2020 05:37
@kzu
Copy link
Contributor Author

kzu commented Sep 6, 2020

Ok, I think this is ready for review now :)

@kzu kzu changed the base branch from master to develop September 8, 2020 04:04
The http://dotnetconfig.org/ format allows unifying configuration with
other .NET core tools, making it easier to maintain multiple tool settings
in a centralized fashion.

By leveraging the format, ReportGenerator gains:

* Simplified command line args in CI scripts (just run without parameters
  most of the time)
* Support for hierarchical configurations
* Standard way of updating and managing those configurations, via the
  `dotnet config` tool, such as `dotnet config --add reportgenerator.reporttype Html`

The configuration is shared uniformly between the CLI and MSBuild task, for
consistency. Updated the documentation too to showcase the new functionality.
@danielpalme danielpalme merged commit b4866d3 into danielpalme:develop Sep 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants