Megalinter Json Scheme Update

[daniel442li]

Is your feature request related to a problem? Please describe.
While navigating the Megalinter repository, I noticed some config variables which aren't described in the default megalinter-configuration.jsonschema.json schema. Because they are missing, these features are limited to users that review the code. I have gathered these configuration variables into 2 groups, the one we want to add to the schema and the one we do not, and why.

Describe the solution you'd like
Update the megalinter-configuration.jsonschema.json file to include actively used configuration variables in the megalinter python code. These changes would provide more actuate documentation and improve IDE schema plug-in support.

Describe alternatives you've considered
Possibly using comments or directly stating a reason for ommiting the scheme

Additional context

**Should be added to the schema, since these are variables for user to change at runtime.

The following are used in reporters. These are defined parameters that define how the report will turn out based on given variables that are set before runtime.

OUTPUT_DETAIL - determines if the report gives a detailed report or a simple one.
OUTPUT_DETAILS - Typo change to OUTPUT_DETAIL in test code and workflows Search · OUTPUT_DETAILS (github.com)
OUTPUT_FORMAT – is a super-linter legacy variable that determines which report format to use such as Text or Tap

The following are all used to produce a GitHub report, comment on a GitHub pull, and produce a marker to find the same comment again. The marker includes the workflow name and job if available (via the GITHUB_WORKFLOW and GITHUB_JOB environment variables) to avoid clashes between multiple Mega-Linter jobs operating on the same PR. If the PR isn’t found, the code will skip the posting of a PR comment.

CI_ACTION_RUN_URL
CI_JOB_TOKEN
CI_JOB_URL
CI_MERGE_REQUEST_ID
CI_MERGE_REQUEST_IID (Possible typo)
CI_OPEN_MERGE_REQUESTS
CI_PROJECT_ID
CI_PROJECT_NAME
CI_SERVER_URL

The following is used in a file reporter to determine if the reporter sends a report. This sends report artifacts by email and if the file reporter reports false, then an email is not sent. Also, if the Megalinter passes with no errors, no email will be sent. This can be changed at runtime.

FILEIO_REPORTER_SEND_SUCCESS

The variable below uses an auth token to determine if Git files are different . This isn’t always necessary and is used when the user is unable to access the Git repository without an authentication token.

GIT_AUTHORIZATION_BEARER

The variable below defines the level of detailed that is outputted to the json file. The variable determines if the file will create a detailed or simple report. A detailed report does not filter out fields from the report and gives the whole report raw.

JSON_REPORTER_OUTPUT_DETAIL

The variable below details the location (directory) of the Dockerfile’s volume which is where persistent storage is created. This is created at the Dockerfile’s build time and the workspace is passed into the object.

MEGALINTER_VOLUME_ROOT

The variable below will disable Github status for each linter if 'false'. Fundamentally, does the same action as the GITHUB_STATUS_REPORTER variable.

MULTI_STATUS

Should NOT be added to the schema:

The following are used in logging as well as building the docker image. They are defined at Dockerfile build time and are used by config for some reporters. Environment variables are set during image build time and will not change at runtime. This configuration attributes do not have to be in the schema since they are set at build time and should not be changed at runtime.

BUILD_DATE
BUILD_REVISION
BUILD_VERSION

All the GitHub variables are used to create a report which posts a GitHub status for each linter. They are defined before the runtime of the Megalinter and are used to create visual guidance about Megalinter’s success/failure. The activation of the status reporter can be disabled at runtime. This configuration attributes do not have to be in the schema since they are set at Docker build time and are global environment variables which should not be changed at runtime.

GITHUB_REPOSITORY
GITHUB_RUN_ID
GITHUB_SHA
GITHUB_TARGET_URL
GITHUB_TOKEN

The variable below determines the MegaLinter flavor used for this repo in the main Megalinter class. If a flavor is selected and there are no flavor suggestions, the Megalinter will ignore linters that are not in the current flavor. Otherwise, Megalinter will give a list of flavor suggestions.

MEGALINTER_FLAVOR

The following are deprecated and their value of them has no effect on how the code is run.

POST_GITHUB_COMMENT
POST_GITLAB_COMMENT

[nvuillam]

@daniel442li That's what I call a great investigation, thanks a lot for doing it :)

The JSON schema is not supposed to contain every variable that can be used within all MegaLinter, but every variable that can be used in local configuration file .mega-linter.yml (for validation of .mega-linter.yml itself, + IDE support with validation & auto-completion)

OUTPUT_DETAIL - determines if the report gives a detailed report or a simple one.
OUTPUT_DETAILS - Typo change to OUTPUT_DETAIL in test code and workflows Search · OUTPUT_DETAILS (github.com)
OUTPUT_FORMAT – is a super-linter legacy variable that determines which report format to use such as Text or Tap

Agreed, this is a typo and must be changed to OUTPUT_DETAIL, and OUTPUT_DETAIL and OUTPUT_FORMAT are missing.
Please note that OUTPUT_FORMAT is not in the doc because I don't want people to use it (there are REPORTER variables instead), except if they just migrated from SuperLinter :)

CI_ACTION_RUN_URL
CI_JOB_TOKEN
CI_JOB_URL
CI_MERGE_REQUEST_ID
CI_MERGE_REQUEST_IID (Possible typo)
CI_OPEN_MERGE_REQUESTS
CI_PROJECT_ID
CI_PROJECT_NAME
CI_SERVER_URL

These are gitlab CI predefined variables, their value is dynamic and provided by Gitlab CI Runner: they will never have to be used in .mega-linter.yml config file, so they must not be in the json schema

FILEIO_REPORTER_SEND_SUCCESS

Agreed, it has to be added to the schema

GIT_AUTHORIZATION_BEARER

This variable value is always dynamically provided by the CI platform, and having it in a .mega-linter.yml would be a huge security risk ^^

JSON_REPORTER_OUTPUT_DETAIL

Agreed, it has to be added to the schema

MEGALINTER_VOLUME_ROOT

It seems we use this one only for internal CI, and as it is always as a docker run parameter, I don't see cases where it could be used in .mega-linter.yml

MULTI_STATUS

This is legacy SuperLinter variable, so no need to document it, but for compatibility of migrating users, you're right it has to be added :)

MEGALINTER_FLAVOR

Internal variable of MegaLinter directly defined when building docker images, messing with it could break the runs ;)

POST_GITHUB_COMMENT
POST_GITLAB_COMMENT

They are used in the code, so it could be a breaking change to remove them ^^

Thanks again for your analysis, I started the updates in a branch :)

[nvuillam]

@daniel442li if you want to have a look at the PR, please be my guest :)

#1625

[daniel442li]

Looks amazing!

[nvuillam]

Thanks !
Please let us know if you see other issues, your investigation was a great job :)