renaming part of extension build refactor PR #7926
Conversation
|
I think this is a nice improvement over the current break-and-fix approach in synchronising repositories, since it reduces the amount of coordination required, and it's atomic (as explained by Sam, steps 3, 4, and 5 have to be completed in order but states will all be valid on both repos). Note also that multiple parallel API-breaking PRs are also supported, as long as patches can be independently applied. Proposal would be giving a test-run with DuckDB-Wasm, where this tries to address a present pain-point, can then be expanded to out-of-tree extensions in a separate step. This could also allow to eventually migrate (promote?) more extension to out-of-tree, given that this provides an arguably simpler workflow in adapting to eventual changes. |
|
Thanks! |
This PR
this pr contains some makefile renames and file renames that are required for #7735
this is pr-ed separately into master to prevent causing lots of merge conflicts while having master and feature separate.
and a bit of ✂️🦬
This PR also contains some yak shaving in the form of introducing a "poor mans mono-repo" feature. It is achieved through the
.github/patchesmechanism that @carlopi and me thought of yesterday. The idea is that when a change is made to duckdb that breaks compatibility with duckdb-wasm, we can still have duckdb CI pass by adding the required changes to duckdb-wasm as a patch file.This creates a natural flow for making changes to duckdb that looks like this:
.github/patches/duckdb-wasmwith descriptive name..github/workflows/WebAssembly.ymlalong with the removal of the applied patches in.github/patches/duckdb-wasmThe nice thing is that CI will be able to pass during every step of this flow. Also, since wasm has its own versions and duckdb's version pinned applying the patch(es) to wasm does not need to happen for every breaking change, only when bumping the duckdb version in duckdb-wasm (though these patches should probably be rare and not be allowed to accumulate too much anyway).
@Mytherin interested to hear your thoughts! we could also apply a similar approach to out of tree extensions that are built using DuckDB's main CI, thought it is slightly different as deployment is then done through duckdb ci creating a bit more potential to "forget" to apply patches.