diff options
Diffstat (limited to 'lib/tasks/gitlab/workhorse.rake')
| -rw-r--r-- | lib/tasks/gitlab/workhorse.rake | 27 |
1 files changed, 17 insertions, 10 deletions
diff --git a/lib/tasks/gitlab/workhorse.rake b/lib/tasks/gitlab/workhorse.rake index 15084a118b7..2d72a01f66f 100644 --- a/lib/tasks/gitlab/workhorse.rake +++ b/lib/tasks/gitlab/workhorse.rake @@ -8,18 +8,25 @@ namespace :gitlab do abort %(Please specify the directory where you want to install gitlab-workhorse:\n rake "gitlab:workhorse:install[/home/git/gitlab-workhorse]") end + # It used to be the case that the binaries in the target directory match + # the source code. An administrator could run `make` to rebuild the + # binaries for instance. Or they could read the source code, or run `git + # log` to see what changed. Or they could patch workhorse for some + # reason and recompile it. None of those things make sense anymore once + # the transition in https://gitlab.com/groups/gitlab-org/-/epics/4826 is + # done: there would be an outdated copy of the workhorse source code for + # the administrator to poke at. + # + # To prevent this possible confusion and make clear what is going on, we + # have created a special branch `workhorse-move-notice` in the old + # gitlab-workhorse repository which contains no Go files anymore, just a + # README explaining what is going on. See: + # https://gitlab.com/gitlab-org/gitlab-workhorse/tree/workhorse-move-notice + # args.with_defaults(repo: 'https://gitlab.com/gitlab-org/gitlab-workhorse.git') + checkout_or_clone_version(version: 'workhorse-move-notice', repo: args.repo, target_dir: args.dir, clone_opts: %w[--depth 1]) - version = Gitlab::Workhorse.version - - checkout_or_clone_version(version: version, repo: args.repo, target_dir: args.dir, clone_opts: %w[--depth 1]) - - _, status = Gitlab::Popen.popen(%w[which gmake]) - command = status == 0 ? 'gmake' : 'make' - - Dir.chdir(args.dir) do - run_command!([command]) - end + Gitlab::SetupHelper::Workhorse.compile_into(args.dir) end end end |