Empfohlene Vorgehensweise für die Produktionsdiskussion mit PR (nicht zusammengeführt)

Unterstützung
1

Hallo,

Wir müssen diese neue Funktion/Funktionalität für E-Mails nutzen:

Da sie noch nicht zusammengeführt wurde (wir gehen davon aus, dass sie eines Tages zusammengeführt wird), wie ist der empfohlene Weg, ein Produktions-Discourse auszuführen und einen PR in Überprüfung einzubeziehen?

Ich gehe davon aus, dass wir die regulären Updates von Discourse vermeiden/nicht durchführen müssen, aber das vereinfacht den Ansatz wahrscheinlich zu sehr.

Jede Anleitung, wie andere in diesem Szenario arbeiten, wäre willkommen.

  • Jake
2

Erstens: Ich weiß es nicht.

Aber ich denke, das könnte funktionieren:

cd /var/discourse
./launcher enter app
cd /var/www/discourse
su - discourse -c 'git fetch origin pull/<pr_number>/head:<local_branch_name>'
su - discourse -c 'git switch <local_branch_name>'
sv restart unicorn

Wenn das funktioniert, könnten Sie Ihrer app.yml etwas hinzufügen, damit sie dies während des Builds tut. Oder vielleicht wird es bald zusammengeführt und Sie können einfach abwarten.

Wenn das die Dinge verschlimmert, können Sie ein

 ./launcher destroy app;./launcher start app

ausführen, und das stellt das zuletzt erstellte Image wieder her.

3 „Gefällt mir“
3

Das ist sehr hilfreich, danke. Idealerweise würden wir gerne warten, bis es zusammengeführt wird, aber da wir neu in diesem Bereich sind, ist nicht klar, ob das ein paar Tage, Wochen oder Monate dauert.

Vielen Dank nochmals.

4

Keine Kritik an diesem PR (ich habe ihn nicht im Detail angesehen), aber im Allgemeinen halte ich das nicht für eine gute Praxis.

  • Sie erhalten keine Updates vom Kern, während Sie auf diesem Branch feststecken, einschließlich aller Sicherheitspatches.
  • Sie können einige Instabilitäten durch Änderungen im Branch erfahren (der bis zur Zusammenführung als Entwicklungscode behandelt werden muss).
  • Was tun Sie, wenn er abgelehnt wird?
  • Die Tests sind noch nicht einmal gelaufen?

Nutzen Sie die Entwicklerprüfung von CDCK und warten Sie, bis sie geprüft und zusammengeführt wurde?

5 „Gefällt mir“
5

Das ist ein guter Rat.

Mit dem, was ich vorgeschlagen habe, könnten Sie sehen, ob es tatsächlich funktioniert (oder ob es Spezifikationen gibt, die diese Frage beantworten) oder ob Sie eine Weile damit auskommen, bis es akzeptiert wird. Viele Leute warten sowieso Wochen (oder Monate) auf ein Upgrade.

2 „Gefällt mir“
7

@merefield danke – ich glaube, Sie sagen, ich soll einfach warten, bis es zusammengeführt wird, ist das richtig?

Wir stimmen zu, das ist eine großartige Idee. In der Zwischenzeit müssen wir jedoch mit E-Mail-Bounces umgehen.

Auch hier wissen wir nicht, wie lange der Prozess dauert. Ohne dieses Wissen gehen wir davon aus, dass er eine beträchtliche Zeit in Anspruch nehmen wird.

Vielleicht entgeht mir hier eine Nuance…

8

Ich denke, Sie können es gefahrlos für einige Wochen ausprobieren. Wenn es eine weitere Veröffentlichung gibt, können Sie entscheiden, ob Sie Ihren PR für die nächste Veröffentlichung aktualisieren oder eine andere Lösung finden möchten. Wahrscheinlich wäre es am einfachsten, es in einem Plugin zu machen?

Warten Sie. Warum nicht einfach in einem Plugin machen?

Das ist der übliche Vorgehensweise. Machen Sie es in einem Plugin und fragen Sie dann, ob sie an einem PR interessiert wären. Im Moment scheint es, als wären Sie der Einzige auf der Welt, der das will. Es in den Kern aufzunehmen bedeutet, dass jemand es auf unbestimmte Zeit pflegen muss; es ist nicht trivial.

