Nous devons utiliser cette nouvelle fonctionnalité/capacité pour les e-mails :
Comme elle n’est pas fusionnée (nous supposons qu’elle le sera un jour), quelle est la méthode recommandée pour exécuter un discourse de production et inclure une PR en cours de révision ?
Je suppose que nous devons éviter/ne pas mettre à jour discourse pour les mises à jour régulières, mais c’est probablement simplifier à l’excès l’approche.
Toute aide sur la façon dont d’autres travaillent dans ce scénario serait appréciée.
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
Si cela fonctionne, vous pourriez ajouter des éléments à votre app.yml pour qu’il le fasse pendant la construction. Ou peut-être qu’il sera fusionné bientôt et que vous pourrez simplement attendre.
Si cela empire les choses, vous pouvez faire un
./launcher destroy app;./launcher start app
et cela remettra l’image que vous avez construite en dernier.
C’est très utile, merci. Idéalement, nous aimerions attendre qu’il soit fusionné, mais étant nouveau dans ce domaine, il n’est pas clair s’il s’agit de quelques jours, semaines ou mois.
Aucune critique de cette PR (je ne l’ai pas examinée en détail), mais en général, je ne pense pas que ce soit une bonne pratique.
vous ne recevrez aucune mise à jour du cœur pendant que vous êtes bloqué sur cette branche, y compris les correctifs de sécurité.
vous pourriez rencontrer une certaine instabilité due aux changements dans la branche (qui doit être traitée comme du code de développement jusqu’à sa fusion)
que faites-vous si elle est rejetée ?
les tests n’ont même pas encore été exécutés ?
Profitez de l’examen des développeurs de CDCK et attendez qu’il soit examiné et fusionné ?
Avec ce que j’ai suggéré, vous pourriez voir si cela fonctionne réellement (ou peut-être qu’il y a des spécifications qui répondent à cette question), ou vous en sortir pendant un certain temps jusqu’à ce qu’il soit accepté. Beaucoup de gens attendent des semaines (ou des mois) pour mettre à niveau de toute façon.
@merefield merci - je crois que vous dites juste d’attendre qu’il soit fusionné, est-ce correct ?
Nous sommes d’accord, c’est une excellente idée. En attendant, cependant, nous devons gérer les rebonds d’e-mails.
Encore une fois, nous ne savons pas combien de temps prend le processus, donc sans cette connaissance, nous supposerons qu’il faudra beaucoup de temps.
Je pense que vous pouvez l’essayer sans risque pendant quelques semaines. S’il y a une autre version, vous pourrez décider si vous mettez à jour votre PR pour qu’il fonctionne avec la prochaine version ou si vous trouvez une autre solution. La chose la plus simple serait probablement de le faire dans un plugin ?
Attendez. Pourquoi pas le faire dans un plugin ?
C’est le cours normal des choses. Faites-le dans un plugin, puis demandez s’ils seraient intéressés par un PR. Pour l’instant, il semble que vous soyez le seul sur la planète à vouloir cela. L’ajouter au cœur signifie que quelqu’un devra le maintenir indéfiniment ; ce n’est pas trivial.
@merefield@pfaffman ce n’est pas un plugin simplement parce que, pour nous, ce n’est pas trivial. Nous n’avons jamais écrit de plugin. Si quelqu’un a des indications sur la façon de connecter cela, nous serions heureux de l’examiner !
De plus, je ne dirais probablement pas que nous sommes la seule personne qui « veut » netcore - c’est l’un des plus grands ESP… sur terre, et plusieurs fois plus grand que certains des autres pris en charge dans le noyau. Je ne suggère pas que c’est mieux, ou que les utilisateurs pourraient vouloir les autres, mais netcore est un ESP très grand et très apprécié. En fait, vous pouvez voir beaucoup de discussions à ce sujet ici, car il s’appelait auparavant pepipost :
Vous ne savez pas s’ils accepteront jamais votre PR. Et moi non plus.
Voici un indice : Quelqu’un de l’équipe a répondu dans ce sujet et n’a pas dit « Oui, nous intégrons cela dès que possible ». Ils vous ont plutôt dit « Voici ce que nous faisons si nous avons une PR qui ne sera pas acceptée dans le cœur pendant des mois ».
Je suis du côté de l’infrastructure, je n’ai aucune idée des priorités des équipes de développement. Pour moi, le commit semble , mais un œil plus expérimenté pourrait avoir une opinion différente.
Mais je pense que répondre à cette question serait un conseil / FAQ généralement utile pour les auto-hébergeurs.
Et j’oublie sans cesse à quel point le personnel est nombreux maintenant et à quel point les équipes doivent être segmentées. On dirait que c’était hier que la plupart des gens connaissaient presque tout (bien sûr, même alors, les gens avaient leurs niches), mais c’était il y a huit ans.
, mais un œil plus expérimenté pourrait avoir une opinion différente.