mirror of
https://github.com/projectsend/projectsend.git
synced 2026-09-16 16:45:07 +00:00
Ignacio Nelson
ed0d36de25
Updating a server install cost nine artisan invocations plus a PHP-FPM
reload, written out in three places that had already drifted apart. One
of those steps is silently fatal to skip: with opcache.validate_timestamps
off — what production guides recommend and what our own image ships — the
database moves to the new version while every visitor keeps being served
the old code, and artisan reports the new version throughout.
`sudo ./update.sh` is now the whole procedure. It asks whether to check
GitHub, asks whether to download the release and verifies the checksum
published beside it, and asks whether there is a backup — offering to dump
the database when the answer is no. Then it takes the site down, replaces
the files, runs the update, reloads PHP-FPM, restarts the worker and
brings the site back. The application still has no self-updater: nothing
is fetched or applied unless somebody runs this and answers yes.
Underneath it is `php artisan projectsend:update`, which is everything an
update does that needs no root — and now the only definition of it. Both
container entrypoints call it instead of carrying their own copy of the
sequence, so the two paths cannot drift again.
Three findings worth keeping in the record, all from rehearsing rather
than reasoning:
- queue:restart has to come last. It writes its signal into the cache,
so clearing the cache afterwards deletes it and the worker runs old
code forever.
- optimize:clear is not safe to recommend. It runs cache:clear, which
on Redis is FLUSHDB — harmless on the default two-database layout,
but on a single-database Redis it takes the sessions and the queue
with it. The compiled caches are cleared individually instead.
- update.sh overwrites itself mid-run, because the zip contains it and
bash reads its own script lazily by byte offset. It re-execs from a
temporary copy before touching anything.
And when the reload is skipped anyway, the application now says so:
projectsend:update records the version it applied, and any staff page
compares that with what the running process actually compiled. The same
check catches the mirror image — new files in place, update never run.
Rehearsed end to end against real installs: a container upgrade (69 to 73
migrations, key and data intact, healthy), a scripted update on a real
nginx + php-fpm install with OPcache pinned (web process moved 2.1.0 to
2.1.1), the skipped-reload case (banner appears naming both versions, and
clears on reload), the refusals (downgrade, non-release zip, truncated
zip, URL passed to --zip, non-root), a database taken down mid-update
(site comes back out of maintenance mode by itself), and a real download
of the published 2.0.0 zip with its checksum verified.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
79 lines
2.9 KiB
PHP
79 lines
2.9 KiB
PHP
<?php
|
|
|
|
declare(strict_types=1);
|
|
|
|
namespace App\Modules\Platform\Updates;
|
|
|
|
use App\Modules\Platform\Installation\Installation;
|
|
use App\Modules\Platform\Settings\Setting;
|
|
use App\Modules\Platform\Settings\Settings;
|
|
|
|
/**
|
|
* Whether the code this process is executing is the code the installation
|
|
* was last brought in line with.
|
|
*
|
|
* It exists because of a failure with no symptom. On a server with OPcache
|
|
* set the way production guides recommend — `validate_timestamps=0`, which
|
|
* this project's own image ships — replacing the files changes nothing for
|
|
* the running site: PHP never re-reads a file it has already compiled. The
|
|
* database ends up on the new version while every visitor is served the
|
|
* old code, and `php artisan` reports the new version throughout, because
|
|
* a fresh CLI process compiles the new files. Nothing errors. The only
|
|
* outward sign is behaviour that quietly does not match the release notes.
|
|
*
|
|
* `projectsend:update` records the version it applied, and this compares
|
|
* that against what *this* process compiled. The two answers differ in
|
|
* both directions, and both are worth saying:
|
|
*
|
|
* applied > running — files were updated, PHP was never reloaded.
|
|
* applied < running — new files are in place and the update never ran,
|
|
* so the schema is behind the code.
|
|
*
|
|
* Not gated on an edition. `manage_updates` maps to a Community-only
|
|
* capability, but what code a server is executing is not a feature — it is
|
|
* a fact about the machine, which is what view_system_info governs.
|
|
*/
|
|
class RunningCodeState
|
|
{
|
|
public function __construct(
|
|
private readonly Settings $settings,
|
|
private readonly Installation $installation,
|
|
) {}
|
|
|
|
/**
|
|
* @return array{reason: string, applied: string, running: string, applied_at: string, install_kind: string}|null
|
|
*/
|
|
public function current(): ?array
|
|
{
|
|
$applied = $this->settings->get(Setting::AppliedVersion);
|
|
$running = (string) config('projectsend.version');
|
|
|
|
// No update has ever been applied through the command: a fresh
|
|
// install, or one older than the command itself. Nothing to say in
|
|
// either direction.
|
|
if (! is_string($applied) || $applied === '' || $running === '') {
|
|
return null;
|
|
}
|
|
|
|
$reason = match (true) {
|
|
version_compare($applied, $running, '>') => 'stale_code',
|
|
version_compare($applied, $running, '<') => 'pending_update',
|
|
default => null,
|
|
};
|
|
|
|
if ($reason === null) {
|
|
return null;
|
|
}
|
|
|
|
$appliedAt = $this->settings->get(Setting::AppliedVersionAt);
|
|
|
|
return [
|
|
'reason' => $reason,
|
|
'applied' => $applied,
|
|
'running' => $running,
|
|
'applied_at' => is_string($appliedAt) ? $appliedAt : '',
|
|
'install_kind' => $this->installation->kind()->value,
|
|
];
|
|
}
|
|
}
|