3 „Gefällt mir“
9

Ja, ich verstehe nicht, warum das nicht in einem Plugin implementiert ist.

Dann könnte man das Plugin separat zur Kerninstallation weiterentwickeln.

Sobald (falls) der PR zusammengeführt wird, könnte man das Plugin entfernen!

1 „Gefällt mir“
10

Wir müssen dieses Problem auch für nicht-öffentliche Sicherheitspatches lösen.

Wir haben Code in unseren internen Tools, der einen Branch aus einem Repository zusammenführt – ich würde denselben Ansatz für Sie empfehlen.

Etwas wie das hier sollte für Sie in einem exec-Block funktionieren (wahrscheinlich im after_code-Hook):

    # Patch abrufen und zusammenführen
    git merge REFERENCE --no-commit
    bundle install # falls notwendig
    pnpm install --frozen-lockfile # falls notwendig
5 „Gefällt mir“
11

@merefield @pfaffman es ist kein Plugin, einfach weil das für uns nicht trivial ist. Wir haben noch nie ein Plugin geschrieben. Wenn jemand Anweisungen hat, wie man das einbindet, schauen wir es uns gerne an!

Außerdem würde ich wahrscheinlich nicht sagen, dass wir die Einzigen sind, die Netcore „wollen“ – es ist einer der größten ESPs … auf der Erde und um ein Vielfaches größer als einige der anderen, die im Kern unterstützt werden. Ich sage nicht, dass es besser ist oder dass Benutzer die anderen wollen mögen, aber Netcore ist ein sehr großer, angesehener ESP. Tatsächlich können Sie hier eine Menge darüber lesen, da es früher Pepipost war:

https://meta.discourse.org/search?q=pepipost

2 „Gefällt mir“
12

Ich denke, eine zweigleisige Strategie wäre angebracht:

  • Erstellen Sie dies jetzt als Plugin, gehen Sie live
  • Verhandeln/diskutieren Sie PR mit CDCK

Die Unfähigkeit, ein Plugin zu erstellen, ist kein guter Grund für eine PR.

Drittanbieter könnten Ihr Plugin immer noch nutzen.

5 „Gefällt mir“
13

@merefield Entschuldigung, warum glaubst du, dass der Plugin-Build mit der Erstellung des PR zusammenhängt? Netcore selbst hat den PR geschrieben.

Vielleicht übersehe ich ein Detail in dem, was du sagst.

1 „Gefällt mir“
14

Nur ein Vorschlag. Es gibt Ihnen zusätzliche Flexibilität bei den Bereitstellungszeitplänen. Wer mag keine geringeren Abhängigkeiten?

2 „Gefällt mir“
15

Weil du ein Plugin erstellen kannst.

Du weißt nicht, ob sie deinen PR jemals akzeptieren werden. Und ich auch nicht.

Hier ist ein Tipp: Jemand vom Team hat in diesem Thema geantwortet und sagte nicht: „Ja, wir ziehen das sofort ein“. Stattdessen gab er dir: „Hier ist, was wir tun, wenn wir einen PR haben, der nicht in den Kern aufgenommen wird, für Monate“.

Es scheint, dass dies deine Optionen sind.

16

Ich würde nicht so viel in meine Antwort hineininterpretieren.

Ich bin auf der Infrastrukturseite, ich habe keine Einblicke in die Prioritäten der Entwicklungsteams. Für mich sieht der Commit :+1:t3: aus, aber ein geübteres Auge könnte eine andere Meinung haben.

Aber ich denke, die Beantwortung dieser Frage wäre ein allgemein nützlicher Ratschlag / FAQ für Self-Hosters.

Meiner Meinung nach wäre ein Plugin hier zu schwerfällig.

2 „Gefällt mir“
17

Nun, das zeigt, was ich weiß.

Und ich vergesse immer wieder, wie groß die Belegschaft inzwischen ist und wie stark die Teams aufgeteilt sein müssen. Es kommt mir vor, als wäre es erst gestern gewesen, dass die meisten Leute fast alles wussten (natürlich hatten die Leute auch damals ihre Nischen), aber dieses „gestern“ war vor acht Jahren.

5 „Gefällt mir“
19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.