Reports format
Hello,
GitLab support actually report in formats:
- artifacts:reports:junit
- artifacts:reports:codequality
- artifacts:reports:sast
- artifacts:reports:dependency_scanning
- artifacts:reports:container_scanning
- artifacts:reports:dast
- artifacts:reports:license_management
- artifacts:reports:performance
In our case, however, the first two formats seem appropriate. I wonder why you chose codequalify format? Does it have any advantage over the other? It seems to me that it has less support in the community.
If we want to add support for the JUnit format, we should resolve the issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/50964 https://github.com/eslint/eslint/issues/11068 What will ensure integration with Gitlab without the installation of additional software.
Greets
Activity
Hello, first of all, thank you for creating this issue. This lets me know people other than myself actually use it.
If I understand the question correctly, you wonder why I decided to pick the codequality format in favour of the junit format.
The answer is actually very simple; I always thought of junit as a unit test report format, not a linting format. However, your question did make me rethink of why I think so.
- The junit format originates from the Java testing framework junit. I think this format is intended for tests, not linting results.
- Linters don't actually create tests that may either succeed or fail. They just report rule violations, meaning there is no success state. This would be weird if for example the junit results would be graphed.
- GitLab has support for multiple linters by embracing code climate engines. This includes codeclimate-eslint. This made me conclude that the codequality format should be used for linters. I created this package, because I think it’s better to use the same tooling, lesser known plugins, lock files, etc. as are used locally, instead of a prebuilt Docker image provided by code climate.
After having thought this through, I believe my initial ideas are correct.
I hope you can see my point and use this package. Otherwise, nothing is stopping you from fixing eslint#11068
As soon as gitlab-org/gitlab-ee#9014 is resolved, I’ll create similar projects for stylelint and prettier.
