This changeset updates the README.md file with a set of entirely new instructions. These updates are intended to improve clarity, simplify steps, and reduce confusion and environment-setup gotchas that folks have run into previously and we have learned from. A couple of other changes are also included:
- Minor adjustments to the Makefile to improve make bootstrap
- Updates to the sample.env file to include previously missing required environment variables and/or information
- Additional support for Python virtual environments
- Removes tracking of the .python-version file used by pyenv
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
This changeset updates a few more dependencies and addresses the challenges we have had in keeping the notifications-utils dependency up-to-date. The changes include instructions on what to do going forward for future notifications-utils updates.
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
This changeset updates several dependencies to address security audit findings and also adds a py-lock make command to make managing our Python dependencies more manageable.
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
This changeset takes care of leaving E2E tests in a clean state so that
we can revisit the work later. The efforts to add authentication
support did not pan out, so we will go a different route in the near
future.
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
This changeset lays the foundation for supporting E2E (end-to-end) integration tests for US Notify. It brings in the Playwright testing framework along with the Playwright pytest plugin to make this possible, and includes the following adjustments:
- A new test session fixture for ensuring that Playwright authenticates with the sites that are currently behind HTTP Auth (requies env-var config)
- A new end_to_end test directory specifically for E2E tests
- Updates to the Makefile that make sure E2E tests are not run as a part of the normal test routine but can be run separately
- A new command in the Makefile to run E2E tests that will run in Chromium, Firefox, and Webkit headless browsers
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
We have decided to use NVM to manage installed Node versions locally
and in CI to ensure they match and produce consistent builds.
Running `nvm install` will install the Node version specified in the
`.nvmrc` file.
This is now consistent with Document Download Frontend.
See: alphagov/document-download-frontend#114
Signed-off-by: Richard Baker <richard.baker@digital.cabinet-office.gov.uk>
When editing CSS, Javascript or other assets it’s useful to not have to
run `gulp` manually to rebuild things after making changes.
This is why we have the `npm watch` script.
However for the paths to fonts to resolve properly when running locally
it needs the `NOTIFY_ENVIRONMENT` variable set to `development`. Having
to remember to do both of these steps every time is awkward.
For a one-off build of the frontend we added a command to set
`NOTIFY_ENVIRONMENT` to the appropriate value in https://github.com/alphagov/notifications-admin/pull/4049
This commit does the same thing for the watch task, by encapsulating
both steps in one `make` command.
Happy to take alternative suggestions on command naming.
Previous attempt: https://github.com/alphagov/notifications-admin/pull/4048
The problem with the previous attempt is that the assets built on
CI become part of the build artefact used for production [1]. This
switches back to my original approach of using environment.sh, but
with a technique to cope with it being absent on CI. I've tested it
works with and without an environment.sh file.
Note that "npm install" is fine to be on a separate line, since a
non-zero exit code will always cause "make" to stop.
[1]: https://github.com/alphagov/notifications-aws/blob/master/concourse/templates/admin.yml.j2#L47
This depends on an environment variable being set when the assets
are built in a development context [1]. Otherwise, the assets get
their '/static' prefix stripped like they do for production, which
isn't compatible with serving them under '/static' in development.
[1]: 66e5022198/gulpfile.js (L37-L41)
We now use `sass`, a JavaScript version of Sass,
compiled from dart-sass*, so shouldn't need to
rebuild it to solve issues with C libraries.
*https://github.com/sass/dart-sass
Depends on: https://github.com/alphagov/notifications-aws/pull/905
Previously this would print some custom text with each step, and
as optionally loading a virtual environment. This moves the actual
test commands to the Makefile. While this no longer prints custom
text, it does print the command that was run:
Before (skipping other output):
./scripts/run_tests.sh
Code style check passed
Import order check passed
...
JavaScript tests have passed
...
Unit tests have passed
After (skipping other output):
flake8 .
isort --check-only ./app ./tests
npm test
...
py.test -n auto --maxfail=10 tests/
...
I think it's more useful to see the command being run, rather than
having to wait until it succeeds to know what was happening. Having
the command also makes it easier to run it again if it fails, rather
than having to go and find it in a script.
