Closed cmnrd closed 3 months ago
The recent updates enhance Docker support across multiple components of the project. These changes include method additions, path resolution adjustments, and Docker integration in test configurations and TypeScript file generation. Key modifications ensure Docker compatibility, streamline Docker-related command executions, and introduce new Docker handling in TypeScript configuration.
Files | Change Summary |
---|---|
core/src/integrationTest/java/org/lflang/tests/runtime/CppTest.java |
Added supportsDockerOption() method to enable Docker support. |
core/src/main/.../lf/lang/generator/docker/DockerComposeGenerator.java |
Modified createLauncher() for path resolution using Unix string manipulation. |
core/src/main/.../generator/cpp/CppPlatformGenerator.kt |
Introduced toUnixString import and adjusted path conversion with relativeBinDir . |
core/src/main/.../generator/cpp/CppRos2Generator.kt |
Improved file path resolutions, Docker image generation, and colcon command creation. |
core/src/main/.../generator/cpp/CppStandaloneGenerator.kt |
Refined handling of CMake install bindir path, added relativeBinDir , and updated executable generation methods. |
core/src/testFixtures/.../org/lflang/tests/TestBase.java |
Streamlined Docker-related test setup, removed DOCKER_RUN_SCRIPT , simplified execution commands. |
core/src/main/.../generator/ts/TSFileConfig.kt |
Added docker parameter in the constructor, introduced setDocker() method, and updated command execution logic to handle Docker. |
core/src/main/.../generator/ts/TSGenerator.kt |
Set Docker property in fileConfig . |
core/src/main/java/org/lflang/generator/LFGenerator.java |
Added extra argument to TSFileConfig constructor for TypeScript to include Docker parameter. |
sequenceDiagram
participant User
participant CppTest
participant DockerComposeGenerator
participant LFGenerator
participant TSFileConfig
participant TestBase
User->>CppTest: Request for Docker support
CppTest-->>CppTest: Executes supportsDockerOption()
User->>DockerComposeGenerator: Create launcher with Unix paths
DockerComposeGenerator->>DockerComposeGenerator: Use FileUtil.toUnixString() and relativize()
User->>LFGenerator: Generate file config for TypeScript
LFGenerator->>TSFileConfig: Pass Docker parameter to constructor
User->>TSFileConfig: Set Docker property
TSFileConfig->>TSFileConfig: Use setDocker() method
TSFileConfig-->>User: Provide command using Docker
User->>TestBase: Execute Docker-related tests
TestBase-->>TestBase: Simplify Docker command determination, remove DOCKER_RUN_SCRIPT
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Turns out that the TypeScript docker test is failing. I don't understand why, though. It works fine if I compile it with lfc, even if I manually force useHierarchicalBin=true
. @petervdonovan is that something you could help with?
This, however, did not work at all. I don't understand the precise reasons, but for the docker tests it would simply do nothing.
I'm not sure I understand because it seems to me like the tests have been doing something. For example, this comment that you posted earlier @cmnrd shows a runtime error (during dynamic linking) while executing a Docker test with docker compose
, presumably via the Bash script that was in the test framework.
I'm not sure I understand because it seems to me like the tests have been doing something. For example, this comment that you posted earlier @cmnrd shows a runtime error (during dynamic linking) while executing a Docker test with
docker compose
, presumably via the Bash script that was in the test framework.
I don't fully understand either. It appears that our tests were good at picking up errors where our generated binary fails, but not where the container execution itself fails. The error message that you link to did not show up in testing, but only when I executed the program myself. Similarly, I was struggling with an issue where the entry point in the dockerfile was wrong, but it did not show up in the tests (The output from the execute step was simply empty).
With the changes in this PR, test/C/src/docker/FilesPropertyContainerized does not result in a test failure even when it finishes with a nonzero exit code. You can verify this by adding exit(1) to the startup reaction and running the C Docker tests:
That is an excellent catch! I did not notice that docker compose up
would mask those errors. I addressed this in https://github.com/lf-lang/lingua-franca/pull/2330
Pretty sure this has been addressed
Nope...
For some reason, we were not testing the docker generation using the launch scripts that we place in
bin
, but instead the test framework would generate a custom docker compose file and run that. This, however, did not work at all. I don't understand the precise reasons, but for the docker tests it would simply do nothing. Thus, a couple of problems in the docker generation were masked, as we never really executed the containers or tested the generated launch script.This PR simply removes the generation of custom docker compose files in the test framework and executes the tests using the generated launch script. This PR also includes a series of fixes for bugs that were uncovered by this change.
Summary by CodeRabbit
New Features
Refactor
Bug Fixes
These changes collectively improve Docker support, streamline file path handling, and refine script generation logic.