Fork `mail_room`, release and use our own fork `gitlab-mail_room`
The following discussion from !19186 (merged) should be addressed:
-
@cablett started a discussion: (+16 comments) @tkuah how would I go about testing this, or figuring out where it is deployed so I can close #30070 (closed)?
🤔 Or would I close #30070 (closed) now that this MR is merged?
We need to release the mail_room
functionality but that involves being dependent on the maintainer. We can base our version of mail_room
on a specific SHA in the Gemfile (scratch that, we can't do that, because as @.luke mentions below, the SHA can be changed if there is a rebase on master), but there will likely be further changes depending on requirements.
Let's fork the mail_room
repo, release and update our Gemfile to use our custom release with the merged PR.
See https://about.gitlab.com/handbook/developer-onboarding/#ruby-gems
Steps to follow, based on @smcgivern 's comment
-
Set up https://github.com/cablett/mail_room
as an up-to-date fork of tpitale/mail_room -
Set up a gitlab-mail_room
project ingitlab-org
as a pull mirror of https://github.com/cablett/mail_room. The rest of the steps I'll be doing on GitLab.com. -
Update the README to state the reason for the fork. -
Rename the gem in the gemspec (but not anywhere else) and merge branch to master. -
Bump the version (or downgrade it; it doesn't matter as it's a new gem). -
Build the gem and push to RubyGems.org. -
Add these owners: https://about.gitlab.com/handbook/developer-onboarding/#ruby-gems
Resulting repo: https://gitlab.com/gitlab-org/gitlab-mail-room