Updates
What the account menu tells you about versions, the check that only runs when you press it, and the one shape that can restart itself.
Bottom left of the window is the version: ● 0.0.8 when there is
nothing to do, and ● Update Available when there is. Click it for both
version numbers, what to do about them, and the way to do it.
Three different things put you behind and it says the same two words for all of them, because your next move is the same: a newer release exists, the page has fallen behind the server, or a downloaded build is waiting to be applied.
For the last two the popup has a refresh, and it is worth knowing that this is not the browser's refresh. DataGripe is a progressive web app: a service worker answers from what it has already stored, so reloading the page re-renders the build you are trying to leave. The button asks for the new one, waits for it to install, and hands over — which is also what happens on its own after a restart.
The check asks once, when you open a project. No interval, no background thread, no telemetry — and the server holds the answer for ten minutes, so a team opening the same project is one request between them. Close the tab and nothing asks again.
A failed check says so. Reporting "up to date" when the request timed out is how a person misses a security release, so a check that could not reach the release feed says that instead.
| Default | ||
|---|---|---|
UPDATE_CHECK_DISABLED |
false |
Removes the check and the button both. What an airgapped deployment sets: an offer that cannot work is worse than no offer. |
Applying one
What the menu suggests depends on how this deployment runs, because the answer is completely different per shape and the person reading it is often not the person who deployed it.
| Shape | What the menu says |
|---|---|
| Kubernetes | Upgrade the image or chart, then restart. The app checks migrations before serving requests. |
| Desktop | Nothing to do: the app updates itself and offers the new version. |
CLI (bunx @datagripe/cli) |
Stop it and run it again with @latest. |
| Container | Pull the image and restart the container. |
| A checkout | Pull the repository and restart. |
Every one of them also links to upgrading, which has the commands and, more importantly, the migration story per shape.
| Default | ||
|---|---|---|
DATAGRIPE_SHAPE |
detected | Which of desktop, cli or container this is. The desktop shell, the CLI launcher and the image each set it for you, and Kubernetes is detected from KUBERNETES_SERVICE_HOST and wins over it. Setting it by hand only changes which upgrade advice you are shown. |
Restarting the server
The restart server button ends the app process. Kubernetes restarts
the container inside the same pod and may pull a new image, but it does
not rerun completed init containers or Helm hooks. The app itself checks
schema_migrations and applies pending files at startup in both database
modes. It waits for concurrent runners and refuses to serve if a migration
fails. See Upgrading.
| Default | ||
|---|---|---|
RESTART_TO_UPDATE |
true in Kubernetes | Whether ending the process brings a new one back. Set it for a compose stack or a systemd unit that restarts, and the button appears there too; set it false in a pod where you would rather nobody had it. |
The button is there whether or not the update check found anything: a deployment that builds its own image from a moving tag has updates the feed has never heard of. A moving tag still requires the new image's migrations; the app startup check applies them before serving.
Four things about that button:
- It is offered only where something will start DataGripe again. Off by default everywhere but Kubernetes, because a container started without a restart policy that exits is a DataGripe nobody is running. The action is refused by the server as well as hidden by the app.
- Owners only, behind a confirm. It disconnects everyone in the deployment for a few seconds. Unsaved editor content is in the browser, not in the process, so it survives.
- It goes out the way a
SIGTERMdoes — the embedded PostgreSQL cluster included, which is what stops the next process finding a stale lock file. - It is in the audit log as
app.restart, with who pressed it.
The page then waits for the server to answer again and reloads, because a restart that pulled a new image also replaced the web bundle.
The account menu
The avatar in the top right is the other half: the project you are in and your role, your address, both settings panels and the way out. No versions — those are a property of the deployment, not of you, which is why they are at the other end of the window.
It comes from Gravatar, by hash: your address never leaves the browser, only a SHA-256 of it does, and nothing is requested until you open the menu for the first time. An address with no Gravatar gets no generated image — the request asks for a 404 — so what you see is your initials. That is also what you see offline, on an airgapped deployment, or behind a content-security policy that blocks it.
Set a name in Account settings and the button shows that instead of the initials. It is stored in this browser: it does not rename your account, and other members still see your address.
This page as Markdown, for an agent or a diff.