ich entwickle ein Plugin und versuche, einige Tests zu schreiben. Wenn ich jedoch versuche, die Spezifikationen des Poll-Plugins über
bundle exec rake plugin:spec poll
auszuführen, wie hier gezeigt, erhalte ich folgenden Fehler:
Ein Fehler trat beim Laden von ./plugins/poll/spec/integration/poll_endpoints_spec.rb auf.
Failure/Error: raise ArgumentError.new(“No setting named ‘#{name}’ exists”)
Was mache ich falsch, wenn ich versuche, die Tests des Poll-Plugins auszuführen? Warum wird diese bestimmte Einstellung nicht in die Standardsprache geladen?
Um nur die Poll-Spezifikationen auszuführen, lautet der Befehl: bundle exec rake "plugin:spec[poll]" (oder kürzer: bin/rake "plugin:spec[poll]"). Andernfalls werden alle Pluginspezifikationen ausgeführt.
Was den von dir erhaltenen Fehler betrifft, bin ich mir nicht sicher. Ist die Testdatenbank migriert? (bin/rails db:migrate RAILS_ENV=test)
Danke. Wie du gesagt hast, wurden alle Plugin-Specs ausgeführt, was ich umgangen habe, indem ich die anderen Plugins entfernt habe. Ich habe mich an diesem orientiert, aber es stellte sich heraus, dass die Klammern an der falschen Stelle waren.
Ja, die Datenbank wurde in der Testumgebung migriert. Ich habe diesen Fehler umgangen, indem ich die Zeile raise ArgumentError.new("No setting named '#{name}' exists") auskommentiert und durch einen puts ersetzt habe. Dabei zeigt sich, dass nur discourse_narrative_bot_enabled diesen Fehler auslöst; alle anderen Einstellungen funktionieren einwandfrei. Ich glaube nicht, dass wir etwas mit dieser Einstellung gemacht haben. Da meine Spec jedoch korrekt lief, während ich diesen Fehler ignorierte, kann ich die Workaround-Lösung in meinem lokalen Discourse belassen. Sobald ich herausfinde, was dies tatsächlich verursacht hat, werde ich diesen Beitrag aktualisieren.
Unser CI funktioniert für PRs und Commits, aber bei Cron-Jobs schlägt es hier jedes Mal fehl.
Ich kann dies in der Rails-Konsole mit einem ähnlichen Block reproduzieren:
[19] pry(main)> SiteSetting.defaults.tap do |s|
[19] pry(main)* s.set_regardless_of_locale(:discourse_narrative_bot_enab, false)
[19] pry(main)* end
ArgumentError: No setting named 'discourse_narrative_bot_enab' exists
Dies funktioniert, wenn ich folgendes eingebe:
[21] pry(main)> SiteSetting.defaults.tap do |s|
[21] pry(main)* if s.has_setting? :discourse_narrative_bot_enab
[21] pry(main)* s.set_regardless_of_locale(:discourse_narrative_bot_enab, false)
[21] pry(main)* end
[21] pry(main)* end
Und nur zur Überprüfung, es schlägt fehl mit:
[21] pry(main)> SiteSetting.defaults.tap do |s|
[21] pry(main)* if s.has_setting? :discourse_narrative_bot_enabled
[21] pry(main)* s.set_regardless_of_locale(:discourse_narrative_bot_enab, false)
[21] pry(main)* end
[21] pry(main)* end
Daher schlage ich die folgende Änderung in einem PR vor, den ich gerne einreichen würde:
if ENV['LOAD_PLUGINS'] == '1' && s.has_setting? :discourse_narrative_bot_enabled
Aus irgendeinem Grund kann die Anwesenheit des Narrative Bot-Plugins nicht garantiert werden?
In diesen Beispielen haben Sie die Website-Einstellung als discourse_narrative_bot_enab und nicht als discourse_narrative_bot_enabled. Ich vermute, sobald das korrigiert ist, ist es nicht reproduzierbar?
Das Überraschendste hier ist:
Das deutet auf einen Unterschied in der Laufzeitumgebung für die geplanten Läufe hin
Wenn ich mir einen der fehlgeschlagenen Logs ansehe, scheint es, dass GitHub das multilingual-Plugin direkt in das plugins-Verzeichnis klont, anstatt in sein eigenes Verzeichnis. Es deinstalliert also im Wesentlichen alle Kern-Plugins (und installiert sich selbst nicht richtig).
Wenn ich mir die Dokumentation ansehe, gibt es keinen konsistenten Weg, den Repository-Namen (ohne den Besitzer) zu erhalten, daher benötigen wir einige Tricks. Ich denke, das sollte funktionieren:
cc @cvx - vielleicht sollten wir diese Technik in der CI der Plugin/Theme-Vorlage verwenden?
auf mich, wenn ich jemals in deiner Nähe bin! 
