-
Notifications
You must be signed in to change notification settings - Fork 270
vanity.yml on CI #349
Comments
Semaphore support just suggested the following:
|
We're made some progress (thanks to @mattwr18) by using a custom vanity.yml like so: development:
adapter: active_record
active_record_adapter: postgresql
database: websiteone_development
host: <%= ENV['DB_HOST'] || ""%>
pool: 20
username: <%= ENV["DATABASE_POSTGRESQL_USERNAME"] %>
password: <%= ENV["DATABASE_POSTGRESQL_PASSWORD"] %>
test:
adapter: active_record
active_record_adapter: default
database: websiteone_test
collecting: false
production:
active_record_adapter: postgresql
<% uri = URI.parse(ENV['DATABASE_URL']) rescue uri = nil %>
<% if uri %>
host: <%= uri.host %>
username: <%= uri.username %>
password: <%= uri.password %>
port: <%= uri.port %>
database: <%= uri.path.sub('/', '') %>
<% end %> but now we're running into issues that the tests kick off puma and the after_worker_fork is causing vanity to try and connect to the dev database which isn't migrated: after_worker_fork do |server, worker|
ActiveRecord::Base.establish_connection
Vanity.playground.establish_connection
end so now we're looking for some way to prevent puma doing this during test. RAILS_ENV and RACK_ENV do not seem to be set to test in semaphore, so perhaps something else ... We've managed to get a complete build by migrating the development database, but that seems a bit of a wasteful hit on the CI performance ... |
looks like we're all sorted with: after_worker_fork do |server, worker|
ActiveRecord::Base.establish_connection
Vanity.playground.establish_connection unless ENV['SEMAPHORE'] == 'true'
end |
Vanity looks great, but I'm having trouble getting it working with our CI (semaphore) - I'm getting the following error on CI:
given our vanity.yml of:
I had to add checks to the production settings to make everything work on my development machine. I'm guessing that test is using the development settings?
I wonder why we need the password settings in vanity.yml - couldn't they just be extracted from database.yml?
But anyhow, our tests now can't run on CI (although they run locally) - I assume it's the presence of vanity.yml that's affecting things here, but maybe it's something else - other builds are passing - here's the failing PR:
AgileVentures/WebsiteOne#2572
and an example of a failing build:
https://semaphoreci.com/agileventures/websiteone/branches/2571_less_text_and_more_images_on_homepage/builds/9
The text was updated successfully, but these errors were encountered: