konveyor / analyzer-lsp Goto Github PK

Today we do not have a defined approach to how to pass templated context values into condition information fields.

Right now, this is the responsibility of the provider, but when moving to external providers, I believe that this needs to become the responsibility of the engine.

I think that for now, we can test out the functionality we do have and this will have to be part of the external provider work.

We need to determine the root here and standardize the output

We need to document provider configuration settings.

Error :

line 0: missing '['

There is value in classifying violations based on factors such as severity, urgency etc. In windup, there is a separate field category to define those characteristics about a violation. We should consider having something similar in analyzers.

Until we decide on the final schema for the rules and generate docs, would it be possible to add a comment about the rule if its not so intuitive. Thanks in advance :)

Once we determine how external providers can be added, we will want to figure out all of this.

It will help extract text from the document and compare it with a value/regex, returning a violation on match.

A logger that can be enabled to run with user-readable logs and structured logging as well as levels to aid in debugging I think are the primary requirements

See this commit for test data. Both added rules should be triggered according to the test data, but I can't see any references in the results.

We need to modify message field to have a title in addition to the actual message. This is needed in the report.

Today, a provider is responsible for adding extra information for its particular capability. We need an easy way for these things to provide this information, such that someone can write rules against this information.

LSP analyzers must support windup rules. The goal is to support 80% of existing windup rules. In the first phase, windup rules can be converted to analyzers manually. In the next phase, a windup shim will facilitate running windup rules with analyzers.

This is to track work on the first iteration of integration work for Analyzers <-> Konveyor. Mainly things I am looking at is passing stuff coming from the Hub as an input to analyzers and pushing back results as a JSON back into the Hub.

In the future, it might be nice to have a location from the dependency file where a dependency can be changed.

We probably should have some validation on rule ids during rule parsing

We need to report errors occurred when creation of violations when a rule partially matches or otherwise. Windup has an Optional category for violations that address this.

Let's start thinking about how we want to get windup rules in analyzers

We need to make it so that folks can make sure that something DOES NOT exist.

Rule authors should be able to categorize technology tags.

Currently we don't point to where the dependencies are coming from, which could be a useful piece of information. We should track and report that. We should also change the Location field in the dependency.Dep to match Location in the rest of the code base (ie it should point somewhere in the codebase) and find a different term to report what it currently gathers for java (or add it to an extras field for arbitrary metadata)

We addressed inter-condition pipelining in Demo A. This issue captures the need for pipelining within rules.

We need to enable and support pipelining in the rule

This will track all the work left outstanding:

• Initial PR: #20
• #22
• #23
• #24

Everytime a go source file is added or removed it causes the demo test to fail. We should update that to be less specific so that it doesn't need to be constantly updated

We nee do to make sure that we don't break this.

Generate a violation for application tags

We need to get README to a point where a user / contributor can run an analyzer independently by following instructions.

Currently rules can only be written in json but yaml is a superset of json that is more fun to write and read so we should support that too

We need to set up cobra or go flags to make the settings files overridable.

This is a large amount of work, and something that I think is important to get done ASAP.

Analyzers need an ability to perform dependency analysis.

One of the concerns could be the performance of a given provider. We will want the ability to quickly diagnose if the time taken is in the engine or a given provider.

We will also want to see the traces from our providers to see if anything is taking longer than it should.

This is intended as a tracking issue to follow work on-going for establishing feature parity WindUp for the Java Analysis.

Assumption is we will use the rules & tests WindUp provides from https://github.com/windup/windup-rulesets/tree/master/rules/rules-reviewed to help establish feature parity.

@pranavgaikwad @fabianvf Copying this issue from PR review. We merged w/o fixing this but want to make sure we don't forget it and have the conversation.

We have ability to return schemas for template context info created by providers. We need something similar for Violations that captures extra information put in there so that end users can parse the extras correctly

Violations in output need an additional type to distinguish Info type output

Add support for following CLI options:

Current State

Today there are 4 Categories in the windup project.

1. Potential
2. Mandatory
3. Information
4. optional

The potential is supposed to mean that the Rule ran successfully, and there may or may not be an issue. We can't tell.

Mandatory is that the Rule ran correctly and the Rule states this must be fixed

Information is that the Rule ran correctly, and the Rule states that this is just for information, which could mean there is a problem in the future but not something you must fix.

Optional is that a rule ran unsuccessfully, and it might have a violation and may not.

Proposed State

Consolidating these and making it easier for both end users to understand what the category is supposed to mean and what a rule writer should set is the goal of this issue.

For the Rule's categories, I am proposing two mutually exclusive buckets.

1. Mandatory will be when the Rule states that this must be fixed based on the ruleset. This will only be set for rules that have run successfully
2. Potential will be when the Rule states this is potentially an issue. This will only be set for rules that have run successfully

We need to create a new bucket for partial matches/errors. I would prefer to call this something like Errors, which will be different than the violations that use the categories above. In this world, we would have two new error categories:

1. Partial Match -> This Rule ran semi-successfully, and some conditions matched, but there were failures in others. This should include the error message and other stuff
2. Failure -> this Rule did not run successfully in any way.

We also need a third bucket of rules for rules that ran successfully but did not have any violations. I believe this should just be something like PassedRules or something.

We should discuss the names here so that once we implement it, we can point back to this.

Adding in folks that this will probably have an impact on:
@rromannissen @jortel @ibolton336 @pranavgaikwad @fabianvf

Publish first version of rule format with documentation.

Using: https://github.com/JetBrains/intellij-community/tree/master/plugins/java-decompiler/engine which can be pulled from here: https://mvnrepository.com/artifact/com.jetbrains.intellij.java/java-decompiler-engine the java LSP bundle to decompile and then re-initialize the project.