debian-mirror-gitlab/lib/tasks/gitlab/workhorse.rake

33 lines
1.6 KiB
Ruby
Raw Normal View History

2017-08-17 22:00:37 +05:30
namespace :gitlab do
namespace :workhorse do
2020-03-13 15:44:24 +05:30
desc "GitLab | Workhorse | Install or upgrade gitlab-workhorse"
2018-03-17 18:26:18 +05:30
task :install, [:dir, :repo] => :gitlab_environment do |t, args|
2017-08-17 22:00:37 +05:30
warn_user_is_not_gitlab
2018-03-17 18:26:18 +05:30
2017-08-17 22:00:37 +05:30
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
2018-03-17 18:26:18 +05:30
2021-02-22 17:27:13 +05:30
# 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
#
2017-08-17 22:00:37 +05:30
args.with_defaults(repo: 'https://gitlab.com/gitlab-org/gitlab-workhorse.git')
2021-02-22 17:27:13 +05:30
checkout_or_clone_version(version: 'workhorse-move-notice', repo: args.repo, target_dir: args.dir, clone_opts: %w[--depth 1])
2017-08-17 22:00:37 +05:30
2021-02-22 17:27:13 +05:30
Gitlab::SetupHelper::Workhorse.compile_into(args.dir)
2017-08-17 22:00:37 +05:30
end
end
end