This project offers citizens a way to apply for different city grants for their associations or themselves.
| Env | Branch | Url |
|---|---|---|
| local | * | https://hel-fi-drupal-grant-applications.docker.so/ |
| development | * | https://avustukset.dev.hel.ninja |
| testing | develop | https://avustukset.test.hel.ninja |
| staging | release/* | https://avustukset.stage.hel.ninja |
| production | main | https://avustukset.hel.fi (https://nginx-avustusasiointi-prod.apps.platta.hel.fi/ before release) |
You need to have these applications installed to operate on all environments:
- Docker
- Stonehenge
- For the new person: Your SSH public key needs to be added to servers
For the first time (new project):
$ make new
And following times to create and start the environment:
$ make fresh
NOTE: Change these according of the state of your project.
This will log you inside the app container:
$ make shell
In addition to normal cim/cex things, we have custom importers for Webform & their translations. This is because it's hard to control form imports with normal setup.
ALL webforms are ignored by default with config_ignore module.
To import forms & translations you can run following command:
$ drush gwi
This imports ALL webform and their translations apart from the specifically skipped production forms.
We have many forms in different states of production, some are in development which we want & can override every time. But then we have forms that are in production and CANNOT be overridden by config, and those can be ignored by their applicationID in grants_metadata.settings.
Like so:
config_import_ignore:
- 53
- 51
This ignores forms with ID's of 53 & 51.
We will ignore every production form like this, but those forms need to be be overridden sometimes. For that we have command to import only single form with it's applicationId.
$ drush gwi 53
To enable xdebug, run export XDEBUG_ENABLE=true before (re)starting your project. More info in docker-composer.yml
Works is done & issues tracked on our Jira board.
Production monitoring dashboard.
Drupal uses phpunit library for tests and it is installed via composer as a development dependency. Tests are configured using phpunit.xml file in module root. Drupal documentation about tests an be found here
There are three kind of tests. Unit tests are for testing code without loading Drupal. Kernel tests are run always with Drupal core and during the test setup phase modules can be installed and configurations loaded. These can be used to test features that tied to Drupal fore features like services and events. Functional tests are run with whole Drupal and they can be used to test any Drupal functionality.
Each kind of test case has base class that are extended to create tests.
Run tests related to AtvSchema: vendor/bin/phpunit -c public/modules/custom/grants_metadata It generates coverage report in html format under public/modules/custom/grants_metadata/html-coverage. Use browser to open dashboard.html to see the report.
Run tests related to application handling: vendor/bin/phpunit -c public/modules/custom/grants_handler
E2E (End-to-End) tests ensure the whole application works as intended from a user's perspective. We use Playwright for our E2E testing.
- Node.js 16+ or Docker
- Create
e2e/.envfile based one2e/.env.example
You can run E2E tests in a Docker container. To do this:
make test-pw
To run a specific test file in the container, use:
make test-pw path/to/test/file
Go to the tests directory
cd e2e
Install the necessary dependencies:
npm install
To run the tests:
npx playwright test
For an interactive UI mode:
npx playwright test --ui
To execute tests in a specific file:
npx playwright test path/to/test/file
To view the test report:
npx playwright show-report
Can be found from here.