Échec de l'action GitHub : étape « Check SKIP_DB_AND_REDIS bootability »

Dev
1

J’ai rencontré un problème où l’étape récemment ajoutée « Vérifier la capacité de démarrage SKIP_DB_AND_REDIS » a échoué pour l’un de mes plugins.

Le démarrage avec SKIP_DB_AND_REDIS a échoué. Assurez-vous que la base de données n’est pas consultée pendant le processus de démarrage de Rails.

Pour reproduire localement, exécutez `SKIP_DB_AND_REDIS=1 RAILS_DB=‘nonexistent’ bin/rails runner “puts ‘booted successfully’”`.

J’ai essayé, mais je n’ai pas pu reproduire le problème localement. Cela a simplement réussi.

J’ai pu utiliser la trace de pile de l’étape d’action GitHub ayant échoué pour identifier précisément le code en cause.

Le code fautif

Dans l’un de mes contrôleurs, j’ai déclaré une constante qui récupérait la liste des attributs d’un enregistrement actif :

REWARD_FIELDS = Reward.attribute_names.excluding("id", "created_at", "updated_at")

Ce qu’il ne faut apparemment pas faire.

Mais cela aurait été plus agréable si j’avais pu simuler cette vérification localement, afin de ne pas avoir à procéder par essais et erreurs via les actions GitHub. Il doit donc y avoir autre chose que l’exécution de :

SKIP_DB_AND_REDIS=1 RAILS_DB='nonexistent' bin/rails runner "puts 'booted successfully'"

3

Intéressant, merci pour le signalement !

C’est quelque chose de très spécifique que nous n’avons probablement pas envisagé auparavant.

Pourriez-vous essayer de modifier cette ligne en false sur votre installation locale :

Puis de réessayer la commande de reproduction ?

Si cela reproduit avec succès le problème, nous devrons alors envisager d’ajouter une variable d’environnement pour contrôler ce paramètre schema_cache_dump.

6

Cela n’a eu aucun effet. La suppression du fichier db/schema_cache.yml non plus.

7

Pourriez-vous essayer ces deux options :

Mode développement, en utilisant un environnement différent pour configurer la base de données :

SKIP_DB_AND_REDIS=1 DISCOURSE_DEV_DB=« nonexistent » bin/rails runner « puts « booté avec succès » »

En mode test, avec les plugins chargés :

LOAD_PLUGINS=1 RAILS_ENV=test SKIP_DB_AND_REDIS=1 RAILS_DB=« nonexistent » bin/rails runner « puts « booté avec succès » »
8

Non, toujours réussi.

Juste pour vérifier que le code du plugin est chargé, j’ai utilisé puts DiscourseKofi::Engine.to_s et cela a affiché le nom. Mais lorsque j’ai référencé la classe qui créerait une connexion à la base de données puts DiscourseKofi::Admin::AccountsController.to_s, cela a finalement échoué.

Il semble donc que le code du plugin ne soit pas entièrement chargé localement comme dans l’action GitHub.

La commande complète ayant échoué :

LOAD_PLUGINS=1 SKIP_DB_AND_REDIS=1 DISCOURSE_DEV_DB=nonexistent bin/rails runner "puts DiscourseKofi::Admin::AccountsController.to_s"

Sans LOAD_PLUGINS=1 ou en utilisant RAILS_DB=nonexistent, cela n’a pas entraîné d’échec.

9

Correction : LOAD_PLUGINS n’avait pas d’importance.

Ainsi, cela échouera :

SKIP_DB_AND_REDIS=1 DISCOURSE_DEV_DB=nonexistent bin/rails runner "puts DiscourseKofi::Admin::AccountsController.to_s"
-> échec

Ceci n’a pas échoué :

SKIP_DB_AND_REDIS=1 DISCOURSE_DEV_DB=nonexistent bin/rails runner "puts 'booted successfully'"
-> aucun échec

Aucun échec non plus en référence à une classe qui ne contacterait pas la base de données :

SKIP_DB_AND_REDIS=1 DISCOURSE_DEV_DB=nonexistent bin/rails runner "puts DiscourseKofi::Admin::PaymentsController.to_s"
-> aucun échec
10

Compris. La commande correcte pour reproduire le problème localement est :

CI=true RAILS_ENV=test LOAD_PLUGINS=1 SKIP_DB_AND_REDIS=1 RAILS_DB=nonexistent bin/rails runner "puts 'booted successfully'"

Toutes ces variables d’environnement sont importantes. Je n’ai pas réussi à le faire fonctionner avec RAILS_ENV=development. Sans CI=true et LOAD_PLUGINS=1 en mode test, il semble que toutes les classes de plugins ne soient pas chargées.