melg8 / cit

Control your c++ code using this ci template and development environment powered by nix and docker.
Other
15 stars 3 forks source link

C++ linters MegaLinter descriptors #18

Open nvuillam opened 2 years ago

nvuillam commented 2 years ago

Hi,

I just discovered your project that seems very interesting :)

I see that you started to implement a lot of MegaLinter descriptors , and there are probably lots of them that would be eligible to core MegaLinter :)

MegaLinter contains an advanced CI that allows to automatically upgrade linter versions when new ones are released, so instead of maintaining those on your side, it may be interesting to add them within MegaLinter repo ? I'd be very glad to welcome you within MegaLinter contributors :):

If you want you can add me on LinkedIn and we can discuss that -> https://www.linkedin.com/in/nicolas-vuillamy/

Best regards

melg8 commented 2 years ago

Hi, @nvuillam !

Glad you've noticed my project. I have some plans to dig deeper into megalinter. My current implementation is merely glue code to use this linters in context of megalinter so i can get nice statistics and github/gitlab outputs. But main differences are:

  1. I don't use dockerfiles to create image. I use nix expressions and packages to build docker image. Main difference is - docker image will be bigger than megalinter's alpine based one, but it will be reproducible with nixpkgs version pinning. So even when time goes by, i can recreate environment and linters in theirs versions identical up to hash sum of whole image. (Before that I've used alpine based approach and encountered a few cases, when new update silently changes versions of distributed packets, and i get one of two problems: either docker doesn't build, or newer version of tool has some incompatibilities with previous one, so i need to manually tweak it).
  2. What nix also provides - using nix-shell - you can even don't bother with loading docker images - it can assemble same environment in any Linux based distro with nix installed. What i imagined - would be some kind of way for user to choose it's own set of tools. Current megalinter approach is slightly different - it provides "ready to use" solution with some flavors (which is great) but no way to cut off from image an fine tune it using some kind of config files and without forking main repo. In nix world (at least for linters which are in nixpgks - we have already tools such as nixery - providing adhoc docker image building.
  3. Sometimes you cant use docker, but can use linux - nix-env based approach could be used to cover that case. Using same setup we can build even full NixOS distro - containing needed linters.
  4. Docker based approach is great for its simplicity and small-er images, but another cost is security - megalinter already have pretty long list of trivy ignores - with cve - for some users having additional potential vulnerability even if it's inside of docker container - can be big no. So once again about some way to split up tools up to only used linters + nix provides way to run applications in isolation.
  5. I'm more focused in covering not only online github/gitlab kind of setup, but also - cases when there is no internet connection, or you have only local network. Megalinter's approach of plugins doesn't work for that (or i didn't understand it at time), that's why i was forced to roll out my descriptors.
  6. At least for now I'm not so focused in providing services for other people, but rather exploring ci/cd setups myself. Contributing in your project would take much more effort i think with all rules/additional testing etc.
  7. Before rolling out my own version i considered contributing into your project, but after reading this issue - i didn't came up with clear understanding what are criteria for linters to be added to core lib or just as plugins. Because i have descriptor for reuse.
  8. I focus on C++ development and tools for c++ are rather quirky: usually they don't just lint on per file bases, they need additional setup (for example - obtaining compiler_commands.json from project, which could be generated in a few different ways). Plus they are not always fast. For example full run of clang-tidy even on my almost non-existent examples code already takes up to 100 + seconds.
  9. Megalinter is more focused on general solution around linting, and i - at least in this repo is more focused on providing out of the box ready setup for just c++ project. Which may or may not be useful for other people. Megalinter is great for easy integration to existing projects.
  10. More as a joke - i just can't handle default's ❌ icons.. they are... i see only one plus - you want them to go away as fast as possible ;P that's why I've patched them to ⛔ symbol. Although that's maybe only for my personal taste.

Last few days with writing all that megalinter yml's and than setting up just kinda burned me a little bit. Although it was very satisfying to see this kind of report after all this days staring only into flying by raw linter logs. But what i think i can do when i recover - is at least give you some feedback about problems/quirks/ideas that I've encountered in the process of this mass production of this linter wrappers.

All my work is distributed under MIT so fill free to grab it if you consider it somewhat useful to main project (or at least some of your contributors can use it as guidance).

I want to thank you for your time and effort put into megalinter it's really nicely done and have huge value for community. I admire your work of setting up all this automatic generation of documentation/docker images/tests and CI. It's a shame that original superlinter team didn't want to accept you pr. I'll mention your project in updated readme.

Btw, how did you find my repo and discover, that I am mass-producing all this linters?

I don't have linkedin, but if you want to discuss with me you can write to public[dot]melg8[@]gmail[dot]com or just continue in this issue.

Best regards