InnerSource components are internally developed components that are shared with other internal projects. InnerSource components are commonly built using open source. When consumed by other projects, InnerSource and its dependencies can produce many redundant policy violations in the consuming Application Composition Report. These policy violations are hard to remediate and cause a lot of wasted time. The goal of InnerSource Insight is to reduce the work needed to remediate and manage consumed InnerSource dependencies.
What is InnerSource Insight?
To explain, let's use a common scenario that causes InnerSource violation. In this case, the InnerSource common database framework was built with open-source components that have violations.
The scenario is two projects: P and C:
- Both projects have an associated IQ application.
- Project P creates a common database framework that Project C uses, making project P a producer of an InnerSource component and project C a consumer of an InnerSource component.
- When viewing the Application Composition Report for project C, one can now see these violations are from project P, making it easy to determine who brought in the violations.
Below is an illustration of this scenario:
- npm NEW IN RELEASE 122
Requirements for InnerSource Insight
Before the consumer can use InnerSource Insight, the producers need to be evaluated by InnerSource Insight. To do this, please run the evaluation for the producers. Once the producers have been evaluated by InnerSource Insight, InnerSource Insight will be able to identify and associate with the consumers
How to use InnerSource Insight for Maven
InnerSource Insight for maven requires the producer and the consumer use the CLM Maven plugin or the Gradle plugin (v2.0.4 or higher). When both are using a supported plugin or format, the consumer's Application Composition Report will identify InnerSource components and their associated dependencies. Check out the Sonatype CLM for Maven documentation and the Gradle Plugin to learn more.
CLM Maven in a CI Environment
CLM Maven goal index is valid for InnerSource Insight in a CI environment such as Jenkins. For more information please refer to Sonatype CLM for Maven.
How to use InnerSource Insight for NPM
InnerSource Insight for npm adopts ecosystem manifest files to identify InnerSource and other dependecy types. Check out the NPM Application Analysis documentation to learn more about supported npm manifests. InnerSource insight for npm works with following IQ scanners and plugins.
- CLI (v 122+)
- Jenkins plugin (Coming Soon)
- Bamboo plugin (Coming Soon)
Example Application Composition Report Before and After
Before these changes, the InnerSource component is unknown and no indication of the InnerSource transitive dependencies.
After these changes, InnerSource is recognized and all the associated transitive dependencies are indicated.
For IQ Server prior to release 122 this appears as follows
NEW IN RELEASE 122
The Application Composition Report has changed in how it shows InnerSource dependencies and InnerSource transitive dependencies.
Note that the root ancestor of a transitive dependency is the application's direct dependency that is responsible for bringing in that transitive dependency or one of its ancestors.
Previously, we nested each transitive dependency with one or more InnerSource root ancestors beneath its first InnerSource root ancestor.
Now, instead of nesting InnerSource transitive dependencies, we add an InnerSource icon alongside its transitive dependency icon as follows.
|Direct dependency which is also an InnerSource dependency.|
Transitive dependency with only InnerSource root ancestors.
Additionally, for each InnerSource dependency, we now show a count of its transitive policy violations i.e. the number of policy violations from all transitive dependencies with this InnerSource dependency as a root ancestor.
If you hover over the InnerSource icon of a transitive dependency, then it will show you a tooltip listing its InnerSource root ancestors.
The CIP also provides a link to the producer report via View Latest Report:
NEW IN RELEASE 122
For transitive dependencies, the CIP will add a tag next to any InnerSource root ancestors.
Additionally, for InnerSource only transitive dependencies i.e. transitive dependencies with only InnerSource root ancestors, the CIP will also show an InnerSource tag next to their transitive dependency tag in the CIP header.
Better Detection of Direct Dependencies
There are some cases that a dependency might be associated with the consumer report and an InnerSource component (producer), in this case, the dependency might be either Direct or Transitive, IQ server prioritizes the direct dependencies so they are associated and shown under the consumer report.