Introduce/Discuss Module Linter

[Flipez]

Currently we keep track of todos (like outdated OS, eol OS, not synced..) in our redis cache. The poll information about every repo und display this in the dashboard.

Pro: You now can visit the VPT-Dashboard, click through the todos and go to the repo and resolve it.
Con: You have to go to a second place (the VPT) to get informed about it.

Proposal:

We can pretty accurately define an issue. We know when a sync is missing or if and what OS is wrongly supported. I'd like to handle these like Rubocop handles styles in Ruby.

If we detect an issue with a module we could create a Github issue listing everything what went wrong (and continiously update this) and give advise on what to do. We later could even provide a pull request for some if these.

For edgecases we then could define something like a vpt.yml in which we could define repositoy specific rules. The "linter" would then ignore the issue and adjsut the Github issue.

As this is very worklow related I'd like to discuss this with a wider contributer community. In the end something like this should help, not annoy.

[bastelfreak]

Hi @voxpupuli/collaborators, we would like to get some feedback here :)

[logicminds]

Interesting idea. TBH, Vox has nailed down some really awesome workflows when it comes to maintaining a large set of modules. Anything we do, should be part of a toolset so large enterprises can also enjoy and even pay for continuing support.

Make this tool generic enough to also work with Gitlab.

[ekohl]

Something that I always find difficult is modules that get heavily outdated. So we often already have an open PR for modulesync but nobody finishes it. An issue probably won't fix it.

With regards to the tools we could introduce a gem that analyzes metadata.json. Basically bundling up the scripts we already have but make them usable within a module. Once you have that, then you can also run the the tests in a cron and see if it actually passes. That way you'd just have to focus on keeping the build green.

PDK takes the approach of storing the sync data in metadata.json. Personally I dislike that, but it does mean you check from the module itself if it's in sync.

In theory then it just becomes listing the CI build status for every module, though something I do miss in Travis is that there's no summary. In Jenkins you could always read junit.xml and see which tests failed. Because Travis lacks that capability, we are now building a replacement.

Now I'm not advocating for Jenkins per se. I get people dislike it, but it has solved a lot these issues already. I'm sure there must be some existing tools out there.