WIP: Handle push options

This MR enables the pre_receive and post_receive hooks to handle the newly-introduced Git push options.

The immediate goal is to enable git push -o skip-ci ... functionality. This implementation however, is not tied to skip-ci and pushes all of the push options to GitLab to handle.

gitlab-shell is in the middle of moving from using Redis to an internal API for handling the post-receive hook (see #77). This implementation only passes the push options using the new internal API.

See gitlab-org/gitlab-ce#18667

One point I'm not sure about: What if gitlab-shell is updated before gitlab-ce, and the fallback_post_receive code is used, which calls update_redis:

    queue = "#{config.redis_namespace}:queue:post_receive"
    msg = JSON.dump({
      'class' => 'PostReceive',
      'args' => [project_identifier, @actor, changes, @push_opts],
      'jid' => @jid,
      'enqueued_at' => Time.now.to_f
    })

What happens when the dequeing code (on the GitLab side) attempts to instantiate a PostReceive with too many parameters (push_opts was added)?

The answer to that question is that the job fails ☹️.

Is there any way around this, other than requiring that gitlab-shell not be used with a version of gitlab-ce before my future MR is merged, adding this parameter to PostReceive?

marked as a Work In Progress

changed the description

added 9 commits

• efb1adaf...2b575a8d - 6 commits from branch gitlab-org:master
• 7f18c131 - Add lib/push_options
• fd25e961 - Pass push options to 'PostReceive' worker
• d3cccc2d - Update specs to include push_opts

Compare with previous version

changed the description

unmarked as a Work In Progress

This MR is ready from my perspective. Note that nothing's happened on the gitlab-ce side of things yet, but with this MR, all of the push options will be available for GitLab to consume in the new /post_receive API.

I've not added a CHANGELOG entry; is that automatic in gitlab-shell?

I'm not sure who's responsible for merging, so I'll cc @brodock @DouweM @stanhu @smcgivern.

marked as a Work In Progress

Sigh... there are two issues:

1. This issue cropped up after rebasing. Right now, even without my changes, on master (2b575a8d) (and gitlab-ce@ab974152dac919d5f9febb6399951bc15a3c1ddd), I'm seeing this error upon push:

$ git push devel HEAD Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 280 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: hooks/pre-receive:17:in rescue in increase_reference_counter': undefined local variable or method repo_path' for main:Object (NameError) remote: from hooks/pre-receive:13:in increase_reference_counter' remote: from hooks/pre-receive:31:in ' To gitlab-devel.example.com:jreinhart/test-project.git ! [remote rejected] HEAD -> junk (pre-receive hook declined) error: failed to push some refs to 'git@gitlab-devel.example.com:jreinhart/test-project.git'

2. I forgot that [*push options* are not enabled in the repository by default, and need to be enabled](https://stackoverflow.com/a/45400809/119527) with

    ```
$ git config receive.advertisePushOptions true

This will presumably need to be added to GitlabProjects.create_hooks().

@JonathonReinhart not the most efficient way but you can always search for the maintainers here: https://about.gitlab.com/team/ (search for Maintainer of GitLab Shell), and yes, you mentioned the right people there :)

I forgot that push options are not enabled in the repository by default, and need to be enabled with

I think there is some config in GitLab itself that you can change to pass this kind of option to the repositories, I've seen something like that the other day (which means there is some point on the codebase that you can change/force this default)

added Community Contribution label

added CI/CD label

This two places (start and end of the highlighting) you can probably use the env variable there to control the options without having to change the repository itself: https://gitlab.com/gitlab-org/gitlab-shell/blob/master/lib/gitlab_shell.rb#L145-177 for the receive.advertisePushOptions true

@brodock I don't think we can use the GIT_CONFIG_PARAMETERS environment variable. That is only useful when we're exec'ing git from Ruby code. In this case, execution begins directly with the Git hooks, so the environment is outside of our control. I believe it must be configured in the repository's local config.

whenever there is a push, we execute git-receive-pack (which is same as git receive-pack) so I think this will work. (https://gitlab.com/gitlab-org/gitlab-shell/blob/master/lib/gitlab_shell.rb#L12)

@JonathonReinhart @brodock This is related to https://gitlab.com/gitlab-org/gitlab-ce/issues/33061, where I suggested in https://gitlab.com/gitlab-org/gitlab-ce/issues/33061#note_37473342 to add receive.advertisePushOptions = true to omnibus-gitlab. I don't actually know if that is more or less appropriate than adding it to the env.

@DouweM I didn't realize we could set receive.advertisePushOptions in the global .gitconfig; it seems so obvious now. I think that's a better solution than any of the others. How does it get set in a source-install? I opened gitlab-ce~14430 for updating the source installation instructions accordingly.

BTW: I found the undefined local variable bug I identified a few days ago (https://gitlab.com/gitlab-org/gitlab-shell/merge_requests/166#note_40634585): See #108 (closed)