개발 중 이메일 작업

메일러 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 서명된 이메일은 현재 letter_opener로 미리보기할 수 없습니다.

메일러 미리보기

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} 플레이스홀더를 포함하는 이메일 주소.
  # 예시: emailaddress+%{key}@gmail.com.
  # %{key} 플레이스홀더는 주소의 "user" 부분에 ( `@` 앞) 전체로 나타나야 합니다.
  # 새로운 문제가 발생할 수 있지만, `Service Desk`를 포함한 일부 기능이 제대로 작동하지 않을 수 있습니다.
  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 버전이 설치되어 있는지 확인하려면, MailRoom Gem 업데이트 섹션을 읽어야 합니다. 요약하면, 일시적으로 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부터 이메일 핸들러 주소의 새로운 형식을 지원합니다. 이는 catch-all 메일함을 지원하기 위한 것입니다.

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

  • 동작은 항상 끝에 -로 구분됩니다. 예를 들어, -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 (새로운 Merge Request 생성)
  • 1234567890abcdef1234567890abcdef-unsubscribe (대화에서 구독 취소)
  • 1234567890abcdef1234567890abcdef (대화에 회신)

레거시 형식

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

  • 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을 업데이트합니다 (예시 Merge Request 참조).
  2. Helm 차트 구성을 업데이트합니다 (예시 Merge Request 참조).

개발 문서로 돌아가기