Fix/677

[chavacava]

Closes #677

The sources of data races were:

1. Concurrent W/R access to rules' configuration
2. Concurrent W/R access to package's type information

Tested with:

• build: go build -race
• config.toml

ignoreGeneratedHeader = false
severity = "warning"
confidence = 1.2
errorCode = 0
warningCode = 0
enableAllRules = true

[rule.unhandled-error]
    arguments=["255"]

[rule.line-length-limit]
    arguments = [200]

[rule.function-result-limit]
    arguments = [200]

[rule.max-public-structs]
    arguments = [200]

[rule.cyclomatic]
    arguments = [200]

[rule.argument-limit]
    arguments = [200]    
[rule.banned-characters]
    arguments = ['#']    


[rule.function-length]
    arguments = [200,200]    


[rule.cognitive-complexity]
    arguments = [200]

[rule.file-header]
    arguments = ["regexp"]    

Then:

untilfail revive -config config.toml kubernetes/third-party/...

[mgechev]

I just skimmed through the PR, and it looks good. There are a few linting errors we can fix before merging.

[zimmski]

Awesome, thanks @chavacava. Looks like a lot of work went into this. Will try it now on a problem i had last week

[zimmski]

Yep, that did it. l had a problem reported that was deterministic in our CI but i could only reproduce locally when i deleted the GOCACHE and pkgs directories. Crazy thing,looked in the wrong place. Yet again a good learning to get rid of the basic errors first: races are never good.

Now that i can reproduce that problem locally, i will take a deeper look and do bug report for the range-val-address rule. I think (hope) it flags something that should be OK.

Thanks again :-)

[zimmski]

OK i wrote to soon, when i compile the whole monorepo i cannot reproduce the problem again. Will do a bug report now.