Working local dev environment on Apple M1 Macs #64
Labels
housekeeping
Refactoring, tidying up or other work which supports the project
Comments
Cruikshanks
added
the
housekeeping
Cruikshanks
added a commit
to DEFRA/water-abstraction-ui
that referenced
this issue
Nov 28, 2022
DEFRA/water-abstraction-team#64 To help simplify things in our new Docker based build environment and to take advantage of something we learned on [water-abstraction-system](https://github.com/DEFRA/water-abstraction-system) this change adds a post install step. If we're running `npm ci` you can be sure we also want to build our assets (we certainly should be!) So, with this change that will happen automatically. We've left the old script command there for now whilst we update our various environments. But once that's done we'll drop `"install-assets": "gulp build",` from `package.json`.
Cruikshanks
added a commit
to DEFRA/water-abstraction-ui
that referenced
this issue
Nov 29, 2022
DEFRA/water-abstraction-team#64 To help simplify things in our new Docker-based build environment and to take advantage of something we learned on [water-abstraction-system](https://github.com/DEFRA/water-abstraction-system) this change adds a post-install step. If we're running `npm ci` you can be sure we also want to build our assets (we certainly should be!) So, with this change that will happen automatically. We've left the old script command there for now whilst we update our various environments. But once that's done we'll drop `"install-assets": "gulp build",` from `package.json`.
StuAA78
added a commit
to DEFRA/water-abstraction-import
that referenced
this issue
Nov 30, 2022
DEFRA/water-abstraction-team#64 We currently hardcode the url of the test database in our `package.json` which isn't good practice, and also causes us problems when running within a Docker environment (as per the linked issue). We want to use `DATABASE_URL` instead as `db-migrate` will use this url if it exists. Unfortunately this causes an issue when we want to run migrations against different dbs in the same environment -- eg. normally we want migrations to run against our regular db but when running unit tests, we want migrations to run against the test db. `db-migrate` does allow for setting different environments in `database.json` (as in test, prod etc.) but this then moves configuration away from our `.env` file -- not what we want when our environments are more like "local", "local test", "CI test", etc. We therefore create a script `scripts/migrate.js`, which checks `NODE_ENV` to see if the environment is `test` or not and sets `DATABASE_URL` accordingly before running `db-migrate up`: - If `NODE_ENV` is `test` then it sets `DATABASE_URL` to the value of `TEST_DATABASE_URL` in the `.env` file; - Otherwise, it simply uses `DATABASE_URL` as-is. We update our `package.json` so that this is run whenever we would normally run `db-migrate up`. Since `lab` sets `NODE_ENV` to `test`, we don't need to make any changes to our `test` script. We also update `config.js` to also check `NODE_ENV` when setting the db connection string -- again, if `NODE_ENV` is `test` then we use `TEST_DATABASE_URL`, otherwise we use `DATABASE_URL`. This therefore means that things like the "create schema" script don't need to be changed as these use the db connection string in `config.js`.
StuAA78
added a commit
to DEFRA/water-abstraction-permit-repository
that referenced
this issue
Nov 30, 2022
DEFRA/water-abstraction-team#64 We currently hardcode the url of the test database in our `package.json` which isn't good practice, and also causes us problems when running within a Docker environment (as per the linked issue). We want to use `DATABASE_URL` instead as `db-migrate` will use this url if it exists. Unfortunately this causes an issue when we want to run migrations against different dbs in the same environment -- eg. normally we want migrations to run against our regular db but when running unit tests, we want migrations to run against the test db. `db-migrate` does allow for setting different environments in `database.json` (as in test, prod etc.) but this then moves configuration away from our `.env` file -- not what we want when our environments are more like "local", "local test", "CI test", etc. We therefore create a script `scripts/migrate.js`, which checks `NODE_ENV` to see if the environment is `test` or not and sets `DATABASE_URL` accordingly before running `db-migrate up`: - If `NODE_ENV` is `test` then it sets `DATABASE_URL` to the value of `TEST_DATABASE_URL` in the `.env` file; - Otherwise, it simply uses `DATABASE_URL` as-is. We update our `package.json` so that this is run whenever we would normally run `db-migrate up`. Since `lab` sets `NODE_ENV` to `test`, we don't need to make any changes to our `test` script. We also update `config.js` to also check `NODE_ENV` when setting the db connection string -- again, if `NODE_ENV` is `test` then we use `TEST_DATABASE_URL`, otherwise we use `DATABASE_URL`. This therefore means that things like the "create schema" script don't need to be changed as these use the db connection string in `config.js`.
StuAA78
added a commit
to DEFRA/water-abstraction-service
that referenced
this issue
Nov 30, 2022
DEFRA/water-abstraction-team#64 We currently hardcode the url of the test database in our `package.json` which isn't good practice, and also causes us problems when running within a Docker environment (as per the linked issue). We want to use `DATABASE_URL` instead as `db-migrate` will use this url if it exists. Unfortunately this causes an issue when we want to run migrations against different dbs in the same environment -- eg. normally we want migrations to run against our regular db but when running unit tests, we want migrations to run against the test db. `db-migrate` does allow for setting different environments in `database.json` (as in test, prod etc.) but this then moves configuration away from our `.env` file -- not what we want when our environments are more like "local", "local test", "CI test", etc. We therefore create a script `scripts/migrate.js`, which checks `NODE_ENV` to see if the environment is `test` or not and sets `DATABASE_URL` accordingly before running `db-migrate up`: - If `NODE_ENV` is `test` then it sets `DATABASE_URL` to the value of `TEST_DATABASE_URL` in the `.env` file; - Otherwise, it simply uses `DATABASE_URL` as-is. We update our `package.json` so that this is run whenever we would normally run `db-migrate up`. Since `lab` sets `NODE_ENV` to `test`, we don't need to make any changes to our `test` script. We also update `config.js` to also check `NODE_ENV` when setting the db connection string -- again, if `NODE_ENV` is `test` then we use `TEST_DATABASE_URL`, otherwise we use `DATABASE_URL`. This therefore means that things like the "create schema" script don't need to be changed as these use the db connection string in `config.js`.
StuAA78
added a commit
to DEFRA/water-abstraction-service
that referenced
this issue
Dec 1, 2022
DEFRA/water-abstraction-team#64 We currently hardcode the url of the test database in our `package.json` which isn't good practice, and also causes us problems when running within a Docker environment (as per the linked issue). We want to use `DATABASE_URL` instead as `db-migrate` will use this url if it exists. Unfortunately this causes an issue when we want to run migrations against different dbs in the same environment -- eg. normally we want migrations to run against our regular db but when running unit tests, we want migrations to run against the test db. `db-migrate` does allow for setting different environments in `database.json` (as in test, prod etc.) but this then moves configuration away from our `.env` file -- not what we want when our environments are more like "local", "local test", "CI test", etc. We therefore create a script `scripts/migrate.js`, which checks `NODE_ENV` to see if the environment is `test` or not and sets `DATABASE_URL` accordingly before running `db-migrate up`: - If `NODE_ENV` is `test` then it sets `DATABASE_URL` to the value of `TEST_DATABASE_URL` in the `.env` file; - Otherwise, it simply uses `DATABASE_URL` as-is. We update our `package.json` so that this is run whenever we would normally run `db-migrate up`. Since `lab` sets `NODE_ENV` to `test`, we don't need to make any changes to our `test` script. We also update `config.js` to also check `NODE_ENV` when setting the db connection string -- again, if `NODE_ENV` is `test` then we use `TEST_DATABASE_URL`, otherwise we use `DATABASE_URL`. This therefore means that things like the "create schema" script don't need to be changed as these use the db connection string in `config.js`.
Cruikshanks
added a commit
to DEFRA/water-abstraction-system
that referenced
this issue
Dec 5, 2022
DEFRA/water-abstraction-team#64 Having built a new development environment based on Docker and Docker Compose that allows us to setup and maintain WRLS on Apple M1 Mac's we've hit some further issues. A number of the repos have it had coded into the tests to assume everything is always running on `http://localhost`. When it comes to our new Docker environment though, the Addressbase Facade and the Charge Module aren't anymore. When it comes to this repo, the other assumption is that the machine the app is running on has the redis CLI installed. In our new dev environment that isn't the case, and shouldn't be assumed in our AWS environments. So, this change - fixes unit tests not to depend on hard coded urls - makes the redis based tests pending (we'll tackle those properly once we have implemented redis support)
Cruikshanks
added a commit
to DEFRA/water-abstraction-system
that referenced
this issue
Dec 6, 2022
DEFRA/water-abstraction-team#64 Having built a new development environment based on Docker and Docker Compose that allows us to set up and maintain WRLS on Apple M1 Mac's we've hit some further issues. A number of the repos have it had coded into the tests to assume everything is always running on `http://localhost`. When it comes to our new Docker environment though, the Addressbase Facade and the Charge Module aren't anymore. So, this change updates the unit tests not to depend on hard-coded URLs.
|
We now have a working environment based on docker and docker-compose. Most of the team is using it on the new M1 Macs. Some are still on the old Macs but have switched to it. From this point on our vagrant-based dev-environment is dead and won't be getting any more attention. So, marking this ticket as complete. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Every now and again we're fortunate enough to get a machine refresh. This ensures we're running the latest and greatest, and our old machines can be used by the contractors we bring in.
It's a great opportunity to tidy things up and re-think the tools and settings you're using. So, apart from some niggles we typically switch without much of a bump. That was until the latest and greatest became M1 Macs sporting Apple Silicon.
Our current dev build is based on vagrant backed by virtualbox. That's all well and good when using a Mac with Intel-inside! But there are issues when using Apple's new ARM-based chips.
Virtualbox has a developer preview out which supports M1 and M2 Macs. But it is flagged as not having feature parity and anecdotally performance is said to be an issue.
WRLS is already dogged by performance woes and already sucks up whatever our machines have available. So, we need to come up with an alternate to virtualbox.
The text was updated successfully, but these errors were encountered: