Simplify internal post receive messages
Problem to solve
The GitlabPostReceive#exec
class in gitlab-shell prints a number of adhoc messages sent from GitLab Rails internal post_receive
endpoint.
The number of these messages has grown over time.
We can refactor this so that Rails prepares messages with a certain structure, and gitlab-shell just prints out the messages that Rails has supplied, rather than the current way that it's working where each new use-case we have for Rails to send a message to gitlab-shell we add a new line to gitlab-shell in order to output it.
Further details
This idea was discussed in gitlab-shell!288 (merged).
The refactor would reduce gitlab-shell's role in printing post-receive messages to simply the ability to print two kinds of messages: a "basic" message and an "alert" message.
Rails would be responsible for generating the text of all of the messages.
A "basic" message would be output as-is (but with formatting to ensure proper word wrapping - see the "Changes to gitlab-shell" section below):
My basic message
An "alert" message would be output the way that broadcast messages currently are:
========================================================================
My alert message
========================================================================
Changes to GitLab Rails
Rails's internal post_receive
endpoint could send this kind of data in its output
for gitlab-shell:
messages: [
{
type: :basic,
message: 'My message'
},
{
type: :alert,
message: 'My broadcast message'
},
{
type: :alert,
message: 'My warning'
}
]
Rails would be solely responsible for generating the full text of the messages. I.e., currently merge_request_urls
are sent to gitlab-shell and gitlab-shell turns the urls into full messages. This would be changed so that Rails sends the full message ready for gitlab-shell to output it.
Changes to gitlab-shell
All messages would first go through the formatting logic in https://gitlab.com/gitlab-org/gitlab-shell/blob/84d96bed60f6ffd7a1bc81f0c99ad7ff3296ef95/lib/gitlab_post_receive.rb#L68 which wraps lines and makes sure links aren't broken.
Any basic
messages would be printed first, followed by any alert
messages.
Possible need for specifying ordering of messages
If we wanted to ensure that certain messages would display below others regardless of the order that Rails added the messages to its output
we could add an order
property to the message structure:
{
type: :alert,
order: 10
message: 'My broadcast message'
},
{
type: :alert,
order: 0
message: 'My warning'
}
Within each group of basic
and alert
messages, order
would determine relative order to each other.