Hello @MichelFR, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

Hello! Gemini here, providing a summary of this pull request. This PR introduces a new sensor/attribute for Docker containers to identify how they were created, specifically distinguishing between containers started directly with the Docker CLI and those managed by Docker Compose. This is achieved by inspecting the container's labels for common Docker Compose patterns. The new origin information is then exposed via MQTT for Home Assistant discovery and included in the standard container state messages.

Highlights

• New Sensor/Attribute: Adds a new docker_created_by sensor/attribute to indicate if a container was created by 'Docker' or 'Composer'.
• Compose Detection Logic: Implements a static method DockerService.getCreatedBy to check container labels for com.docker.compose prefixes to determine the origin.
• Home Assistant Integration: Adds Home Assistant MQTT discovery configuration for the new docker_created_by sensor and includes the origin in the main container state MQTT payload.
• Unit Tests: Includes new unit tests specifically for the DockerService.getCreatedBy method to ensure correct detection logic.

Changelog

• README.md
  • Removed an empty line.
• src/services/DockerService.ts
  • Added a new static method getCreatedBy to determine if a container was created by Docker Compose or standard Docker based on labels.
• src/services/HomeassistantService.ts
  • Added Home Assistant discovery configuration for the new docker_created_by sensor.
  • Included the container's creation origin (detected by DockerService.getCreatedBy) in the main container state MQTT payload.
• tests/DockerServiceCreatedBy.test.ts
  • Added a new test file with unit tests for the DockerService.getCreatedBy method, covering both 'Composer' and 'Docker' cases.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Container starts fast,
Compose labels tell its birth,
Docker or Composer?

Code Review

This PR effectively introduces the docker_created_by sensor, enhancing container information. The implementation in DockerService.ts for detecting the origin (Composer vs. Docker) is clear and robust, and its integration into HomeassistantService.ts follows existing patterns well. The new unit tests for DockerService.getCreatedBy are also a great addition and cover the primary logic paths.

One point of clarification: The PR description mentions '- remove the README addition that described the new sensor'. However, the diff for README.md only shows the removal of a blank line. Could you clarify if there was other content related to the new sensor in the README that was intended to be removed, or if this description point refers to something else?

Overall, the code changes look good and improve the functionality as intended. The work is high quality.

Summary of Findings

• Use of Magic Strings: In src/services/DockerService.ts, the strings "Composer" and "Docker" returned by getCreatedBy are used directly. While clear in this context, consider defining them as constants for improved maintainability, especially if these values were to be used elsewhere or become more complex. (Severity: low, not commented directly due to review settings)
• Unit Test Explicitness: The unit tests for DockerService.getCreatedBy in tests/DockerServiceCreatedBy.test.ts cover the main scenarios well. For even greater explicitness, consider adding a test case specifically for when container.Config.Labels is an empty object or null/undefined, although the current implementation handles this correctly and it's implicitly covered. (Severity: low, not commented directly due to review settings)
• README.md Change Clarification: The PR description states a README addition about the new sensor was removed, but the diff only shows a blank line removal. Clarification on this point would be helpful. (Severity: low, addressed in general comments)

Merge Readiness

The code changes are well-implemented and add valuable functionality. After clarifying the README.md change mentioned in the general feedback, this PR appears ready for merging from a technical standpoint. As an AI reviewer, I cannot approve pull requests; please ensure it undergoes further review and approval by the maintainers.