On this page you will find an overview of Depbot, its components and the main vocable used in the architecture. This will clarify some of the things you will encounter in your experience.
The agent is the component responsible for the identification of dependencies in the codebase, its a self-contained binary that will scan your codebase looking for these dependencies and post these to the Depbot API. The Agent does not post anything else than the dependencies found to the platform. It typically runs within the context of your CI on each build but can be configured differently.
The API receives the dependencies found by the Agent and stores them in a database. It requires a valid API key to be passed, otherwise it will reject the request since the API will not be able to relate the dependencies to the codebase.
The platform is the place where users can view dependencies and their details. It is a web application that runs on a server and is accessible from the internet. It is a single point of entry for all users to view the dependencies they have found, analytics as well as other important information.
On the platform Depbot does periodical analysis and tracks changes across dependencies to provide the best level of experience in terms of Code Health and Security.
Below you can find some of the vocable used in the Depbot architecture, this is important to understand the architecture and how it works.
A codebase is a Git repository, on it there might be dependencies and tools used by a team, the codebase is contained of many lines of codes which may or may not be related to the dependencies.
A dependency is a library that the codebase uses and provides some functionality that otherwise would need to be written by the team, for example a library that provides a database querying functionality.
A tool is something used by the development team as part of the development workflow, for example a tool that is used to compile the codebase or manage dependencies. Depbot itself is a development tool.
A license is a legal document that describes the rights and obligations of a team to use a library, for example the MIT license, the GPL license or the Apache license.
The CI is a tool used to run automated builds of the codebase, for example a Jenkins or Travis.