From b0d21002101b621e7cefebf36abb0beee7d9cbaf Mon Sep 17 00:00:00 2001 From: Nicolas Date: Thu, 24 Sep 2026 19:36:21 +0200 Subject: [PATCH 1/2] Fix flaky mtime assertion in the static party store test on Linux The "only rewrites the party that changed" test compared a file's mtimeMs against the exact millisecond passed to utimesSync. Linux reports mtimeMs as a float that can land a hair off it (...780.999 for ...781), failing CI on master. Compare against the mtime the filesystem reports right after setting it instead. Co-Authored-By: Claude Opus 5.5 --- server/test/staticPartyService.test.ts | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/server/test/staticPartyService.test.ts b/server/test/staticPartyService.test.ts index 98c1ca8..c2aa116 100644 --- a/server/test/staticPartyService.test.ts +++ b/server/test/staticPartyService.test.ts @@ -195,11 +195,15 @@ describe('StaticPartyStore', () => { const otherFile = path.join(partiesDir(), `${other.id}.json`); const past = new Date(Date.now() - 60000); fs.utimesSync(otherFile, past, past); + // Compared against what the filesystem itself reports back, not + // past.getTime(): Linux returns mtimeMs as a float that can land a + // hair off the exact millisecond set (e.g. ...780.999 for ...781). + const mtimeBefore = fs.statSync(otherFile).mtimeMs; StaticPartyService.markWatched(sp, alice, 'e1'); await StaticPartyStore.writeNow(); - assert.equal(fs.statSync(otherFile).mtimeMs, past.getTime(), 'the untouched party\'s file was not rewritten'); + assert.equal(fs.statSync(otherFile).mtimeMs, mtimeBefore, 'the untouched party\'s file was not rewritten'); }); it('deleting a party removes its file, even with a save still pending', async () => { -- 2.45.2 From 56f969ba78c591298b546f15af3540925640e9d8 Mon Sep 17 00:00:00 2001 From: Nicolas Date: Thu, 24 Sep 2026 19:37:15 +0200 Subject: [PATCH 2/2] Fix CI source checkout on pull requests MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On a pull_request event github.ref_name is the PR number (e.g. "29"), not a fetchable ref, so the test job failed at "Récupérer les sources" on every PR ("couldn't find remote ref 29"). Fetch the PR's head branch (github.head_ref) instead, falling back to ref_name for pushes/tags. Co-Authored-By: Claude Opus 5.5 --- .forgejo/workflows/publish-docker.yml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/.forgejo/workflows/publish-docker.yml b/.forgejo/workflows/publish-docker.yml index 594e5a3..6310cf7 100644 --- a/.forgejo/workflows/publish-docker.yml +++ b/.forgejo/workflows/publish-docker.yml @@ -55,13 +55,16 @@ jobs: # node:20-alpine n'a pas git préinstallé - même approche de clone # manuel que le job publish (pas d'actions/checkout, action JS qui a # ses propres soucis dans les conteneurs Alpine minimalistes ici). + # Sur une PR, `ref_name` vaut le numéro de la PR (ex. `29`), qui n'est + # pas une ref récupérable ("couldn't find remote ref 29") : on récupère + # alors la branche source de la PR (`head_ref`, vide hors PR). - name: Récupérer les sources run: | set -eu apk add --no-cache git git init -q git remote add origin "${{ github.server_url }}/${{ github.repository }}.git" - git fetch -q --depth 1 origin "${{ github.ref_name }}" + git fetch -q --depth 1 origin "${{ github.head_ref || github.ref_name }}" git checkout -q FETCH_HEAD - name: Serveur - installer les dépendances -- 2.45.2