Skip to content

Commit 636adc0

Browse files
authored
Merge pull request migtools#23 from vsodhi/MTA-2696-multi-lang
MTA-2696: Documentation for multilanguage support
2 parents 65843f3 + 5cffb7e commit 636adc0

File tree

2 files changed

+58
-4
lines changed

2 files changed

+58
-4
lines changed

docs/topics/mta-web-configuring-and-running-an-application-analysis.adoc

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -74,20 +74,19 @@ You can attach tags to the application manually instead of enabling automated ta
7474
+
7575
[NOTE]
7676
====
77-
Analysis engines use standard rules for a comprehensive set of migration targets, but if the target is not included or is a customized framework, custom rules can be added. Only manually uploaded custom rule files are validated.
77+
Analysis engines use standard rules for a comprehensive set of migration targets. However, if the target is not included, is a customized framework, or the application is written in a language that is not supported (for example, Node.js, Python), you can add custom rules by skipping the target selection in the Set Target tab and uploading custom rule files in the Custom Rules tab. Only custom rule files that are uploaded manually are validated.
7878
====
7979

8080
. Click *Next*.
8181
. In *Review*, verify the analysis parameters.
8282
. Click *Run*.
8383
+
8484
The analysis status is `Scheduled` as {ProductShortName} downloads the image for the container to execute. When the image is downloaded, the status changes to `In-progress.`
85-
+
85+
8686
[NOTE]
8787
====
8888
Analysis takes minutes to hours to run depending on the size of the application and the capacity and resources of the cluster.
8989
====
90-
+
9190
[TIP]
9291
====
9392
{ProductShortName} relies on Kubernetes scheduling capabilities to determine how many analyzer instances are created based on cluster capacity. If several applications are selected for analysis, by default, only one analyzer can be provisioned at a time. With more cluster capacity, more analysis processes can be executed in parallel.
@@ -98,3 +97,7 @@ Analysis takes minutes to hours to run depending on the size of the application
9897
Alternatively, hover over the application name to display the pop-over window.
9998
. When analysis is complete, to see its results, open the application drawer by clicking on the application name.
10099

100+
[NOTE]
101+
====
102+
After creating an application instance on the Application Inventory page, the language discovery task starts, automatically pre-selecting the target filter option. However, you can choose a different language that you prefer.
103+
====

docs/topics/yaml-rule-structure-syntax.adoc

Lines changed: 52 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -230,6 +230,9 @@ when:
230230

231231
==== Provider conditions
232232

233+
The Application Analyzer detects the programming languages, frameworks, and tools used to build an application, and it generates default rulesets for each supported provider using the Language Server Protocol (LSP) accordingly.
234+
Each supported provider has a ruleset defined by default and is run independently in a separate container.
235+
233236
{ProductShortName} supports multi-language source code analysis. Searching for a specific language in the source code is enabled using the `provider` condition. This condition defines a search query for a specific language provider. The `provider` condition also specifies which of the provider's "capabilities" to use for analyzing the code.
234237

235238
The `provider` condition has the form `<provider_name>.<capability>`:
@@ -246,6 +249,29 @@ The analyzer currently supports the following `provider` conditions:
246249
* `builtin`
247250
* `java`
248251
* `go`
252+
* `dotnet`
253+
+
254+
:FeatureName: dotnet provider
255+
include::snippets/technology-preview-admonition.adoc[]
256+
257+
[[table-Supported-providers-and-rule-conditions]]
258+
[options="header"][cols="99,99,99,99"][%autowidth]
259+
|===
260+
261+
|Provider rule conditions |Provider name
262+
263+
| Providers that are fully supported and included in the product
264+
| Java
265+
266+
| Providers that have rules already defined in the product
267+
| .NET
268+
269+
|Providers that require custom rulesets for analysis
270+
a|
271+
* Go
272+
* Python
273+
* Node.js
274+
|===
249275

250276
===== `builtin` provider
251277

@@ -406,6 +432,24 @@ when:
406432
<2> Upper bound on the version of the dependency.
407433
<3> Lower bound on the version of the dependency.
408434

435+
===== `dotnet` provider
436+
437+
The `dotnet` is an external provider used to analyze .NET and C# source code. Currently, the provider supports the `referenced` capability.
438+
439+
.`referenced`
440+
441+
The `referenced` capability enables the provider to find references in the source code.
442+
443+
[source,terminal]
444+
----
445+
when:
446+
dotnet.referenced:
447+
pattern: "<pattern>" <1>
448+
namespace: "<namespace>" <2>
449+
----
450+
<1> `pattern`: A regex pattern to match the desired reference. For example, HttpNotFound.
451+
<2> `namespace`: Specifies the namespace to search within. For example, System.Web.Mvc.
452+
409453
==== Custom variables
410454

411455
Provider conditions can have associated custom variables. You can use custom variables to capture relevant information from the matched line in the source code. The values of these variables are interpolated with data matched in the source code. These values can be used to generate detailed templated messages in a rule's action (see xref:yaml-rule-actions_{context}[Message actions]). They can be added to a rule in the `customVariables` field:
@@ -518,4 +562,11 @@ labels: <2>
518562
- key=val
519563
----
520564
<1> The name must be unique within the provided rulesets.
521-
<2> Ruleset labels are inherited by all rules that belong to the ruleset.
565+
<2> Ruleset labels are inherited by all rules that belong to the ruleset.
566+
567+
To execute any application analysis, run the following command. Replace <application_to_analyze> with your application, <output_dir> with the directory of your choice, and <custom_rule_dir> with the custom rulesets file.
568+
----
569+
$ mta-cli analyze --input=<application_to_analyze> --output=<output_dir> --rules=<custom_rule_dir> --enable-default-rulesets=false
570+
----
571+
572+
On initiation, the mta-cli tool determines the type of application and the corresponding provider needed for analysis. It then starts the provider in a container that has the required dependencies and tools. Finally, the provider uses the analyzer to execute a series of rulesets to analyze the source code.

0 commit comments

Comments
 (0)