I generally fully agree.

But I don’t want to cause contributors to leave in that case.
I have seen way too many projects where good contributions don’t get merged 
because of guards like that.

So, if us doing that would cause us loosing/not attracting new people, then I 
would be hesitant to add more rules.

In the end it doesn’t help us, if we have a happy Sonar, but we’re (or I) am 
the only ones contributing, cause everyone else left.

When contributing to other project stuff like that is sometimes the most 
discouraging things.
Like “Build failed cause there’s a line-break at the end of this file” (Totally 
annoyed by that in the IoTDB project).

Chris

Von: Sebastian Rühl <sru...@apache.org>
Datum: Freitag, 15. März 2024 um 11:23
An: dev@plc4x.apache.org <dev@plc4x.apache.org>
Betreff: Re: [DISCUSS] Disable the Sonar-Check in Github Actions?
Honestly I think we should do the following:

- Take sonar serious and look after that stuff Reported there
- Disable the build breaker for some time so it doesn't flag everything as a 
failed build
- Think about how we can avoid ending in the same situation again

If you look at other projects usually you have a build breaker/guard on a PR 
and then it is the duty of the author to ensure that the code added doesn't 
break the sonar rules before merging. Due to the fact that we don't follow that 
it is easy to slip stuff into develop which leads then to a state we have now. 
Not 100% sure what is best to do here.

Sebastian

On 2024/03/14 21:27:45 Christofer Dutz wrote:
> Hi all,
>
> So, we have been having failing builds for … well … it feels like … ever. 
> Because the Sonarcloud check always keeps on marking every commit as Errror.
>
> I think: Either we pay attention to it, or we disable it.
>
> So, what do you folks think? Keeping it on and paying attention to it will be 
> a lot of work, but it would be worth it.
>
> Chris
>

Reply via email to