Skip to content
This repository has been archived by the owner on Jan 1, 2024. It is now read-only.

vanity.yml on CI #349

Closed
tansaku opened this issue Aug 30, 2018 · 3 comments
Closed

vanity.yml on CI #349

tansaku opened this issue Aug 30, 2018 · 3 comments

Comments

@tansaku
Copy link
Contributor

tansaku commented Aug 30, 2018

Vanity looks great, but I'm having trouble getting it working with our CI (semaphore) - I'm getting the following error on CI:

NameError: FATAL:  Peer authentication failed for user "postgres"

given our vanity.yml of:

development:
  adapter: active_record
  active_record_adapter: postgresql
  database: websiteone_development
  host: <%= ENV['DB_HOST'] || ""%>
  pool: 20
  username: postgres
  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 %>

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

@tansaku
Copy link
Contributor Author

tansaku commented Aug 31, 2018

Semaphore support just suggested the following:

When you select database provider in Project Settings > Build Settings > database.yml for, Semaphore will automatically generate the database.yml file for your builds. Even if you have your own version of a database.yml file, the generated one will be used.
If you look at the contents of this file, you will notice the username and password are set to runner/semaphoredb as explained in the documentation: https://semaphoreci.com/docs/available-environment-variables.html#variables-in-ruby-projects-with-databases. Database username and password should be updated accordingly in the vanity.yml file.

If you wish to use a custom version of a database.yml file and avoid updates to the vanity.yml file, a custom database.yml file should be added as a configuration file in a project. For more details please see the documentation: https://semaphoreci.com/docs/languages/ruby/custom-database-yml.html.

@tansaku
Copy link
Contributor Author

tansaku commented Sep 3, 2018

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 ...

@tansaku
Copy link
Contributor Author

tansaku commented Sep 3, 2018

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant