Add local repo test #48
Conversation
WalkthroughThis pull request adds CMCONF integration for the FLEET_PROTOCOL system, introduces support for a new "fleet-os-2" Docker image, creates test data files for package builds (fleet-protocol-cpp, fleet-protocol-interface, nlohmann-json, and zlib), adds a new integration test for local repository builds, and extends the packager utility with a use_local_repo flag. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Right now it requires some changes. After merging this PR and creating new release, this new version of io-module must be used in tests to finish the tests succesfully. Otherwise the PR should be ready. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
tests/integration_tests/test_build_apps.py (1)
152-202: Simplify redundant conditionals in expected_returncode.The test logic correctly validates local repository builds, but lines 168-172 and 196-200 contain redundant conditionals. Since the test skips on line 157 when the app doesn't support the image, the
does_app_support_imagecheck in the expected_returncode will always be true.Apply this diff to simplify:
run_packager( packager_binary, "build-app", context=context, image_name=test_image, output_dir=test_repo, name=app, use_local_repo=True, expected_result=PackagerExpectedResult.FAILURE, - expected_returncode=( - PackagerReturnCode.BUILD_ERROR - if does_app_support_image(app, test_image) - else PackagerReturnCode.DEFAULT_ERROR - ), + expected_returncode=PackagerReturnCode.BUILD_ERROR, )And for the second invocation:
run_packager( packager_binary, "build-app", context=context, image_name=test_image, output_dir=test_repo, name=app, use_local_repo=True, expected_result=PackagerExpectedResult.SUCCESS, - expected_returncode=( - PackagerReturnCode.SUCCESS - if does_app_support_image(app, test_image) - else PackagerReturnCode.DEFAULT_ERROR - ), + expected_returncode=PackagerReturnCode.SUCCESS, )
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (23)
example_context/config/CMCONF_FLEET_PROTOCOLConfig.cmake(1 hunks)example_context/config/README.md(1 hunks)example_context/docker/debian12/Dockerfile(1 hunks)example_context/docker/fedora40/Dockerfile(1 hunks)example_context/docker/fedora41/Dockerfile(1 hunks)example_context/docker/fleet-os-2/Dockerfile(1 hunks)example_context/docker/ubuntu2404/Dockerfile(1 hunks)example_context/package/fleet-protocol-cpp/fleet_protocol_cpp_debug.json(1 hunks)example_context/package/fleet-protocol-cpp/fleet_protocol_cpp_release.json(1 hunks)example_context/package/fleet-protocol-interface/fleet_protocol_debug.json(1 hunks)example_context/package/fleet-protocol-interface/fleet_protocol_release.json(1 hunks)tests/integration_tests/test_build_apps.py(2 hunks)tests/test_data/example/app/io-module/io-module_debug.json(2 hunks)tests/test_data/example/app/io-module/io-module_release.json(2 hunks)tests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_debug.json(1 hunks)tests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_release.json(1 hunks)tests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_debug.json(1 hunks)tests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_release.json(1 hunks)tests/test_data/test_packages/nlohmann-json/nlohmann_json_debug.json(1 hunks)tests/test_data/test_packages/nlohmann-json/nlohmann_json_release.json(1 hunks)tests/test_data/test_packages/zlib/zlib_debug.json(1 hunks)tests/test_data/test_packages/zlib/zlib_release.json(1 hunks)tests/test_utils/test_utils.py(2 hunks)
🧰 Additional context used
🧠 Learnings (16)
📓 Common learnings
Learnt from: mikusaq
Repo: bacpack-system/packager PR: 43
File: tests/test_data/test_packages/test_package_1_25/zlib_debug.json:4-6
Timestamp: 2025-08-29T09:51:15.354Z
Learning: In the bacpack-system/packager repository, test files with invalid Git revisions like "not_real_version_tag" in tests/test_data/test_packages/test_package_1_25/ are intentional negative test cases designed to test error handling, not actual issues that need fixing.
Learnt from: mikusaq
Repo: bacpack-system/packager PR: 43
File: tests/test_data/test_packages/test_package_3_06/lz4_release.json:7-9
Timestamp: 2025-08-29T09:53:32.961Z
Learning: For the bacpack-system/packager repository, using moving branch references like "master" in test data Git revisions is acceptable and preferred by the team, even in cases where it might affect test determinism.
Learnt from: mikusaq
Repo: bacpack-system/packager PR: 43
File: tests/test_data/test_packages/test_package_1_18/zlib_release.json:3-6
Timestamp: 2025-08-29T09:50:44.695Z
Learning: For the bacpack-system/packager repository, Git revision tags (like "v1.2.11") are acceptable in test data JSON files and do not need to be replaced with commit SHAs.
Learnt from: mikusaq
Repo: bringauto/packager-fleet-protocol-context PR: 8
File: docker/ubuntu2204/Dockerfile:30-30
Timestamp: 2025-08-27T12:47:58.557Z
Learning: The packager-fleet-protocol-context repository contains Dockerfiles that are processed by the external Packager build system from the BacPack system. The Packager system provides build stages like `packager-context` that these Dockerfiles reference via `COPY --from=packager-context`, making these references valid and required even though the stages aren't defined within the individual Dockerfiles themselves.
Learnt from: mikusaq
Repo: bringauto/packager-fleet-protocol-context PR: 8
File: docker/ubuntu2204/Dockerfile:30-30
Timestamp: 2025-08-27T12:47:58.557Z
Learning: In the packager-fleet-protocol-context repository, Dockerfiles use `COPY --from=packager-context` which is provided by the external Packager build system, not defined within the individual Dockerfiles themselves.
Learnt from: mikusaq
Repo: bringauto/packager PR: 24
File: example/package/fleet-protocol-internal-client/internal_client_debug.json:23-23
Timestamp: 2024-10-09T05:03:50.249Z
Learning: The repository URL for 'fleet-protocol-internal-client' is 'https://github.com/bringauto/internal-client-cpp.git', not 'https://github.com/bringauto/fleet-protocol-internal-client.git'.
📚 Learning: 2025-08-27T12:47:58.557Z
Learnt from: mikusaq
Repo: bringauto/packager-fleet-protocol-context PR: 8
File: docker/ubuntu2204/Dockerfile:30-30
Timestamp: 2025-08-27T12:47:58.557Z
Learning: The packager-fleet-protocol-context repository contains Dockerfiles that are processed by the external Packager build system from the BacPack system. The Packager system provides build stages like `packager-context` that these Dockerfiles reference via `COPY --from=packager-context`, making these references valid and required even though the stages aren't defined within the individual Dockerfiles themselves.
Applied to files:
example_context/config/CMCONF_FLEET_PROTOCOLConfig.cmaketests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_debug.jsonexample_context/config/README.mdexample_context/docker/ubuntu2404/Dockerfileexample_context/package/fleet-protocol-cpp/fleet_protocol_cpp_release.jsontests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_release.jsonexample_context/docker/fedora40/Dockerfileexample_context/package/fleet-protocol-cpp/fleet_protocol_cpp_debug.jsonexample_context/docker/fedora41/Dockerfiletests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_release.jsonexample_context/docker/debian12/Dockerfileexample_context/package/fleet-protocol-interface/fleet_protocol_debug.jsonexample_context/docker/fleet-os-2/Dockerfiletests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_debug.json
📚 Learning: 2024-10-03T17:41:56.410Z
Learnt from: Mayt34
Repo: bringauto/transparent-module PR: 1
File: CMakeLists.txt:15-20
Timestamp: 2024-10-03T17:41:56.410Z
Learning: In the `transparent_module` project, all modules should be built by default; `FLEET_PROTOCOL_BUILD_MODULE_GATEWAY` and `FLEET_PROTOCOL_BUILD_EXTERNAL_SERVER` should be set to ON by default.
Applied to files:
example_context/config/CMCONF_FLEET_PROTOCOLConfig.cmakeexample_context/config/README.mdtests/test_data/example/app/io-module/io-module_release.jsontests/test_data/example/app/io-module/io-module_debug.json
📚 Learning: 2025-08-05T09:08:02.107Z
Learnt from: mikusaq
Repo: bringauto/module-gateway PR: 46
File: resources/systemd/module-gateway.service.in:0-0
Timestamp: 2025-08-05T09:08:02.107Z
Learning: In the module-gateway project's systemd service file, the config path intentionally uses /CMAKE_INSTALL_SYSCONFDIR@ with a leading slash to create absolute paths pointing to system-wide config locations (e.g., /etc/) rather than installation prefix locations, even though this deviates from standard CMake practices.
Applied to files:
example_context/config/CMCONF_FLEET_PROTOCOLConfig.cmake
📚 Learning: 2025-05-12T07:30:23.835Z
Learnt from: jiristrouhal
Repo: bringauto/fleet-protocol-http-api PR: 29
File: server/fleetv2_http_api/models/payload.py:0-0
Timestamp: 2025-05-12T07:30:23.835Z
Learning: Files autogenerated by OpenAPI Generator in the fleet-protocol-http-api project (indicated by comments like "This class is auto generated by OpenAPI Generator") should not be manually modified, even if they contain linting issues or duplicate imports. Any changes should be made at the specification level and regenerated.
Applied to files:
tests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_debug.jsonexample_context/package/fleet-protocol-cpp/fleet_protocol_cpp_release.jsontests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_release.jsontests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_release.jsonexample_context/package/fleet-protocol-interface/fleet_protocol_debug.jsontests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_debug.json
📚 Learning: 2024-10-09T05:03:50.249Z
Learnt from: mikusaq
Repo: bringauto/packager PR: 24
File: example/package/fleet-protocol-internal-client/internal_client_debug.json:23-23
Timestamp: 2024-10-09T05:03:50.249Z
Learning: The repository URL for 'fleet-protocol-internal-client' is 'https://github.com/bringauto/internal-client-cpp.git', not 'https://github.com/bringauto/fleet-protocol-internal-client.git'.
Applied to files:
tests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_debug.jsontests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_release.jsontests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_release.jsontests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_debug.json
📚 Learning: 2025-08-27T12:47:58.557Z
Learnt from: mikusaq
Repo: bringauto/packager-fleet-protocol-context PR: 8
File: docker/ubuntu2204/Dockerfile:30-30
Timestamp: 2025-08-27T12:47:58.557Z
Learning: In the packager-fleet-protocol-context repository, Dockerfiles use `COPY --from=packager-context` which is provided by the external Packager build system, not defined within the individual Dockerfiles themselves.
Applied to files:
tests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_debug.jsonexample_context/config/README.mdexample_context/docker/ubuntu2404/Dockerfileexample_context/package/fleet-protocol-cpp/fleet_protocol_cpp_release.jsontests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_release.jsonexample_context/docker/fedora40/Dockerfileexample_context/docker/fedora41/Dockerfiletests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_release.jsonexample_context/docker/debian12/Dockerfileexample_context/docker/fleet-os-2/Dockerfiletests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_debug.json
📚 Learning: 2024-10-18T10:19:50.140Z
Learnt from: MarioIvancik
Repo: bringauto/module-gateway PR: 36
File: Dockerfile:65-65
Timestamp: 2024-10-18T10:19:50.140Z
Learning: In the `Dockerfile` of this project, using the `latest` tag for the base image `bringauto/cpp-build-environment` is required due to the CI configuration.
Applied to files:
example_context/docker/ubuntu2404/Dockerfileexample_context/docker/debian12/Dockerfileexample_context/docker/fleet-os-2/Dockerfile
📚 Learning: 2024-10-24T12:17:01.106Z
Learnt from: MarioIvancik
Repo: bringauto/fleet-protocol-http-api PR: 18
File: Dockerfile:16-17
Timestamp: 2024-10-24T12:17:01.106Z
Learning: In the `fleet-protocol-http-api` project, modifying the `ENTRYPOINT` and `CMD` in the `Dockerfile` as previously suggested leads to issues when running the image in Docker Compose.
Applied to files:
example_context/docker/ubuntu2404/Dockerfileexample_context/package/fleet-protocol-cpp/fleet_protocol_cpp_release.jsonexample_context/docker/fedora40/Dockerfileexample_context/package/fleet-protocol-cpp/fleet_protocol_cpp_debug.jsonexample_context/docker/fedora41/Dockerfileexample_context/package/fleet-protocol-interface/fleet_protocol_release.jsonexample_context/docker/debian12/Dockerfileexample_context/package/fleet-protocol-interface/fleet_protocol_debug.jsonexample_context/docker/fleet-os-2/Dockerfile
📚 Learning: 2024-10-18T10:21:55.153Z
Learnt from: MarioIvancik
Repo: bringauto/module-gateway PR: 36
File: Dockerfile:70-70
Timestamp: 2024-10-18T10:21:55.153Z
Learning: In the `Dockerfile`, using `ADD` to clone repositories is preferred over `git clone` because it allows checking for remote changes on GitHub when rebuilding the image frequently during development.
Applied to files:
example_context/docker/ubuntu2404/Dockerfile
📚 Learning: 2025-01-21T11:34:52.410Z
Learnt from: koudis
Repo: bringauto/packager PR: 28
File: example/docker/fedora41/Dockerfile:20-21
Timestamp: 2025-01-21T11:34:52.410Z
Learning: Version pinning for the cmakelib repository in Dockerfiles is not required as per team preference.
Applied to files:
example_context/docker/ubuntu2404/Dockerfile
📚 Learning: 2025-01-21T11:35:12.990Z
Learnt from: koudis
Repo: bringauto/packager PR: 28
File: example/docker/fedora41/Dockerfile:23-26
Timestamp: 2025-01-21T11:35:12.990Z
Learning: SSH security configurations (root login, password authentication) in Dockerfiles used for local development and building packages can be permissive as they are not exposed to external networks.
Applied to files:
example_context/docker/ubuntu2404/Dockerfileexample_context/docker/fedora40/Dockerfileexample_context/docker/fedora41/Dockerfileexample_context/docker/debian12/Dockerfile
📚 Learning: 2025-08-29T09:50:44.695Z
Learnt from: mikusaq
Repo: bacpack-system/packager PR: 43
File: tests/test_data/test_packages/test_package_1_18/zlib_release.json:3-6
Timestamp: 2025-08-29T09:50:44.695Z
Learning: For the bacpack-system/packager repository, Git revision tags (like "v1.2.11") are acceptable in test data JSON files and do not need to be replaced with commit SHAs.
Applied to files:
tests/test_data/test_packages/zlib/zlib_debug.jsontests/test_data/test_packages/nlohmann-json/nlohmann_json_release.jsontests/test_data/test_packages/zlib/zlib_release.jsontests/test_data/test_packages/nlohmann-json/nlohmann_json_debug.json
📚 Learning: 2025-08-29T09:50:32.441Z
Learnt from: mikusaq
Repo: bacpack-system/packager PR: 43
File: tests/test_data/test_packages/test_package_1_06/zlib_release.json:3-6
Timestamp: 2025-08-29T09:50:32.441Z
Learning: For the bacpack-system/packager project, using mutable Git tags (like "v1.2.11") instead of commit SHAs in test data JSON files is acceptable and preferred by the team.
Applied to files:
tests/test_data/test_packages/nlohmann-json/nlohmann_json_release.jsontests/test_data/test_packages/nlohmann-json/nlohmann_json_debug.json
📚 Learning: 2025-08-29T09:51:15.354Z
Learnt from: mikusaq
Repo: bacpack-system/packager PR: 43
File: tests/test_data/test_packages/test_package_1_25/zlib_debug.json:4-6
Timestamp: 2025-08-29T09:51:15.354Z
Learning: In the bacpack-system/packager repository, test files with invalid Git revisions like "not_real_version_tag" in tests/test_data/test_packages/test_package_1_25/ are intentional negative test cases designed to test error handling, not actual issues that need fixing.
Applied to files:
tests/test_data/test_packages/nlohmann-json/nlohmann_json_release.jsontests/test_data/test_packages/nlohmann-json/nlohmann_json_debug.json
📚 Learning: 2025-08-27T13:07:47.911Z
Learnt from: mikusaq
Repo: bacpack-system/packager PR: 35
File: bap-builder/PackageMode.go:164-198
Timestamp: 2025-08-27T13:07:47.911Z
Learning: In bap-builder/PackageMode.go, `buildAllPackages` and `buildSinglePackage` have intentionally different behaviors for image support validation: `buildAllPackages` should skip packages that don't support the requested Docker image (permissive), while `buildSinglePackage` should return an error if the specific package doesn't support the image (strict).
Applied to files:
tests/integration_tests/test_build_apps.py
🧬 Code graph analysis (1)
tests/integration_tests/test_build_apps.py (4)
tests/test_utils/test_utils.py (3)
prepare_packages(79-86)does_app_support_image(147-162)run_packager(193-298)tests/conftest.py (4)
test_image(45-52)packager_binary(71-80)context(56-57)test_repo(61-62)tests/test_utils/common.py (2)
PackagerExpectedResult(20-29)PackagerReturnCode(4-17)internal/packager_error/PackagerError.go (2)
BUILD_ERROR(12-12)DEFAULT_ERROR(8-8)
🔇 Additional comments (22)
tests/test_data/example/app/io-module/io-module_debug.json (1)
11-12: Verify FLEET_PROTOCOL_BUILD_EXTERNAL_SERVER setting and Docker image ordering.Line 12 sets
FLEET_PROTOCOL_BUILD_EXTERNAL_SERVERto "OFF", but a learning from the transparent_module project indicates these flags should be "ON" by default. Confirm this is intentional for io-module testing.Additionally,
fleet-os-2appears at the beginning ofImageNames(line 28), but in other files likefleet_protocol_cpp_release.jsonandfleet_protocol_release.json, it's positioned at the end. Standardize the Docker image ordering across all test data files for consistency.Also applies to: 28-28
example_context/package/fleet-protocol-cpp/fleet_protocol_cpp_release.json (1)
36-37: LGTM!The Docker matrix addition is well-formed and aligns with the PR objectives to support fleet-os-2 builds.
example_context/package/fleet-protocol-interface/fleet_protocol_release.json (1)
35-36: LGTM!Docker matrix update is consistent with similar fleet-protocol manifest changes.
example_context/package/fleet-protocol-interface/fleet_protocol_debug.json (1)
35-36: LGTM!Debug manifest properly mirrors the release variant with fleet-os-2 addition.
tests/test_data/example/app/io-module/io-module_release.json (1)
11-12: Consistency check: FLEET_PROTOCOL_BUILD_EXTERNAL_SERVER and Docker image ordering.The release manifest properly mirrors its debug counterpart (lines 11-12 and 28). However, this file maintains the same Docker image ordering pattern as its debug variant, with
fleet-os-2at the beginning rather than the end. As noted in the debug review, standardize Docker image ordering across all test data for consistency. Additionally, confirm thatFLEET_PROTOCOL_BUILD_EXTERNAL_SERVER = "OFF"is correct for io-module (vs the "ON" default suggested in transparent_module learnings).Also applies to: 28-28
tests/test_data/test_packages/zlib/zlib_release.json (1)
1-34: Docker image ordering is inconsistent across test packages; verify whether standardization is required across all test data files.The review comment correctly identifies a real inconsistency:
fleet-os-2appears first in zlib variants (zlib_debug.jsonandzlib_release.json) but last in fleet-protocol variants (fleet_protocol_debug.jsonandfleet_protocol_release.json). This pattern is systemic across the test data, not isolated to this file.The
ubuntu1804-aarch64inclusion is confirmed as intentional—it appears consistently across 16 test package files (both zlib and fleet-protocol variants). This aligns with the learnings that the aarch64 Docker image's x86-64 tooling is by design.Before applying refactoring, determine whether Docker image ordering should be standardized across all test data files or if different orderings for different package types are acceptable by design.
tests/test_data/test_packages/nlohmann-json/nlohmann_json_debug.json (1)
1-35: Verify Docker image ordering and architecture coverage intentionality.The review observations are factually accurate:
Docker image ordering inconsistency confirmed: Fleet-protocol manifests place
fleet-os-2at the end ofImageNames, while nlohmann-json (and zlib) place it at the beginning. This represents a real inconsistency in ordering conventions across manifests.Architecture coverage difference confirmed: The zlib manifests include
ubuntu1804-aarch64inImageNames, while nlohmann-json does not. Fleet-protocol-interface also includes it, but fleet-protocol-cpp does not.Determine whether these differences are:
- Intentional (e.g., nlohmann-json being header-only requires no multi-architecture builds vs. binary libraries like zlib)
- Oversights that should be standardized across all manifests
tests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_release.json (1)
1-39: LGTM!New test data manifest for fleet-protocol-interface release build. JSON structure is valid, Git revision tag format is acceptable per project conventions, and release/debug configurations are properly separated (IsDebug: false, CMAKE_BUILD_TYPE: Release).
tests/test_data/test_packages/nlohmann-json/nlohmann_json_release.json (1)
1-35: LGTM!New test data manifest for nlohmann-json library. Proper JSON structure, appropriate CMake defines (JSON_BuildTests disabled), and consistent DockerMatrix configuration with fleet-os-2 image.
tests/test_data/test_packages/fleet-protocol-interface/fleet_protocol_debug.json (1)
1-39: LGTM!Debug variant of fleet-protocol-interface manifest. Correctly paired CMAKE_BUILD_TYPE: Debug with IsDebug: true. Consistent with release variant in structure and DockerMatrix configuration.
example_context/docker/debian12/Dockerfile (1)
37-40: Verify the build stage name for this repository.The
COPY --from=package-contextreferences a build stage that should be provided by the external Packager build system. Per learnings, similar patterns use this stage name in this repository, but verify thatpackage-contextis the correct stage name and notpackager-context(which is used in the packager-fleet-protocol-context repository).example_context/docker/fedora41/Dockerfile (1)
23-26: Consistent CMCONF integration with other images.Follows the same CMCONF installation pattern as debian12, ubuntu2404, and fedora40 Dockerfiles. Assuming
package-contextbuild stage is verified as correct for this repository.example_context/package/fleet-protocol-cpp/fleet_protocol_cpp_debug.json (1)
36-37: LGTM!Correctly adds "fleet-os-2" to the DockerMatrix.ImageNames with proper JSON syntax (comma placement on line 36). Consistent with other package manifests in the PR.
example_context/docker/ubuntu2404/Dockerfile (1)
23-26: LGTM!Follows consistent CMCONF integration pattern across all updated Dockerfiles. Proper placement and configuration.
example_context/docker/fedora40/Dockerfile (1)
23-26: LGTM!Consistent CMCONF integration following the same pattern as debian12, fedora41, and ubuntu2404. All Docker images now have unified CMCONF setup.
tests/test_utils/test_utils.py (1)
206-206: LGTM! Clean implementation of the use_local_repo flag.The new parameter follows the established pattern for boolean flags in this function, with appropriate default value and conditional CLI argument handling.
Also applies to: 271-273
example_context/docker/fleet-os-2/Dockerfile (1)
45-48: LGTM! CMCONF integration follows the established pattern.The integration correctly:
- Copies the CMCONF config from the external package-context stage (as per learnings)
- Sets CMLIB_DIR as an environment variable for the cmake invocation
- Installs CMCONF as a symlink
Based on learnings
example_context/config/README.md (1)
1-17: LGTM! Clear and helpful documentation.The README effectively explains the CMCONF system's purpose, key variables, and provides relevant links to the Package Tracker project.
example_context/config/CMCONF_FLEET_PROTOCOLConfig.cmake (1)
1-44: LGTM! Well-structured CMCONF configuration.The configuration properly initializes the CMCONF system with sensible defaults and includes helpful examples for different repository hosting platforms.
Based on learnings
tests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_release.json (1)
1-40: LGTM! Clean release manifest with fleet-os-2 support.The configuration properly defines a release build with the new fleet-os-2 image added to the Docker matrix, consistent with the PR objectives.
Based on learnings
tests/test_data/test_packages/fleet-protocol-cpp/fleet_protocol_cpp_debug.json (1)
1-40: LGTM! Proper debug manifest with fleet-os-2 support.The debug configuration correctly mirrors the release version with appropriate Debug-specific settings (CMAKE_BUILD_TYPE and IsDebug flag).
Based on learnings
tests/integration_tests/test_build_apps.py (1)
174-185: Manual verification required for dependency completeness.The io-module manifest files (
io-module_debug.jsonandio-module_release.json) do not contain a "DependsOn" field or any structured dependency declarations. The test assumes["nlohmann-json", "zlib", "fleet-protocol-interface", "fleet-protocol-cpp"]are required dependencies, but this cannot be verified against the manifest. Confirm these dependencies are correct by checking the io-module source (CMakeLists.txt or similar) and ensuring the test setup is complete.
|
From my side - tests shall not be bound on the projects which are not part of the Packager. What if the IO module is deleted etc.? |
|
Moved to #49 , closing this PR. |
Summary by CodeRabbit
New Features
Documentation
Tests
Chores