+5
−3
+13
−9
CLAUDE.md
0 → 100644
+102
−0
+4
−1
Loading
<h3>The problem</h3> The CMS-specific filter files (rsync-filter-bitrix, rsync-filter-ceteracms, rsync-filter-wordpress) all hardcode /www/ in their rules. rsync-filter-std operates at the project root level and has no /www/ references, so it needs no changes. When DOC_ROOT_NAME=public_html, the deployment renames `www/` to `public_html/` in the checkout, then rsyncs from $CI_PROJECT_DIR/ to the server. But the filter still says exclude `/www/**` — which now matches nothing (the dir is public_html/), so rsync happily deletes everything inside public_html/ on the server that isn't in the repo. <h3>The solution</h3> Runtime sed substitution after filter files are fetched — replace `/www/` with `/$DOC_ROOT_NAME/` in the downloaded filter file. Where exactly: in `.deploy_code_to_server_with_delete`, right after `*set_rsync_filter` (which sets `$PROJECT_FILTER`). At that point both filter files are on disk and DOC_ROOT_NAME is available from the dotenv artifact. ```bash if [[ "$DOC_ROOT_NAME" != "www" ]]; then sed -i "s|/www/|/$DOC_ROOT_NAME/|g" "$PROJECT_FILTER" fi ``` Only `$PROJECT_FILTER` needs it — `rsync-filter-std` has no `/www/` paths. * Why not put it inside the `*set_rsync_filter anchor`? The anchor doesn't know about `rsync-filter-std`, and keeping it clean/single-purpose is better. The substitution is a concern of the deploy job, not of filter selection. * Why not modify the filter files themselves to use a variable? rsync filter files are plain text — they don't support shell variable interpolation. The only way to parametrize them is runtime substitution (sed/envsubst) or generating them on the fly. Building templating system for them looks too complex for such a simple thing. * What about projects supplying their own local rsync-filter? Those also need the substitution, and `*set_rsync_filter` correctly sets `PROJECT_FILTER="rsync-filter"` for them — so the same one sed line covers that case too.