개발 중 이메일 사용

메일러 Sidekiq 작업과 호환성 확인

ActionMailer에서 deliver_later가 호출될 때마다 Sidekiq 작업이 enqueued됩니다. 메일러 인수를 추가하거나 제거해야 하는 경우, 역방향 및 전방향 호환성을 보장하는 것이 중요합니다. 워커의 인수를 변경하는 경우 Sidekiq 단계를 준수하는 것이 중요합니다. 워커의 인수를 변경하는 방법에 대해 참조하세요.

새로운 메일러 메소드나 새로운 메일러의 경우도 마찬가지입니다. 새로 추가하는 경우 새로운 워커 추가 방법을 따르세요. 이는 새로운 메소드를 기능 플래그로 감싸는 것을 포함합니다. 이렇게 하면 새로운 메일러를 배포 후 문제가 발생할 경우 비활성화할 수 있습니다.

다음 예제는 NotificationService에서 인수를 추가하거나 제거하면 모든 Rails 및 Sidekiq 노드에 업데이트된 코드가 적용되기 전에 배포 중 문제가 발생할 수 있습니다. 

mailer.unknown_sign_in_email(user, ip, time).deliver_later

발신 이메일

개발 환경에서 “보낸” 이메일을 확인하려면 /rails/letter_opener을 방문하세요.

S/MIME signed 이메일은 letter_opener로 현재 미리 볼 수 없습니다. (https://github.com/fgrehm/letter_opener_web/issues/96)

메일러 미리보기

Rails는 샘플 데이터를 사용하여 HTML 및 평문으로 메일러 템플릿을 미리볼 수 있도록 제공합니다.

미리보기는 app/mailers/previews에 있으며 /rails/mailers에서 확인할 수 있습니다.

더 많은 정보는 Rails 가이드를 참조하세요.

수신 이메일

  1. GitLab 설치 디렉터리로 이동하세요.

  2. config/gitlab.yml에서 incoming_email 섹션을 찾고 기능을 활성화하고 구체적인 IMAP 서버 및 이메일 계정에 대한 세부 정보를 입력하세요.

    Gmail / Google Apps 구성, gitlab-incoming@gmail.com 메일함을 가정합니다: 

    incoming_email:
  enabled: true

  # 이메일 주소에는 %{key} 플레이스홀더가 포함되어야 합니다. 이 %{key}는 이메일 주소 내에서 완전히 포함되어 있어야 하며 다른 값으로 대체되어서는 안됩니다.
  # 예: emailaddress+%{key}@gmail.com.
  # 플레이스홀더는 주소의 "user" 부분( `@` 앞)에 나타나야 합니다. 생략할 수 있지만 서비스 데스크를 포함해 일부 기능이 제대로 작동하지 않을 수 있습니다.
  address: "gitlab-incoming+%{key}@gmail.com"

  # 이메일 계정 사용자 이름
  # 타사 제공 업체의 경우 통상적으로 전체 이메일 주소입니다.
  # 자체 호스팅된 이메일 서버의 경우 가장 자주 이메일 주소의 사용자 부분입니다.
  user: "gitlab-incoming@gmail.com"
  # 이메일 계정 비밀번호
  password: "[REDACTED]"

  # IMAP 서버 호스트
  host: "imap.gmail.com"
  # IMAP 서버 포트
  port: 993
  # IMAP 서버가 SSL을 사용하는지 여부
  ssl: true
  # IMAP 서버가 StartTLS를 사용하는지 여부
  start_tls: false

  # 수신 메일이 끝나게 될 메일함. 일반적으로 "inbox"입니다.
  mailbox: "inbox"
  # IDLE 명령 시간 초과.
  idle_timeout: 60

  # 전송 후 메일이 삭제로 표시된 경우 메일함에서 메시지를 영구적으로 제거(몰수함)할지 여부
  expunge_deleted: false

    + 뒷부분은 무시되고 이 메시지는 gitlab-incoming@gmail.com 메일함으로 전송됩니다.

  3. 진행하기 전에 더 많은 정보를 위해 MailRoom Gem 업데이트 섹션을 참조하여 올바른 MailRoom 버전이 설치되어 있는지 확인하세요. 요약하면, Gemfile에서 gitlab-mail_room 버전을 임시로 최신 버전으로 업데이트하고 bundle install을 실행해야 합니다. 이 변경사항은 임시적인 해결책이므로 커밋하지 마세요.

  4. GitLab 루트 디렉터리에서 다음 명령을 실행하여 mail_room을 시작하세요. 

    bundle exec mail_room -q -c config/mail_room.yml

  5. 모든 것이 올바르게 구성되었는지 확인하세요. 

    bundle exec rake gitlab:incoming_email:check RAILS_ENV=development

  6. 이제 이메일 답장이 작동하는지 확인하세요.

이메일 네임스페이스

GitLab 11.7부터 새로운 형식의 이메일 핸들러 주소를 지원합니다. 이것은 캐치 올 메일박스를 지원하기 위해 수행되었습니다.

새로운 이메일 핸들러가 필요한 기능을 구현해야 하는 경우, 이메일 키의 형식에 대한 다음 규칙을 따르세요:

  • 액션은 항상 끝에 -로 구분되며, 예를 들어 -issue 또는 -merge-request와 같습니다.
  • 만약 당신의 기능이 프로젝트와 관련이 있다면, 키는 프로젝트 식별자(프로젝트 경로 슬러그 및 프로젝트 ID)로 시작하여 -로 구분됩니다. 예를 들어, gitlab-org-gitlab-foss-20와 같습니다.
  • 프로젝트 식별자와 액션 사이에 추가 정보(예: 작성자 토큰)를 -로 구분하여 추가할 수 있습니다. 예를 들어, gitlab-org-gitlab-foss-20-Author_Token12345678-issue와 같습니다.
  • 이메일 핸들러는 lib/gitlab/email/handler.rb에 등록합니다.

유효한 이메일 키의 예시:

  • gitlab-org-gitlab-foss-20-Author_Token12345678-issue (새 이슈 생성)
  • gitlab-org-gitlab-foss-20-Author_Token12345678-merge-request (새 병합 요청 생성)
  • 1234567890abcdef1234567890abcdef-unsubscribe (대화에서 구독 취소)
  • 1234567890abcdef1234567890abcdef (대화에 회신)

액션 -issue-은 GitLab에서 서비스 데스크 기능의 핸들러로 사용됩니다.

레거시 형식

이전 레거시 형식은 계속 지원하지만, 새로운 기능은 레거시 형식을 사용해서는 안 됩니다. 다음은 이메일 핸들러를 위한 유일한 유효한 레거시 형식입니다:

  • path/to/project+namespace
  • path/to/project+namespace+action
  • namespace
  • namespace+action

GitLab에서 서비스 데스크 기능의 핸들러는 path/to/project입니다.

MailRoom Gem 업데이트

우리는 필요한 경우에 빠르게 젬을 업데이트할 수 있도록 MailRoom의 포크인 gitlab-mail_room을 사용합니다. 가능한 빨리 변경 사항을 상위 프로젝트에 반영하고 두 프로젝트를 동기화하려고 노력합니다.

MailRoom을 업데이트하려면:

  1. GitLab Rails의 Gemfile을 업데이트하세요 (예시 머지 리퀘스트 참조).
  2. Helm 차트 구성을 업데이트하세요 (예시 머지 리퀘스트 참조).

개발 문서로 돌아가기