GitHub user DimaOshchepkov created a discussion: Discuss adding a Docker-based workflow for running tests locally
Hi Cloudberry contributors, I am new to this project and recently tried to run Apache Cloudberry locally to better understand it. I was able to start the project using the Docker sandbox and connect to the database successfully. That worked well for trying the database manually. After that, I wanted to go one step further and run the project tests locally. >From what I found, the sandbox containers are mainly useful for running a >local Cloudberry cluster, but they do not seem to include the source/build >tree or the full test environment needed for commands like: ```bash make -C src/test/regress installcheck-small ``` After looking at the GitHub Actions workflow, it seems that CI uses a different approach: a build image, source checkout, configure/build/install steps, creation of a gpAux/gpdemo cluster, and then make installcheck-* targets. I was able to reproduce a similar workflow locally by using the official build image: ```apache/incubator-cloudberry:cbdb-build-rocky9-latest``` and mounting the source tree into the container. After building Cloudberry and creating a demo cluster, I was able to run: ```PGOPTIONS="-c optimizer=off" make -C src/test/regress installcheck-small``` successfully. This could lower the entry barrier for new contributors who want not only to run Cloudberry locally, but also to validate changes before opening a pull request. I would like to discuss whether it would be useful to make this workflow easier for new contributors. Possible options: 1. Add test support to the existing Docker sandbox, if that fits its purpose. 2. Add a separate development/test Docker container or documented workflow, similar to what CI does. 3. Add documentation to src/test/README, devops/sandbox/README.md, or the contributor guide explaining how to run tests locally with Docker. I understand that the sandbox may not be intended as a full development/test environment, so a separate test-oriented container or documented workflow might be a better fit. Would the project be open to adding something like this? If so, what direction would maintainers prefer? GitHub link: https://github.com/apache/cloudberry/discussions/1682 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
