Part of preparing the app for hosting many customers as one container per customer.
Problem
Runtime files are written into the site root inside the container, with paths hard-coded relative to the working directory (src/backend/appearance.rs):
the uploaded banner image: target/site/data/<file name>
the generated stylesheet: target/site/data/banner-<random>.css
the template target/site/data/banner.css, which comes from the image
When a customer's container is replaced by a new image version, these files are gone, while the database still references them (appearance.banner, appearance.css_name). The public page then links a stylesheet that returns 404. The same thing happens in development after every rebuild.
Suggested fix
Make the data directory configurable (config key or environment variable) instead of the hard-coded target/site/data, and serve it under /data from there.
Mount it as a per-customer volume.
Keep the banner.css template in the image and copy it to the data directory on start if it is missing.
On start, if the stylesheet referenced in the database does not exist, fall back to banner.css instead of linking a missing file.
Related: the upload handler uses the client-supplied file name in the path without sanitising it; worth fixing in the same change.
Done when
Banner and generated CSS survive replacing the container with a new image.
The data directory is documented in README.
Part of preparing the app for hosting many customers as one container per customer.
## Problem
Runtime files are written into the site root inside the container, with paths hard-coded relative to the working directory (`src/backend/appearance.rs`):
- the uploaded banner image: `target/site/data/<file name>`
- the generated stylesheet: `target/site/data/banner-<random>.css`
- the template `target/site/data/banner.css`, which comes from the image
When a customer's container is replaced by a new image version, these files are gone, while the database still references them (`appearance.banner`, `appearance.css_name`). The public page then links a stylesheet that returns 404. The same thing happens in development after every rebuild.
## Suggested fix
- Make the data directory configurable (config key or environment variable) instead of the hard-coded `target/site/data`, and serve it under `/data` from there.
- Mount it as a per-customer volume.
- Keep the `banner.css` template in the image and copy it to the data directory on start if it is missing.
- On start, if the stylesheet referenced in the database does not exist, fall back to `banner.css` instead of linking a missing file.
Related: the upload handler uses the client-supplied file name in the path without sanitising it; worth fixing in the same change.
## Done when
- Banner and generated CSS survive replacing the container with a new image.
- The data directory is documented in README.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of preparing the app for hosting many customers as one container per customer.
Problem
Runtime files are written into the site root inside the container, with paths hard-coded relative to the working directory (
src/backend/appearance.rs):target/site/data/<file name>target/site/data/banner-<random>.csstarget/site/data/banner.css, which comes from the imageWhen a customer's container is replaced by a new image version, these files are gone, while the database still references them (
appearance.banner,appearance.css_name). The public page then links a stylesheet that returns 404. The same thing happens in development after every rebuild.Suggested fix
target/site/data, and serve it under/datafrom there.banner.csstemplate in the image and copy it to the data directory on start if it is missing.banner.cssinstead of linking a missing file.Related: the upload handler uses the client-supplied file name in the path without sanitising it; worth fixing in the same change.
Done when