Class: Jets::Booter

Inherits:
Object
  • Object
show all
Defined in:
lib/jets/booter.rb

Class Method Summary collapse

Class Method Details

.boot!(options = {}) ⇒ Object 



4
5
6
7
8
9
10
11
12
13
14
15
 
# File 'lib/jets/booter.rb', line 4

def boot!(options={})
  return if @booted

  redirect_output
  confirm_jets_project!
  require_bundle_gems
  Jets::Dotenv.load!
  Jets.application # triggers application.setup! # autoload_paths, routes, etc
  setup_db

  @booted = true
end

.bundler_groups ⇒ Object 



84
85
86
 
# File 'lib/jets/booter.rb', line 84

def bundler_groups
  [:default, Jets.env.to_sym]
end

.confirm_jets_project! ⇒ Object

Cannot call this for the jets new



89
90
91
92
93
94
 
# File 'lib/jets/booter.rb', line 89

def confirm_jets_project!
  unless File.exist?("#{Jets.root}config/application.rb")
    puts "It does not look like you are running this command within a jets project.  Please confirm that you are in a jets project and try again.".colorize(:red)
    exit
  end
end

.message ⇒ Object 



96
97
98
 
# File 'lib/jets/booter.rb', line 96

def message
  "Jets booting up in #{Jets.env.colorize(:green)} mode!"
end

.redirect_output ⇒ Object

AWS Lambda for natively supported languages prints to CloudWatch instead of mungling up the response. We’ll redirect stdout to stderr to mimic AWS Lambda behavior.

Also, for local use, printing to stdout can mangle up the response when piping the value to jq. For example:

`jets call --local .. | jq`

By redirecting stderr we can use jq safely.



28
29
30
31
32
 
# File 'lib/jets/booter.rb', line 28

def redirect_output
  $stdout.sync = true
  $stderr.sync = true
  $stdout = $stderr # jets call and local jets operation
end

.require_bundle_gems ⇒ Object

require_bundle_gems called when environment boots up via Jets.boot. It also useful for when to loading Rake tasks in Jets::Commands::RakeTasks.load!

For example, some gems like webpacker that load rake tasks are specified with a git based source:

gem "webpacker", git: "https://github.com/tongueroo/webpacker.git"

This results in the user having to specific bundle exec in front of jets for those rake tasks to show up in jets help.

Instead, when the user is within the project folder, jets automatically requires bundler for the user. So the rake tasks show up when calling jets help.

When the user calls jets help from outside the project folder, bundler is not used and the load errors get rescued gracefully. This is done in Jets::Commands::RakeTasks.load! In the case when there are in another project with another Gemfile, the load errors will still be rescued.



54
55
56
57
58
59
60
61
 
# File 'lib/jets/booter.rb', line 54

def require_bundle_gems
  # NOTE: Dont think ENV['BUNDLE_GEMFILE'] is quite working right.  We still need
  # to be in the project directory.  Leaving logic in here for when it gets fix.
  if ENV['BUNDLE_GEMFILE'] || File.exist?("Gemfile")
    require "bundler/setup"
    Bundler.require(*bundler_groups)
  end
end

.setup_db ⇒ Object

Only connects connect to database for ActiveRecord and when config/database.yml exists. Dynomite handles connecting to the clients lazily.



66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
 
# File 'lib/jets/booter.rb', line 66

def setup_db
  return unless File.exist?("#{Jets.root}config/database.yml")

  db_configs = Jets.application.config.database
  # DatabaseTasks.database_configuration for db:create db:migrate tasks
  # Documented in DatabaseTasks that this is the right way to set it when
  # using ActiveRecord rake tasks outside of Rails.
  ActiveRecord::Tasks::DatabaseTasks.database_configuration = db_configs

  current_config = db_configs[Jets.env]
  if current_config.empty?
    abort("ERROR: config/database.yml exists but no environment section configured for #{Jets.env}")
  end
  # Using ActiveRecord rake tasks outside of Rails, so we need to set up the
  # db connection ourselves
  ActiveRecord::Base.establish_connection(current_config)
end