feat(devops): add Rocky Linux 10 sandbox support / dynamic OS selection - #1913
feat(devops): add Rocky Linux 10 sandbox support / dynamic OS selection#1913Konstantin-Glukhov wants to merge 1 commit into
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hi, @Konstantin-Glukhov welcome!🎊 Thanks for taking the effort to make our project better! 🙌 Keep making such awesome contributions!
|
Hi everyone! I've added Rocky Linux 10 sandbox support for the Ready for review from the @apache/cloudberry-committers team. Thank you! |
|
|
||
| ```shell | ||
| cd cloudberry/devops/sandbox | ||
| ./run.sh -c main -m -o rockylinux9 |
There was a problem hiding this comment.
| ./run.sh -c main -m -o rockylinux9 | |
| ./run.sh -c main -m -o rockylinux10 |
There was a problem hiding this comment.
Sorry it was a typo, I addressed it.
Hi @Konstantin-Glukhov Thanks for your great work! I'll take a look at the PR later. |
|
BTW, @Konstantin-Glukhov Would you like to help with creating a sandbox workflow? We can verify changes automatically. I have done some draft work here: tuhaihe@18d3667 . If you are available, please take over. :) |
7d37bc0 to
0810b0a
Compare
|
Thanks for the work, @Konstantin-Glukhov! Could you please split the |
…tion Introduce support for Rocky Linux 10 sandbox builds while improving the flexibility and safety of the sandbox orchestration script. Changes include: - Add a new `-o` option flag to `run.sh` to allow users to explicitly specify the target OS version. - Implement a validation guard preventing users from building older release versions on Rocky Linux 10 due to modern toolchain incompatibilities. - Move the `CODEBASE_VERSION` validation earlier in the execution path to catch errors before OS mapping occurs. - Add missing `libicu-devel` dependency to the Rocky Linux 9 Dockerfile to fix localized build issues.
0810b0a to
4aa980a
Compare
I did. |
|
Hi, since #1927 was merged, we plan to close this PR. As explained above, it is better to keep the sandbox as simple as possible. |
I don't understand how this PR relates to the other. This is completely a new feature to provide support for Rocky 10. So, you don't want Rocky 10 functionality at all? |
Hi, from my understanding, a sandbox is used by users to try and experience the basic features of Apache Cloudberry. So, no matter what operating system the sandbox is built on, users will have a similar experience. For Rocky Linux 10, the files are nearly the same as those in Rocky Linux 9. I want the sandbox to be kept simple. |
Sandbox is also used to test functionality with a new OS. Adding two new files does not make it any more complicated, it just provides options. |
|
Understood, and that's a fair point — the sandbox does get used to try a new OS, not Let me ask the other way round: do you have a concrete need for a Rocky 10 sandbox on On OS coverage itself, I think we're already served: our CI workflows build and test on So my suggestion: let's park this for now and pick it up the moment there's real pull |
|
Two additional Dockerfile/config files for Rocky 10 don't add real complexity — they're isolated, self-contained additions that don't touch the Rocky 8/9 paths at all. Maintenance burden stays flat. Also worth noting: "sandbox," by etymology, means a play area for experimenting safely. Testing a new OS in it isn't a departure from its purpose — it's exactly what it's for. |
3 participants
What does this PR do?
Introduce support for Rocky Linux 10 sandbox builds while improving the flexibility and safety of the sandbox orchestration script.
Changes include:
-ooption flag torun.shto allow users to explicitly specify the target OS version.CODEBASE_VERSIONvalidation earlier in the execution path to catch errors before OS mapping occurs.libicu-develdependency to the Rocky Linux 9 Dockerfile to fix localized build issues.Type of Change
Test Plan
./run.sh -c main -m -o rockylinux10./run.sh -c main -m./run.sh -c 2.1.0 -mImpact
Dependencies:
Optional rockylinux10
Checklist