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

Sonar integration #37

Open
wants to merge 27 commits into
base: master
Choose a base branch
from
Open

Sonar integration #37

wants to merge 27 commits into from

Conversation

Dongata
Copy link
Contributor

@Dongata Dongata commented May 16, 2018

Background  

It's a good thing knowing some metrics of your project, so we add an integration with sonar

Changes done  

  • updates travis config file
  • adds coverlet report generator

Demo 

Sonar Page

Copy link
Contributor

@mravinale mravinale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

awesome!!

@matiasbeckerle
Copy link
Contributor

Please DO NOT merge this yet. I want to review what it does. So far, I'm against adding it on a seed project.

@AlphaGit
Copy link
Member

In response to @matiasbeckerle's concern (which I agree with), consider adding it as a optional module (something plugabble, so that not every project needs to take this out) OR having a set of instructions that make it easy to add. (For instance, a branch/document with the changes to apply to include it.)

Code generators are an option buuuuut they might be very complicated and I agree if you guys don't want to follow that route.

@mravinale
Copy link
Contributor

I think it adds value as travis does, seems to be not very difficult to remove and we can track bad practices as we develop this project

@matiasbeckerle
Copy link
Contributor

matiasbeckerle commented May 16, 2018

I think it adds value as travis does

Not exactly. Travis does his thing in a much less invasive form.

seems to be not very difficult to remove

Yes but while working on projects this is hard to make it happen. There is always a different priority.

and we can track bad practices as we develop this project

Indeed... but we have other mechanisms to improve ourselves. I believe that a tool like this one should be a decision made by the team. What if they want to use a different one? How they can track what was required so they can delete the code? I remark again that a seed it's just that: the minimum required to make it grow. We should not create a box full of libraries.

Instead, I propose to see what happens with just the minimum. Where do we fail? What was wrong? What we were missing? What was a leftover? Let's experience with the minimum first, then we iterate. I'm not saying we should never use this tool/lib. I'm saying that for now, I believe we should hold on with adding it.

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.

5 participants