remove constant unexplained failures that don´t seem to fail

[DaanHoogland]

Description

This PR disables the SuperLinter which always claims there are failures even if there is nothing to report.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[GabrielBrascher]

LGTM

[yadvr]

With #6531 this may not be needed if the lint is fixed, if we think it's not necessary (as travis does some lint checks too?) let's remove this indeed.

[github-actions]

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

[github-actions]

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

[DaanHoogland]

@jbampton can you comment please? i lost track of our pre-commit track record.

[jbampton]

The flake8 lint fix was here #6529 which added a single line at the end of a Python file.

So the Super Linter was taking over 10 minutes to run. So in #6531 we changed the linter to just check the files in each pull request and it now takes about 2 minutes to run.

Seems having a blank line at the end of a file is best practice.

Flake8 is now linting for 3 rules all whitespace related shown here

cloudstack/.github/linters/.flake8

Line 19 in 0cae440

select = W291,W292,W293

Python has PEP 8 – Style Guide for Python Code and whilst you don't have to follow it, it does talk about some best practices.

https://peps.python.org/pep-0008/

So this work with the Super-Linter is all about code standards.

I think using pre-commit is just the next extension to getting all the linters/checks running on your local machine.

I would be happy to write up some docs if needed on all this.

[DaanHoogland]

@rohityadavcloud if @jbampton is right I'd rather disable the checks in travis as they take longer and travis has enough to do anyway.
And I think we can close this consequently.

[yadvr]

Travis lint checks are somehow quicker and only done via job #1 which only does build related checks (doesn't run more than one simple smoketests). Job #1 is usually fastest among rest of the jobs.