개발에서 이메일 사용하기

메일러 Sidekiq 작업과의 호환성 보장

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

새로운 메일러 메소드나 새로운 메일러에도 동일한 규칙이 적용됩니다. 새 메소드를 소개하는 경우, 새로운 워커를 추가하는 단계를 따르세요. 이는 새로운 메일러가 배포 후 문제가 발생할 경우 비활성화될 수 있도록 기능 플래그로 감싸는 것을 포함합니다.

다음 예제에서 NotificationService에서 메일러 정의에서 인수를 추가하거나 제거하는 것은 모든 Rails 및 Sidekiq 노드가 업데이트된 코드를 가지기 전에 배포 중 문제를 일으킬 수 있습니다.

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

전송된 이메일

개발 환경에서 “전송된” 렌더링된 이메일을 보려면 /rails/letter_opener를 방문하세요.

S/MIME 서명 이메일은 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.
      # 플레이스홀더는 주소의 "사용자" 부분(`@` 이전)에 나타나야 합니다. 생략할 수 있지만 Service Desk를 비롯한
      # 일부 기능이 제대로 작동하지 않을 수 있습니다.
      address: "gitlab-incoming+%{key}@gmail.com"
    
      # 이메일 계정 사용자 이름
      # 제3자 공급업체의 경우 보통 전체 이메일 주소입니다.
      # 자체 호스트된 이메일 서버의 경우 보통 이메일 주소의 사용자 부분입니다.
      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은 캐치올 메일함을 지원하기 위해 새 이메일 핸들러 주소 형식을 지원합니다.

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

  • 작업은 항상 -로 구분하여 끝냅니다. 예: -issue 또는 -merge-request
  • 기능이 프로젝트와 관련된 경우, 키는 프로젝트 식별자(project path slug 및 project 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 (대화에 회신)

레거시 형식

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

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

GitLab에서 Service Desk 기능의 핸들러는 path/to/project입니다.

MailRoom Gem 업데이트

우리는 필요할 경우 빠르게 젬을 업데이트할 수 있도록 MailRoom의 포크인 gitlab-mail_room을 사용합니다. 변경 사항은 최대한 빨리 업스트림으로 올리고 두 프로젝트를 동기화하려고 노력합니다.

MailRoom을 업데이트하려면:

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

개발 문서로 돌아가기