-
-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Megalinter Json Scheme Update #1621
Comments
@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
Agreed, this is a typo and must be changed to OUTPUT_DETAIL, and OUTPUT_DETAIL and OUTPUT_FORMAT are missing.
These are gitlab CI predefined variables, their value is dynamic and provided by Gitlab CI Runner: they will never have to be used in
Agreed, it has to be added to the schema
This variable value is always dynamically provided by the CI platform, and having it in a
Agreed, it has to be added to the schema
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
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 :)
Internal variable of MegaLinter directly defined when building docker images, messing with it could break the runs ;)
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 :) |
@daniel442li if you want to have a look at the PR, please be my guest :) |
Looks amazing! |
Thanks ! |
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
The text was updated successfully, but these errors were encountered: