Cross platform testing CI - local

[ThatDeparted2061]

Description

Cross-Platform Build and Testing

Summary of the Change

This change updates the Docker build process to support cross-platform builds using Docker Buildx. The platforms tested include:

• linux/amd64
• linux/arm64
• linux/riscv64
• linux/ppc64le
• linux/s390x
• linux/386
• linux/mips64le
• linux/mips64
• linux/arm/v7
• linux/arm/v6

Key updates include:

1. Cross-platform support: The docker-compose.sh script was updated to build images for multiple platforms using Docker Buildx.
2. Multi-platform image building: The script now uses the docker buildx build --platform command to build for all specified platforms.
3. Testing images locally: The script has been modified to allow testing on all platforms without pushing the images to a registry.
4. Default platform configuration: If the METACALL_PLATFORM variable is not set, the script defaults to all the platforms mentioned above.

Issue Fixed

The issue fixed by this change is enabling cross-platform Docker builds and testing. This ensures that the Docker images for the application can be built and tested across various architectures (e.g., amd64, arm64, riscv64, etc.), addressing any compatibility issues across platforms.

Dependencies

1. Docker: Docker should be installed and configured on your system.
2. Docker Buildx: This is required for multi-platform builds. Docker Buildx should be enabled and configured on the system (which is handled by the script if it's not already set up).
3. Docker Compose: The script assumes you are using docker-compose.yml for building the images. Ensure Docker Compose is installed.

Additional Information

• The change does not push the images to a registry, so it's suitable for local testing and CI pipelines that require multi-platform testing.
• To push the images to a registry, you would need to modify the script to use the --push flag (which was intentionally avoided as per your request).
• This change improves platform compatibility for users building and testing the application on diverse architectures (e.g., ARM, PPC, etc.).

Additional code testing

I went a step ahead and in order to check the validity of the code pushed the images to a personal image of metacall/core that I have created on Docker hub.

• These include amd64 and arm64
• It stays in this link https://hub.docker.com/repository/docker/thatdeparted2061/harsh-metcall-core/general
  
  
• The output file
  

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Documentation update

Checklist:

• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have added tests/screenshots (if any) that prove my fix is effective or that my feature works.
• I have tested the tests implicated (if any) by my own code and they pass (make test or ctest -VV -R <test-name>).
• If my change is significant or breaking, I have passed all tests with ./docker-compose.sh test &> output and attached the output.
• I have tested my code with OPTION_BUILD_ADDRESS_SANITIZER or ./docker-compose.sh test-address-sanitizer &> output and OPTION_TEST_MEMORYCHECK.
• I have tested my code with OPTION_BUILD_THREAD_SANITIZER or ./docker-compose.sh test-thread-sanitizer &> output.
• I have tested with Helgrind in case my code works with threading.
• I have run make clang-format in order to format my code and my code follows the style guidelines.

[ThatDeparted2061]

From what i understand to complete the tasks failed I'd need to make changes in docker hub platform yml, dockerfile etc, which wud basically mean the issue #485.