Skip to content

Continuous Integration (CI)

Continuous Integration (CI) is an essential aspect of software development which involves integrating changes and testing them automatically. CI allows us to maintain high-quality code by catching issues early and often in the development process. At Ultralytics, we use various CI tests to ensure the quality and integrity of our codebase.

CI Actions

Here's a brief description of our CI actions:

  • CI: This is our primary CI test that involves running unit tests, linting checks, and sometimes more comprehensive tests depending on the repository.
  • Docker Deployment: This test checks the deployment of the project using Docker to ensure the Dockerfile and related scripts are working correctly.
  • Broken Links: This test scans the codebase for any broken or dead links in our markdown or HTML files.
  • CodeQL: CodeQL is a tool from GitHub that performs semantic analysis on our code, helping to find potential security vulnerabilities and maintain high-quality code.
  • PyPI Publishing: This test checks if the project can be packaged and published to PyPi without any errors.

CI Results

Below is the table showing the status of these CI tests for our main repositories:

Repository CI Docker Deployment Broken Links CodeQL PyPI and Docs Publishing
yolov3 YOLOv3 CI Publish Docker Images Check Broken links CodeQL
yolov5 YOLOv5 CI Publish Docker Images Check Broken links CodeQL
ultralytics ultralytics CI Publish Docker Images Check Broken links CodeQL Publish to PyPI and Deploy Docs
hub HUB CI Check Broken links
docs Check Broken linksCheck Domains pages-build-deployment

Each badge shows the status of the last run of the corresponding CI test on the main branch of the respective repository. If a test fails, the badge will display a "failing" status, and if it passes, it will display a "passing" status.

If you notice a test failing, it would be a great help if you could report it through a GitHub issue in the respective repository.

Remember, a successful CI test does not mean that everything is perfect. It is always recommended to manually review the code before deployment or merging changes.

Code Coverage

Code coverage is a metric that represents the percentage of your codebase that is executed when your tests run. It provides insight into how well your tests exercise your code and can be crucial in identifying untested parts of your application. A high code coverage percentage is often associated with a lower likelihood of bugs. However, it's essential to understand that code coverage does not guarantee the absence of defects. It merely indicates which parts of the code have been executed by the tests.

Integration with codecov.io

At Ultralytics, we have integrated our repositories with codecov.io, a popular online platform for measuring and visualizing code coverage. Codecov provides detailed insights, coverage comparisons between commits, and visual overlays directly on your code, indicating which lines were covered.

By integrating with Codecov, we aim to maintain and improve the quality of our code by focusing on areas that might be prone to errors or need further testing.

Coverage Results

To quickly get a glimpse of the code coverage status of the ultralytics python package, we have included a badge and sunburst visual of the ultralytics coverage results. These images show the percentage of code covered by our tests, offering an at-a-glance metric of our testing efforts. For full details please see https://codecov.io/github/ultralytics/ultralytics.

Repository Code Coverage
ultralytics codecov

In the sunburst graphic below, the innermost circle is the entire project, moving away from the center are folders then, finally, a single file. The size and color of each slice is representing the number of statements and the coverage, respectively.

Ultralytics Codecov Image

FAQ

What is Continuous Integration (CI) in Ultralytics?

Continuous Integration (CI) in Ultralytics involves automatically integrating and testing code changes to ensure high-quality standards. Our CI setup includes running unit tests, linting checks, and comprehensive tests. Additionally, we perform Docker deployment, broken link checks, CodeQL analysis for security vulnerabilities, and PyPI publishing to package and distribute our software.

Ultralytics uses a specific CI action to check for broken links within our markdown and HTML files. This helps maintain the integrity of our documentation by scanning and identifying dead or broken links, ensuring that users always have access to accurate and live resources.

Why is CodeQL analysis important for Ultralytics' codebase?

CodeQL analysis is crucial for Ultralytics as it performs semantic code analysis to find potential security vulnerabilities and maintain high-quality standards. With CodeQL, we can proactively identify and mitigate risks in our code, helping us deliver robust and secure software solutions.

How does Ultralytics utilize Docker for deployment?

Ultralytics employs Docker to validate the deployment of our projects through a dedicated CI action. This process ensures that our Dockerfile and associated scripts are functioning correctly, allowing for consistent and reproducible deployment environments which are critical for scalable and reliable AI solutions.

What is the role of automated PyPI publishing in Ultralytics?

Automated PyPI publishing ensures that our projects can be packaged and published without errors. This step is essential for distributing Ultralytics' Python packages, allowing users to easily install and use our tools via the Python Package Index (PyPI).

How does Ultralytics measure code coverage and why is it important?

Ultralytics measures code coverage by integrating with Codecov, providing insights into how much of the codebase is executed during tests. High code coverage can indicate well-tested code, helping to uncover untested areas that might be prone to bugs. Detailed code coverage metrics can be explored via badges displayed on our main repositories or directly on Codecov.



Created 2023-11-12, Updated 2024-07-04
Authors: glenn-jocher (8), Burhan-Q (1)

Comments