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
elementsproperty, whose value is an indexed type which values of type
TechnologyElement. Because a
ProjectAnalysisis designed to be serialized and persisted it contains only data, and no functions.
- Interpretation: Second phase. Requires a
ProjectAnalysisbut not source code, so can be run on persisted analyses. An
Interpretationis 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
TransformRecipeContributorimplementations 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.
Code of conduct
Please see [docs.atomist.com][atomist-doc] for developer documentation.
General support questions should be discussed in the
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.
Build and test
$ npm install
build package script to compile, test, lint, and build the
$ npm run build
Releases are handled via the Atomist SDM. Just press the 'Approve' button in the Atomist dashboard or Slack.