Unable to run tests on GitHub CI

[nrgbistro]

I'm trying to run turbo_tests on my Ruby project, which requires a postgresql database running, one for each parallel tester. It seems that running bin/rails parallel:create does not properly set the TEST_ENV_NUMBER environment variable in GitHub CI, as the output from the command is:

Database 'test_database' already exists
Database 'test_database' already exists

When I run locally, I get test_database1 and test_database2. I've made sure to set PARALLEL_TEST_FIRST_IS_1=true, but even without that the second database name should be test_database2. Could someone help me run this test suite on in a GitHub action workflow? I would prefer not to use a matrix.

[TheRoyalTnetennba]

@nrgbistro did you ever figure this out?

[nrgbistro]

No I haven't, I'm currently sticking with rspec for my CI. This would be nice to have but isn't a priority for me now. Let me know if you figure it out.

[javierjulio]

@nrgbistro have you tried using bin/rake parallel:setup instead? From what I recall the "setup" commands handle the case where if they exist they drop and recreate them but "create" won't do that I believe.

[nrgbistro]

I just tried using parallel:setup but get the same issues:

Database 'rails_test' already exists
Database 'rails_test' already exists
psql:/home/runner/.../db/structure.sql:16: ERROR:  duplicate key value violates unique constraint "pg_extension_name_index"
DETAIL:  Key (extname)=(pg_stat_statements) already exists.
rake aborted!

It doesn't seem to ever increment the database number on CI. Any ideas on how to debug that specific behavior?

[nrgbistro]

After significant headache, I've settled on a more manual approach to this:

- name: Set up databases
        run: |
          for i in $(seq 1 2); do
            TEST_ENV_NUMBER=$i DISABLE_SPRING=1 bin/rake db:create db:schema:load
          done

This works as expected when running bundle exec turbo_tests -n 2. I'm not 100% sure if DISABLE_SPRING is necessary but I think it fixed a bug where the environment variable was being cached.

[javierjulio]

@nrgbistro sorry, it's hard to help without more info about your setup. I did want to suggest one thing based on your last comment though to confirm. Did you end up trying PARALLEL_TEST_FIRST_IS_1=true bin/rake parallel:setup instead? That should work both locally and in CI.

For example, in one project, this is what I use to prep and run turbo_tests in CI:

DEVISE_SECRET_KEY=sample PARALLEL_TEST_FIRST_IS_1=true bin/rake parallel:setup
bin/turbo_tests

You did update your config/database.yml file so the test database name includes <%= ENV['TEST_ENV_NUMBER'] %> right? Not sure what else I can suggest without more info.

I'd advise against using spring nowadays. I removed it shortly after adding turbo_tests, for what its worth. Although the primary reason for that was when upgrading Rails due to Zeitwerk.