This was found useful by @Bramas when building a Dockerfile of the web
app itself. See https://github.com/ente-io/ente/pull/1065.
Now, the GIT_SHA environment variable can just be undefined if we're not
in a git repository, and the code using it deals with that case
explicitly.
**Tested by**
Temporarily inverted the isDevBuild flag, then
1. Ran the build normally and verified that the SHA continued to appear
in the logs.
2. Ran the build after copying to a standalone folder without an
associated git repository and verified that the SHA was skipped without
causing the build to fail.
Change the syntax highlighting of the `env` code block from `env` to `sh`
because currently vite press doesn't support the env language and instead
complains
> The language 'env' is not loaded, falling back to 'txt' for syntax highlighting.
This was found useful by @Bramas when building a Dockerfile of the web app
itself. See https://github.com/ente-io/ente/pull/1065.
Now, the GIT_SHA environment variable can just be undefined if we're not in a
git repository, and the code using it deals with that case explicitly.
**Tested by**
Temporarily inverted the isDevBuild flag, tehn
1. Ran the build normally and verified that the SHA continued to appear in the logs.
2. Ran the build after copying to a standalone folder without an associated git
repository and verified that the SHA was skipped without causing the build to
fail.
- Main change here is removing a submodule and moving to the upstream
dependency
- Also updated to Prettier 3
The original issue, about yarn dev not working because of context
isolation, still remains. This PR prepares the ground, will have a go at
it in a subsequent PR.
Sentry has a measurable impact on page load, a metric that I'm keen to
improve. Apparently by default it loses us 8-9 page speed points, though
that can be reduced to 3-4
(https://github.com/getsentry/sentry-javascript/issues/9179).
All of this is doable, but there are bigger tasks to deal with. This is
not to say that Sentry won't be useful again at some point, when we have
time to deal with it better. But right now, we discussed that it's just
better to remove Sentry instead of piling on to the sunk cost.
Sentry has a measurable impact on page load, a metric that I'm keen to
improve. Apparently by default it loses us 8-9 page speed points, though that
can be reduced to 3-4
(https://github.com/getsentry/sentry-javascript/issues/9179).
All of this is doable, but there are bigger tasks to deal with. This is not to
say that Sentry won't be useful again at some point, when we have time to deal
with it better. But right now, we discussed that it's just better to remove
Sentry instead of piling on to the sunk cost.
On our Discord @Degos ran into an issue where their uploads to the self hosted
docker compose cluster were failing. On debugging, it was found that the
line-endings in `server/scripts/compose/minio-provision.sh` were set to CRLF,
causing the script to fail when run inside Docker. The minIO buckets never got
provisioned, and so the uploads would fail with
<Code>NoSuchBucket</Code>
<Message>The specified bucket does not exist</Message>
To fix this, we add a new .gitattributes that enforces the LF for the scripts
that run inside Docker. To (perhaps too preemptively) guard against similar
issues in other scenarios, turn this on for all shell scripts.
Refs:
- https://stackoverflow.com/questions/29603737/bash-seamlessly-run-scripts-with-crlf-line-endings
- https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings
Preview deployments can be made by manually triggering the "Preview
(web)" workflow. You can select the app you want to build
(accounts/auth/cast/photos) and the branch to take the code from. The
deployment will be available at https://preview.ente.sh.