This project defines two stages of project analysis, which can be used to drive delivery decisions and to classify projects.
The two stages are:
- Project Analysis: First phase. Takes the project source code and
builds an analysis that may be persisted. The most important part of
a
ProjectAnalysis
is theelements
property, whose value is an indexed type which values of typeTechnologyElement
. Because aProjectAnalysis
is designed to be serialized and persisted it contains only data, and no functions. - Interpretation: Second phase. Requires a
ProjectAnalysis
but not source code, so can be run on persisted analyses. AnInterpretation
is computed when necessary and not serialized to JSON, so it can specify functions and delivery goals.
Analysis and interpretation is designed to be extensible. Additional "scanners" and "interpreters" can be added wtihout affecting existing capabilities.
Two additional concepts are principally relevant to offline use, to classify projects and provide a basis for project querying:
- Seed analysis: The ability to use multiple
TransformRecipeContributor
implementations to contribute parameters and transforms that can enable any project to be used as a seed. This "contribution" model ensures that we avoid the Cartesian product problem with seeds: E.g. if we care about AWS Lambda and Kubernetes, Node and Spring, we don't need 4 distinct generators (Lambda/Node, Lambda/Spring, Kube/Node and Kube/Spring), but can use one "universal" generator that applies whichever contributions are relevant to the current seed. - Project scoring: The ability to attach scores to an interpretation for various dimensions of a project, and to calculate a weighted composite score based on individual scores.
Seed analysis is only performed when a project analysis is performed with the full
option flag
set to true. Scanner registrations that return technology elements can also specify
whether or not they should fire depending on the invocation options. This is important
for scanners that are expensive, such as calculation of the number of lines of code
in a repository, which requires reading every file. Typically, such analyses
are performed only infrequently, and persisted for future use.
See the Developer Quick Start to jump straight to creating an SDM.
Contributions to this project from community members are encouraged and appreciated. Please review the Contributing Guidelines for more information. Also see the Development section in this document.
This project is governed by the Code of Conduct. You are expected to act in accordance with this code by participating. Please report any unacceptable behavior to code-of-conduct@atomist.com.
Please see [docs.atomist.com][atomist-doc] for developer documentation.
Follow @atomist and The Composition blog related to SDM.
General support questions should be discussed in the #help
channel in the Atomist community Slack workspace.
If you find a problem, please create an issue.
You will need to install Node.js to build and test this project.
Install dependencies.
$ npm install
Use the build
package script to compile, test, lint, and build the
documentation.
$ npm run build
Releases are handled via the Atomist SDM. Just press the 'Approve' button in the Atomist dashboard or Slack.
Created by Atomist. Need Help? Join our Slack workspace.