`bin/rspec`/`bin/karma` can nuke the GDK entirely
@mbergeron and I experienced an horrible experience when trying to run some tests locally: the entire GDK repository has been wiped out!
To reproduce this, you can just run bin/rake karma
(don't do this at home!).
Then you should see something like the following (puts
debugs added by me):
› bin/rake karma
Running via Spring preloader in process 29312
/Users/remy/Code/GitLab/gdk/gitlab/lib/gitlab/database.rb:6: warning: already initialized constant Gitlab::Database::MAX_INT_VALUE
/Users/remy/Code/GitLab/gdk/gitlab/lib/gitlab/database.rb:6: warning: previous definition of MAX_INT_VALUE was here
/Users/remy/.rubies/ruby-2.3.3/bin/ruby -I/Users/remy/.gem/ruby/2.3.3/gems/rspec-core-3.6.0/lib:/Users/remy/.gem/ruby/2.3.3/gems/rspec-support-3.6.0/lib /Users/remy/.gem/ruby/2.3.3/gems/rspec-core-3.6.0/exe/rspec --pattern spec/javascripts/fixtures/\*.rb --format documentation
**************************************************
⛔️ WARNING: Sidekiq testing API enabled, but this is not the test environment. Your jobs will not go to Redis.
**************************************************
==> Setting up Gitlab Shell...
GitLab Shell setup in 0.000125 seconds...
==> Setting up Gitaly...
"ENV['RAILS_ENV']: development"
"socket_path: /Users/remy/Code/GitLab/gdk/gitaly.socket"
"gitaly_dir: /Users/remy/Code/GitLab/gdk"
"File.exist?(gitaly_executable): true"
"File.mtime(gitaly_executable): 2017-09-14 12:26:22 +0200"
"File.mtime(Rails.root.join('GITALY_SERVER_VERSION')): 2017-09-14 12:20:38 +0200"
rake aborted!
Gitlab::TaskFailedError: fatal: Couldn't find remote ref v0.38.0
/Users/remy/Code/GitLab/gdk/gitlab/lib/tasks/gitlab/task_helpers.rb:86:in `run_command!'
/Users/remy/Code/GitLab/gdk/gitlab/lib/tasks/gitlab/task_helpers.rb:165:in `checkout_version'
/Users/remy/Code/GitLab/gdk/gitlab/lib/tasks/gitlab/task_helpers.rb:157:in `checkout_or_clone_version'
/Users/remy/Code/GitLab/gdk/gitlab/lib/tasks/gitlab/gitaly.rake:15:in `block (3 levels) in <top (required)>'
/Users/remy/.gem/ruby/2.3.3/gems/rake-12.0.0/exe/rake:27:in `<top (required)>'
Tasks: TOP => gitlab:gitaly:install
(See full trace by running task with --trace)
Gitaly failed to install, cleaning up /Users/remy/Code/GitLab/gdk!
Finished in 14.66 seconds (files took 13.53 seconds to load)
0 examples, 0 failures
/Users/remy/.rubies/ruby-2.3.3/bin/ruby -I/Users/remy/.gem/ruby/2.3.3/gems/rspec-core-3.6.0/lib:/Users/remy/.gem/ruby/2.3.3/gems/rspec-support-3.6.0/lib /Users/remy/.gem/ruby/2.3.3/gems/rspec-core-3.6.0/exe/rspec --pattern spec/javascripts/fixtures/\*.rb --format documentation failed
You notice that the env is development
, thus the development settings are used, and for Gitaly the socket path is /Users/remy/Code/GitLab/gdk/gitaly.socket
, making gitaly_dir
set to /Users/remy/Code/GitLab/gdk
. Then in TestEnv.setup_gitaly
, Gitaly is detected as non-installed, then it fails to install (i.e. system('rake', "gitlab:gitaly:install[#{gitaly_dir}]")
) into /Users/remy/Code/GitLab/gdk
since there's already something there, so it ends up trying to cleanup the "dirty Gitaly install folder", which happen to be /Users/remy/Code/GitLab/gdk
...
Possible mitigations
- In
spec/spec_helper.rb
, changingENV["RAILS_ENV"] ||= 'test'
toENV["RAILS_ENV"] = 'test'
solves the issue...
- This would force the env to
test
whenspec/spec_helper.rb
is required, which is the only valid value in this case
- Abort when
ENV["RAILS_ENV"]
is nottest
inTestEnv.init
- This would prevent invocation of
TestEnv.init
in the wrong invocation early - This would abort with
TestEnv.init can only be run if
RAILS_ENVis set to 'test' not 'development'!
1. EnsureFile.basename(gitaly_dir)
isgitaly
inTestEnv.setup_gitaly
so that we can never blow up the GDK root dir inadvertently - This would solve the case where you mess up your
config/gitlab.yml
and useunix:/Users/remy/Code/GitLab/gdk/gitaly.socket
in thetest
env - This would abort with
Gitaly install dir should be named 'gitaly', not 'gdk' (full install path given was '/Users/remy/Code/GitLab/gdk')!
I think we should implement the 3 mitigation methods above.