170530e52e
We had three files that were almost identical, and we can use environment variables to specify the differences. Note we're using the `PGUSER` and `PGPASSWORD` variables, since these variables will automatically be used by the PostgreSQL client when we have a blank `username` and `password` keys in the `database.yml` file (which we did until now). The difference between these variables and the `POSTGRES_USER` and `POSTGRES_PASSWORD` variables is that the `PG` variables are used by the client connecting to the database, while the `POSTGRES_` variables are used by the Docker postgresql image when creating the database superuser. For consistency with the code in our github workflows (and everywhere else in the postgres world), we're respecting this double standard. The fact that there are two different names for what's basically the same thing makes the code confusing, though, particularly when running the docker-compose commands, since we get the password from an environment variable but we have to assign two different environment variables with it. So we're accepting both `PGPASSWORD` and `POSTGRES_PASSWORD` variables in the database configuration file. This way, developers using docker-compose can use `POSTGRES_PASSWORD` for everything and it'll work fine. We're also making `PGPASSWORD` default to `POSTGRES_PASSWORD` so we don't get a warning if we only set `POSTGRES_PASSWORD`: ``` WARN[0000] The "PGPASSWORD" variable is not set. Defaulting to a blank string. ``` Also note we're using `DB_HOST` instead of `PGHOST` because that's the variable Rails currently uses by default for new applications [1]. Finally, note we're using `.presence` in the `ENV` calls in the database.yml file. The `PGPASSWORD` variable was set to an empty string when running docker-compose, so using `ENV["PGPASSWORD"] ||` wouldn't work. [1] https://github.com/rails/rails/blob/c90a8701e5/railties/lib/rails/generators/rails/app/templates/config/databases/postgresql.yml.tt#L22
CONSUL DEMOCRACY
Citizen Participation and Open Government Application
CONSUL DEMOCRACY Project main website
You can access the main website of the project at http://consuldemocracy.org where you can find documentation about the use of the platform, videos, and links to the community space.
Configuration for development and test environments
NOTE: For more detailed instructions, check the local installation docs.
Prerequisites: install git, Ruby 3.2.5, CMake, pkg-config, Node.js 18.20.3, ImageMagick and PostgreSQL (>=9.5).
Note: The bin/setup command below might fail if you've configured a username and password for PostgreSQL. If that's the case, edit the lines containing username: and password: (adding your credentials) in the config/database.yml file and run bin/setup again.
git clone https://github.com/consuldemocracy/consuldemocracy.git
cd consuldemocracy
bin/setup
bin/rake db:dev_seed
Run the app locally:
bin/rails s
You can run the tests with:
bin/rspec
Note: running the whole test suite on your machine might take more than an hour, so it's strongly recommended that you setup a Continuous Integration system in order to run them using parallel jobs every time you open or modify a pull request (if you use GitHub Actions or GitLab CI, this is already configured in .github/workflows/tests.yml and .gitlab-ci.yml) and only run tests related to your current task while developing on your machine. When you configure the application for the first time, it's recommended that you run at least one test in spec/models/ and one test in spec/system/ to check your machine is properly configured to run the tests.
You can use the default admin user from the seeds file:
user: admin@consul.dev pass: 12345678
But for some actions like voting, you will need a verified user, the seeds file also includes one:
user: verified@consul.dev pass: 12345678
Configuration for production environments
See installer
License
Code published under AFFERO GPL v3 (see LICENSE-AGPLv3.txt)
Contributions
See CONTRIBUTING.md