contrib/ del repositorio de ClickHouse.
Según las opciones de compilación, es posible que algunas de estas bibliotecas no se hayan compilado y que, en consecuencia, su funcionalidad no esté disponible en tiempo de ejecución.
Ejemplo
Cómo agregar y mantener bibliotecas de terceros
contrib/ del repositorio de ClickHouse.
Evite volcar copias de código externo en el directorio de la biblioteca.
En su lugar, cree un submódulo de Git para incorporar código de terceros desde un repositorio upstream externo.
Todos los submódulos utilizados por ClickHouse se enumeran en el archivo .gitmodule.
- Si la biblioteca puede usarse tal cual (el caso predeterminado), puede hacer referencia directamente al repositorio upstream.
- Si la biblioteca necesita parches, cree un fork del repositorio upstream en la organización de ClickHouse en GitHub.
ClickHouse/ a partir de la rama o etiqueta que quiera integrar; por ejemplo, ClickHouse/2024_2 (para la rama 2024_2) o ClickHouse/release/vX.Y.Z (para la etiqueta release/vX.Y.Z).
Evite seguir las ramas de desarrollo upstream master/ main / dev (es decir, las ramas con prefijo ClickHouse/master / ClickHouse/main / ClickHouse/dev en el repositorio con fork).
Estas ramas son objetivos móviles, lo que dificulta un versionado correcto.
Las “ramas con prefijo” garantizan que los pulls desde el repositorio upstream hacia el fork no afecten a las ramas personalizadas ClickHouse/.
Los submódulos en contrib/ solo deben seguir ramas ClickHouse/ de repositorios de terceros con fork.
Los parches solo se aplican sobre ramas ClickHouse/ de bibliotecas externas.
Hay dos formas de hacerlo:
- quiere crear una nueva corrección sobre una rama con prefijo
ClickHouse/en el repositorio con fork, por ejemplo, una corrección del sanitizador. En ese caso, publique la corrección como una rama con prefijoClickHouse/, por ejemploClickHouse/fix-sanitizer-disaster. Luego cree un PR desde la nueva rama hacia la rama de seguimiento personalizada, por ejemploClickHouse/2024_2 <-- ClickHouse/fix-sanitizer-disaster, y fusione el PR. - actualiza el submódulo y necesita volver a aplicar parches anteriores. En este caso, volver a crear PR antiguos es excesivo. En su lugar, simplemente haga cherry-pick de commits anteriores en la nueva rama
ClickHouse/(correspondiente a la nueva versión). No dude en hacer squash de los commits de PR que tenían varios commits. En el mejor de los casos, habremos aportado los parches personalizados upstream y podremos omitirlos en la nueva versión.