blob: 2d72a01f66f30221439d09d8922317c9430136f4 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
namespace :gitlab do
namespace :workhorse do
desc "GitLab | Workhorse | Install or upgrade gitlab-workhorse"
task :install, [:dir, :repo] => :gitlab_environment do |t, args|
warn_user_is_not_gitlab
unless args.dir.present?
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])
Gitlab::SetupHelper::Workhorse.compile_into(args.dir)
end
end
end
|
