개발 중 이메일 작업하기

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

deliver_later가 ActionMailer에서 호출될 때마다 Sidekiq 작업이 큐에 추가됩니다.

메일러 인수를 추가하거나 제거해야 하는 경우, 이전 및 이후 호환성을 보장하는 것이 중요합니다. 작업의 인수 변경에 대한 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} 자리 표시자를 포함한 이메일 주소.
  # 이 %{key}는 이메일 주소 내에서 전체적으로 포함되어야 하며 다른 값으로 대체되어서는 안됩니다.
  # 예: emailaddress+%{key}@gmail.com.
  # 자리 표시자는 주소의 "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 Gem 업데이트 섹션 MailRoom Gem 업데이트를 읽고 진행하기 전에 올바른 버전의 MailRoom이 설치되어 있는지 확인하세요. 요약하자면, Gemfile의 gitlab-mail_room 버전을 최신 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
  • 기능이 프로젝트와 관련된 경우, 키는 프로젝트 식별자(프로젝트 경로 슬러그 및 프로젝트 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 업데이트

우리는 gitlab-mail_room, MailRoom의 포크를 사용하여 필요한 경우 신속하게 gem을 업데이트할 수 있도록 합니다. 우리는 가능한 한 빨리 변경 사항을 업스트림하고 두 프로젝트를 동기화하려고 노력합니다.

MailRoom을 업데이트하려면:

  1. GitLab Rails의 Gemfile을 업데이트합니다 (예: 예시 머지 요청).

  2. Helm Chart 구성을 업데이트합니다 (예: 예시 머지 요청).

개발 문서로 돌아가기