Expose all git push options in Push and Tag Event Webhooks
Problem to solve
We want to allow customers to receive all git push options passed in during a git push via Push and Tag Event Webhooks.
Presently, only git push options that are recognised by
Gitlab::PushOptions will be present in the Push and Tag Event Webhook payloads. This means that customers cannot build systems around their own customised git push options.
For example, the following two push options:
git push -u origin -o 'foo' -o 'bar'
Should become exposed in the Push and Tag Event Webhooks payloads as:
"push_options": ["foo", "bar"]
This feature was previously added in 11.7 as part of https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15643, but was unintentionally removed in 11.10 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26752.
The regression was raised and discussed in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26752#note_164043657.
What caused the regression?
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26752 introduced a class
Gitlab::PushOptions to parse push options passed to the
post_receive API endpoint to make it easier for GitLab to extract their namespaced push option values. At the same time, the
Gitlab::PushOptions class also filters out unrecognised push options. In the
post_receive API endpoint the
PostReceive worker class receives the push options, which eventually are passed to classes that execute the push webhooks. Any unrecognised push options will have been removed.
What should be fixed?
The git push option data exposed in the Push and Tag Event Webhooks needs to be the unparsed data.
The parsed data from
Gitlab::PushOptions is a Hash. The
push_options data in the webhook payloads will need to be reverted back to being an Array of the raw push options, which the
post_receive API endpoint receives as
What does success look like?
All Git push options passed via the command line should be exposed in the Push and Tag Event Webhook payloads (without any filtering or manipulation of the data).
These docs should be updated with the new :
An integration test for this feature should be added to the
post_receive internal API endpoint.