kyuno/watchparty
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

Fix CI: flaky mtime test on master + PR checkout always failing #29

Merged
kyuno merged 2 commits from fix/static-store-test-mtime-precision into master 2026-09-24 19:42:48 +02:00
Conversation 0 Commits 2 Files changed 2 +9 -2
kyuno commented 2026-09-24 19:36:32 +02:00
Owner
Copy link

1. Pipeline de master en échec (run #119)

L'étape « Serveur - lancer la suite de tests » échoue sur ce test :

not ok 2 - a change only rewrites the party that changed
  expected: 1790271067781
  actual: 1790271067780.999
  • Cause : le test, ajouté par #28, comparait mtimeMs à la milliseconde exacte passée à utimesSync. Sous Linux, mtimeMs est un flottant qui peut tomber juste à côté ; sous Windows, la comparaison passait.
  • Correction : le test compare maintenant au mtimeMs que renvoie le système de fichiers juste après utimesSync. Le code applicatif ne change pas.

2. CI des PR en échec systématique (problème plus ancien)

Toutes les PR échouaient dès l'étape « Récupérer les sources », avec fatal: couldn't find remote ref 29. C'était déjà le cas pour #28, #26, etc.

  • Cause : sur un événement pull_request, github.ref_name vaut le numéro de la PR, pas une branche qu'on peut récupérer.
  • Correction : le job test récupère github.head_ref || github.ref_name, c'est-à-dire la branche source sur une PR et la ref habituelle sur un push ou un tag. Le job publish ne tourne pas sur les PR, il n'est donc pas modifié.

Vérification

La CI de cette PR (run #121) est entièrement au vert : clone, typecheck et tests serveur (179/179), typecheck et build client.

🤖 Generated with Claude Code

## 1. Pipeline de `master` en échec (run #119) L'étape « Serveur - lancer la suite de tests » échoue sur ce test : ``` not ok 2 - a change only rewrites the party that changed expected: 1790271067781 actual: 1790271067780.999 ``` - **Cause** : le test, ajouté par #28, comparait `mtimeMs` à la milliseconde exacte passée à `utimesSync`. Sous Linux, `mtimeMs` est un flottant qui peut tomber juste à côté ; sous Windows, la comparaison passait. - **Correction** : le test compare maintenant au `mtimeMs` que renvoie le système de fichiers juste après `utimesSync`. Le code applicatif ne change pas. ## 2. CI des PR en échec systématique (problème plus ancien) Toutes les PR échouaient dès l'étape « Récupérer les sources », avec `fatal: couldn't find remote ref 29`. C'était déjà le cas pour #28, #26, etc. - **Cause** : sur un événement `pull_request`, `github.ref_name` vaut le numéro de la PR, pas une branche qu'on peut récupérer. - **Correction** : le job `test` récupère `github.head_ref || github.ref_name`, c'est-à-dire la branche source sur une PR et la ref habituelle sur un push ou un tag. Le job `publish` ne tourne pas sur les PR, il n'est donc pas modifié. ## Vérification La CI de cette PR (run #121) est entièrement au vert : clone, typecheck et tests serveur (179/179), typecheck et build client. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
kyuno added 1 commit 2026-09-24 19:36:32 +02:00
Fix flaky mtime assertion in the static party store test on Linux
Some checks failed
Publier l'image Docker / test (pull_request) Failing after 3s
Details
Publier l'image Docker / publish (pull_request) Has been skipped
Details
b0d2100210 
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 <noreply@anthropic.com>
kyuno added 1 commit 2026-09-24 19:37:20 +02:00
Fix CI source checkout on pull requests
All checks were successful
Publier l'image Docker / test (pull_request) Successful in 24s
Details
Publier l'image Docker / publish (pull_request) Has been skipped
Details
56f969ba78 
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 <noreply@anthropic.com>
kyuno changed title from Fix flaky mtime assertion breaking CI on master to Fix CI: flaky mtime test on master + PR checkout always failing 2026-09-24 19:37:57 +02:00
kyuno merged commit 363cf44ebe into master 2026-09-24 19:42:48 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: kyuno/watchparty#29
No description provided.
Delete branch "fix/static-store-test-mtime-precision"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?