34 lines
1.7 KiB
Ruby
34 lines
1.7 KiB
Ruby
# frozen_string_literal: true
|
|
|
|
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
|