Échec des builds Travis : le fichier posts.cached_version n'existe pas

Dev
1

J’ai trois plugins pour lesquels je réalise des builds Travis appropriés et qui ont tous commencé à échouer hier. Ils échouent tous de la même manière, et je ne vois pas comment ce problème pourrait être causé par les plugins :

020-05-01 00:29:58.212 UTC [334] ERROR:  la colonne posts.cached_version n'existe pas à la position 193
2020-05-01 00:29:58.212 UTC [334] HINT:  Vous vouliez peut-être faire référence à la colonne "posts.baked_version".
2020-05-01 00:29:58.212 UTC [334] STATEMENT:  SELECT "posts"."id", "posts"."user_id", "posts"."topic_id", "posts"."post_number", "posts"."raw", "posts"."cooked", "posts"."created_at", "posts"."updated_at", "posts"."reply_to_post_number", "posts"."cached_version", "posts"."reply_count", "posts"."quote_count", "posts"."deleted_at", "posts"."off_topic_count", "posts"."like_count", "posts"."incoming_link_count", "posts"."bookmark_count", "posts"."score", "posts"."reads", "posts"."post_type", "posts"."vote_count", "posts"."sort_order", "posts"."last_editor_id", "posts"."hidden", "posts"."hidden_reason_id", "posts"."notify_moderators_count", "posts"."spam_count", "posts"."illegal_count", "posts"."inappropriate_count", "posts"."last_version_at", "posts"."user_deleted", "posts"."reply_to_user_id", "posts"."percent_rank", "posts"."notify_user_count", "posts"."like_score", "posts"."deleted_by_id" FROM "posts" WHERE ("posts"."deleted_at" IS NULL) AND 1=0
PG::UndefinedColumn: ERROR:  la colonne posts.cached_version n'existe pas
LINE 1: ...ts"."updated_at", "posts"."reply_to_post_number", "posts"."c...

Je viens de mettre à niveau un site et tout a fonctionné correctement, donc ce n’est pas quelque chose qui affecte les sites fonctionnant normalement.

Je viens de réessayer (cela fait 14 heures !) et il semble que le problème persiste. Y a-t-il quelque chose que je dois mettre à jour ?

2

C’est donc de cela dont tu parles ? Avons-nous supprimé cette colonne ? Je me souviens que @sam a supprimé certaines colonnes récemment.

3

Il y a plusieurs années

L’un de ces plugins est-il non officiel ? Installez-vous une ancienne version de calendrier ?

4

Ce sont tous des plugins non officiels, sinon je ne les testerais pas. :wink:

Désolé si ce n’était pas clair.

Ils passent tous les tests depuis plusieurs semaines maintenant. Il y a eu une période, il y a quelque temps, où ils ont échoué pendant quelques jours avant de recommencer à fonctionner quelques jours plus tard.

À ma connaissance, aucun d’entre eux n’effectue d’opérations liées au calendrier. Celui-ci est assez simple si vous souhaitez jeter un coup d’œil.

5

L’un d’entre eux possède-t-il des migrations ?

6

Non. Je n’ai aucune idée de la façon de leur faire exécuter des migrations. :wink:

7

Donc, c’est mieux. Il y a 14 heures, https://travis-ci.org/ a relancé les tests pour mes plugins personnalisés et tous ont réussi. Je n’ai rien modifié. Cela s’est déjà produit au moins une fois : les builds Travis échouaient, puis quelques jours plus tard, ils repassaient sans que j’aie rien fait.

8

Je rencontre le même problème lors de l’exécution des migrations avec notre plugin discourse-ratings seul, dans un environnement de développement standard. Je ne vois aucun code demandant spécifiquement la colonne cached_version.

Hash du commit : 093ee1d80c269afd00ba1341a3e71eb97e4ce7f1

J’ai exécuté RAILS_ENV=test rake db:drop db:create db:migrate, donc il ne devrait y avoir aucune donnée dans la base de données.

Voici la ligne concernée :

9

Ok, voici ce qui a fonctionné pour nous. Nous avons appelé reset_column_information sur les tables concernées avant la migration. D’une manière ou d’une autre, la colonne cached_version est mise en cache :wink: dans le cache du schéma. De plus, cela semble être un problème particulièrement présent dans l’environnement test.