You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by GitBox <gi...@apache.org> on 2020/09/17 12:45:50 UTC

[GitHub] [logging-log4net] fluffynuts edited a comment on pull request #67: Fix CA2000, CA2237, CA3075

fluffynuts edited a comment on pull request #67:
URL: https://github.com/apache/logging-log4net/pull/67#issuecomment-694206130


   > Build-in tools are preferable, an external tool makes it harder for new contributor to join. But in the same time used tools should be effective by all means.
   > I'm not familiar with SonarQube to make any conclusion so it is not up to me :)
   
   I'm not talking about expecting people to install stuff -- external tools which can be bootstrapped by the build pipeline are ok -- for instance, running tests: for the primary run, we use the nunit runner, but how that happens is all tucked away in the bowels of `zarro test-dotnet`, which will download the nunit console runner nuget package & use it to run tests. Same goes for coverage via dotCover or OpenCover (and subsequent report generation with ReportGenerator, if using OpenCover). Where I can't just automate it, I try to provide helpers like the .ps1 scripts in the root of the repo to get more esoteric build targets installed. But for a new dev, if one has node & the relevant .net tools installed (eg vs build tools install), then
   ```
   npm ci
   npm release
   ```
   
   will 
   - bootstrap all required tooling
   - restore packages
   - build
   - test
   - generate build artifacts
   
   
   At some point, I want to automate the site into that (I have a `build-site` npm script which I use, just not 100% convinced it should be part of the build pipeline yet because `release` can be run at a CI server which wouldn't (shouldn't) be able to push back the generated site). Also need to fix up the sdk docs which went missing, and then that should be a part of the `build-site` pipeline.
   
   The point is: I don't mind external stuff which can be automated. I try to reduce non-automatable dependencies, which should be documented (yes, I have work to do there too, in cleaning up the docs).
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org