안녕하세요,
이메일 관련 이 새로운 기능/기능성을 사용해야 하는 상황입니다:
해당 PR이 아직 병합되지 않았으므로(어느 시점에 병합될 것으로 추정합니다), 프로덕션 Discourse를 실행하면서 검토 중인 PR을 포함하는 권장 방법은 무엇인가요?
정기적인 Discourse 업데이트를 피하거나 업데이트를 하지 않아야 한다고 생각하지만, 아마도 접근 방식을 지나치게 단순화한 것 같습니다.
이러한 상황에서 다른 분들이 어떻게 작업하시는지 안내해 주시면 감사하겠습니다.
첫째: 저는 잘 모르겠습니다.
하지만 이렇게 하면 될 것 같습니다:
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
이렇게 작동한다면, 빌드 중에 이 작업을 수행하도록 app.yml에 내용을 추가할 수 있습니다. 아니면 곧 병합(merge)될 수도 있으니 기다려보는 것도 방법입니다.
만약 상황이 더 나빠진다면, 다음을 실행할 수 있습니다.
./launcher destroy app;./launcher start app
이렇게 하면 마지막으로 빌드한 이미지로 되돌려집니다.
정말 큰 도움이 됩니다. 감사합니다. 이상적으로는 병합이 완료될 때까지 기다리고 싶지만, 이 분야가 처음이라 며칠, 몇 주, 혹은 몇 달이 걸릴지 명확하지 않습니다.
다시 한번 감사합니다.
이 PR에 대한 비판은 아닙니다(상세히 살펴보지 않았기 때문이요), 하지만 일반적으로 이것이 좋은 관행이라고 생각하지 않습니다.
CDCK 개발자 리뷰를 활용하고, 리뷰 및 병합이 완료될 때까지 기다리는 것은 어떨까요?
좋은 조언이네요.
제가 제안한 방법으로 실제로 동작하는지 확인할 수 있거나(아니면 해당 질문에 답하는 사양이 문서에 포함되어 있을 수도), 승인될 때까지 당분간 기존 버전을 계속 사용할 수 있을 겁니다. 많은 분들이 업그레이드를 위해 몇 주(혹은 몇 달)를 기다리기도 하니까요.
@merefield 감사합니다. 말씀하신 대로 병합될 때까지 기다리면 된다는 말씀이신가요?
동의합니다. 아주 좋은 아이디어입니다. 다만 그 동안 이메일 바운스 처리는 해야 합니다.
다시 한번 말씀드리지만, 프로세스가 얼마나 걸리는지 알 수 없기 때문에, 그 정보가 없으므로 상당한 시간이 걸릴 것으로 가정하겠습니다.
아마도 제가 어떤 뉘앙스를 놓치고 있는 것일지도 모릅니다…
몇 주간 시도해 보셔도 안전할 것 같습니다. 새로운 릴리스가 나오면, PR을 다음 릴리스에 맞게 업데이트할지, 아니면 다른 해결책을 찾을지 결정하시면 됩니다. 아마 가장 쉬운 방법은 플러그인으로 구현하는 것일 겁니다.
잠깐. 왜 그냥 플러그인으로 하지 않나요?
보통 그렇게 하는 게 일반적입니다. 플러그인으로 만든 뒤, PR에 관심이 있는지 물어보시는 거죠. 지금은 이 기능을 원하는 분이 당신뿐인 것 같습니다. 코어에 추가하면 누군가가 무기한으로 유지보수를 해야 하므로, 쉽지 않은 일입니다.
음, 왜 이게 플러그인으로 구현되지 않는지 모르겠어요.
그렇게 하면 코어 설치와 독립적으로 플러그인을 별도로 발전시킬 수 있을 텐데요.
PR이 병합되면(만약 병합된다면) 플러그인을 제거하면 됩니다!
비공개 보안 패치에 대해서도 이 문제를 해결해야 합니다.
내부 도구에 리포지토리의 브랜지를 병합하는 코드가 있습니다. 동일한 접근 방식을 권장합니다.
exec 블록(아마도 after_code 훅)에서 다음과 같은 코드가 작동할 것입니다:
# 패치 가져오기 및 병합
git merge REFERENCE --no-commit
bundle install # 필요한 경우
pnpm install --frozen-lockfile # 필요한 경우
@merefield @pfaffman 단순히 플러그인이라고 말하지 않는 이유는, 우리에게는 그 작업이 자명하지 않기 때문입니다. 우리는 아직 플러그인을 작성해 본 적이 없습니다. 이 설정을 어떻게 해야 하는지에 대한 방향을 제시해 주시는 분이 있다면, 기꺼이 살펴보고 싶습니다!
또한, 우리가 netcore를 ‘원하는’ 유일한 사람이라고 말하지는 않을 것입니다. netcore는 지구상에서 가장 큰 ESP 중 하나이며, 코어에서 지원하는 다른 일부 ESP보다 여러 번 더 큽니다. 이것이 더 낫다고 주장하는 것도 아니고, 다른 ESP를 원하는 사용자가 있을 수도 있지만, netcore는 매우 크고 명성이 높은 ESP입니다. 실제로 pepipost 시절부터 이에 대한 논의가 많이 이루어져 왔기 때문에, 여기서도 많은 이야기를 볼 수 있습니다:
개인적으로는 이중 전략이 적절하다고 생각합니다:
플러그인을 만들 수 없다는 것은 PR을 진행할 좋은 이유가 아닙니다.
제3자도 여전히 사용자의 플러그인을 사용할 수 있습니다.
@merefield 죄송하지만 왜 플러그인 빌드가 PR 생성과 관련 있다고 생각하시나요? Netcore 팀이 직접 PR을 작성했습니다.
아마도 말씀하신 내용 중 놓치고 있는 부분이 있는 것 같습니다.
단순히 제안하는 것뿐입니다. 배포 일정에 대한 유연성이 높아집니다. 의존성이 줄어드는 걸 싫어하는 사람이 누가 있겠습니까?
플러그인을 만들 수 있기 때문입니다.
그들이 당신의 PR을 받아들일지 여부는 당신도, 나도 모릅니다.
힌트를 드리자면: 팀(Team)의 누군가가 이 주제에 응답했는데, "네, 최대한 빨리 이걸 반영하겠습니다"라고 말하지 않았습니다. 대신 "코어에 수개월간 반영되지 않을 PR이 있을 때 우리가 취하는 조치"에 대해 설명해 주었습니다.
그것들이 당신의 선택지인 것 같습니다.
저의 답변을 너무 심각하게 받아들이지 마시기를 바랍니다.
저는 인프라 쪽에 속해 있어 개발 팀의 우선순위에는 통찰력이 없습니다. 저에게는 커밋이 
처럼 보이지만, 더 경험 많은 시선에서는 다른 의견일 수 있습니다.
하지만 이 질문에 대한 답변은 셀프 호스터들에게 일반적으로 유용한 조언/FAQ가 될 것이라고 생각합니다.
제 생각에는 여기에서 플러그인을 사용하는 것은 너무 무겁습니다.
역시 제가 아는 게 없었네요.
그리고 지금은 스태프 규모가 얼마나 커졌고, 팀들이 얼마나 세분화되어 있는지 자꾸 잊고 있습니다. 마치 어제는 대부분의 사람들이 거의 모든 것을 알고 있었던 것 같은데(물론 그때도 각자 전문 분야는 있었지만), 그 '어제’가 벌써 8년 전이라는 걸요.