build: add very experimental MegaLinter config files

[eitsupi]

Close #1944

• Automatic fixes are disabled to avoid conflicts with existing pre-commits.
• The linters for languages (Rust, JS, and Python) which are already configured (?) are disabled.
• stylelint is disabled because of long execution time.
• Configured to ignore Linter errors, which currently generate errors for all codes in this repo.

[github-actions]

🦙 MegaLinter status: ❌ ERROR

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
⚠️ ACTION	actionlint	16		2	0.09s
✅ BASH	bash-exec	2		0	0.01s
⚠️ BASH	shellcheck	2		1	0.04s
⚠️ BASH	shfmt	2		1	0.0s
⚠️ C	cpplint	2		6	0.13s
⚠️ COPYPASTE	jscpd	yes		11	13.41s
⚠️ CPP	cpplint	1		2	0.08s
⚠️ CSHARP	csharpier	4		1	0.99s
⚠️ CSHARP	dotnet-format	4		4	1.71s
⚠️ DOCKERFILE	hadolint	1		1	0.08s
⚠️ HTML	djlint	19		16	0.56s
⚠️ HTML	htmlhint	19		75	0.26s
⚠️ JAVA	checkstyle	4		76	1.57s
⚠️ JAVA	pmd	4		1	1.65s
✅ JSON	eslint-plugin-jsonc	9		0	2.08s
⚠️ JSON	jsonlint	9		1	0.19s
✅ JSON	prettier	9		0	1.19s
✅ JSON	v8r	9		0	9.09s
⚠️ MAKEFILE	checkmake	1		1	0.0s
⚠️ MARKDOWN	markdownlint	97		48	0.63s
❌ MARKDOWN	markdown-link-check	97		1	75.92s
⚠️ MARKDOWN	markdown-table-formatter	97		1	0.29s
⚠️ PHP	phpcs	3		1	0.1s
✅ PHP	phplint	3		0	0.08s
⚠️ PHP	phpstan	3		9	2.05s
⚠️ PHP	psalm	3		11	0.53s
⚠️ REPOSITORY	checkov	yes		6	11.45s
⚠️ REPOSITORY	devskim	yes		3	0.97s
✅ REPOSITORY	dustilock	yes		no	1.34s
✅ REPOSITORY	gitleaks	yes		no	3.13s
✅ REPOSITORY	git_diff	yes		no	0.01s
✅ REPOSITORY	secretlint	yes		no	2.13s
✅ REPOSITORY	syft	yes		no	1.66s
⚠️ REPOSITORY	trivy	yes		1	3.78s
⚠️ SPELL	misspell	189		1	0.16s
✅ SQL	sql-lint	1		0	0.3s
⚠️ SQL	tsqllint	1		1	0.4s
✅ XML	xmllint	1		0	0.01s
✅ YAML	prettier	30		0	1.24s
⚠️ YAML	v8r	30		1	30.84s
✅ YAML	yamllint	30		0	0.64s

See detailed report in MegaLinter reports

You could have same capabilities but better runtime performances if you request a new MegaLinter flavor.

• Click here to request the new flavor

MegaLinter is graciously provided by

[eitsupi]

@max-sixty I have configured it to ignore all linters errors that were causing errors.
Revert a665b2d and we can merge without generating errors.

Is that good enough for you?
Or is there a linters you would like to disable altogether or a setting you would like to add?
(Personally, I think it would be better to add them as needed after the merge than to do that in this PR. Unless this is merged, the number of codes that linters complain about will continue to grow.)

[max-sixty]

It does actually find a couple of good results, so yes, let's try it. We can evaluate in a few weeks whether it's adding value.

I find the PR comment very long and noisy — I would vote to have that turned off, at least initially. I'm also not that keen on a sponsor message on every single PRQL PR without a really good reason.

I also think we should:

• Update the development.md with a sentence to say we're experimenting with this
• Add a comment somewhere in the config file saying this is experimental and that we're exploring using this more / open to changes / etc.
• Resolve it adding annotations — possibly these are correct and we should fix them, but we don't want these added to every PR until they're fixed — maybe we disable, open an issue to fix?

And then at some point:

• Look into turning on auto-fixes for formatters
• Move it to the pull-request workflow
• Decide whether it's adding value — are we using it to make changes to the code or is it just producing perma-warnings? My experience is that in order to be helpful, linters either need to fix the errors they find (e.g. formatters) or discriminate between important and unimportant errors.
  • So my guess is that we might benefit instead from adding more pre-commit tasks, which have strict pass/fails, driven by the folks who are working on that language binding. But let's see...

[eitsupi]

@max-sixty Thanks for your advice.

I find the PR comment very long and noisy — I would vote to have that turned off

Done. (The comment left above is previous and will no longer be updated.)

Update the development.md with a sentence to say we're experimenting with this

Done.

Add a comment somewhere in the config file saying this is experimental and that we're exploring using this more / open to changes / etc.

Done.

Resolve it adding annotations — possibly these are correct and we should fix them, but we don't want these added to every PR until they're fixed — maybe we disable, open an issue to fix?

I don't think this appears on all PRs.
I temporarily ran the workflow for all code in the project (a665b2d), but usually only for files that have changed.
In other words, this will not show up in PRs that do not edit php files.

Does this answer your concern?

[max-sixty]

Perfect! Looking forward to trying this.

Some things we could do from here (no urgency / obligations!):

• Turn on autofixes for formatters
• Turn on failures for the checks that we've fixed and are reliable (e.g. thanks for fixing chore: fix typo #1988, we could try enforcing that if we trust it to have minimal false positives)

[eitsupi]

Thanks, I merged this and created a issue about future follow up #1994