Hi! It sounds wise, I fully support the idea. But who will fix it in a case of issue? Let's imagine, we have a build and it failed this week. We do not know commit leads to the failure and the failure reason. Someone should thoroughly investigate it. We have the similar issue with our internal e2e tests. It's always hard to understand why it failed. Each time we should discuss, find the volunteer who could fix it or persuade someone devote all his work time to the issue.
Anyway, I vote for regular builds ср, 12 нояб. 2025 г., 17:40 Dianjin Wang <[email protected]>: > Hi all, > > I’d like to start a discussion on setting up scheduled CI workflows to > regularly build Apache Cloudberry (both the 2.0.0 branch and the main > branch) and deploy demo clusters on multiple operating systems — for > example, Ubuntu 24.04 LTS, Rocky Linux 8, and Rocky Linux 10. > > Currently, our PRs are tested using a development image based on Rocky > Linux 9, and @Leonid is also working on enabling Ubuntu 22.04 support > in the workflow (see PR #1378, which needs further review and approval > — your feedback is welcome!). > > However, other popular enterprise Linux OS releases are not yet > included in our automated workflows. While these systems share most of > the same build and dependency steps, I’ve encountered multiple package > differences during manual tests on Rocky Linux 10 and Ubuntu 24.04 > that caused build failures. > > In addition to dependency inconsistencies, there are also issues > caused by higher gcc/g++ version standards or differences in Python > environment handling, which can affect compilation behavior. > > If we could schedule weekly builds (e.g., every Monday UTC 00:00) for > both the Cloudberry 2.0.0 and main branches across these OS > environments — including full compilation and demo cluster setup (more > tests are better)— it would greatly help us detect issues earlier, > particularly those related to compiler or dependency version > mismatches. > > Looking forward to your thoughts! > > Best, > Dianjin Wang > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
