- Create a
.env
file
cp .env.template .env
Update values as needed (see Environment Variables.
-
Install Node.js version 18 (doing this using nvm is recommended).
-
Install dependencies
npm install
npm install -ws
psql
needs to be installed for running tests
Depending on the work being done, some environment variable will not be required for the service to run.
For these, simply fill in any fake value to prevent require-env-variable
from throwing errors.
Variable | Default | Notes |
---|---|---|
ENV | local | Tells stela what environment it's running in |
DATABASE_URL | postgres:https://postgres:permanent@database:5432/permanent | Run tests to generate default database |
PORT | 8080 | Tells stela what port to run on |
FUSIONAUTH_HOST | <none. needs to be set> | Fusionauth's host URL. Should be different between prod and other envs. |
FUSIONAUTH_API_KEY | <none. needs to be set> | Find it in Fusionauth admin panel -> settings -> API keys -> the one called "back-end (local)" |
FUSIONAUTH_TENANT | <none. needs to be set> | Find it in Fusionauth admin panel -> Tenants -> the one called "Local" |
FUSIONAUTH_BACKEND_APPLICATION_ID | <none. needs to be set> | Find it in Fusionauth admin panel -> Applications -> the one called "back-end (local)" |
FUSIONAUTH_ADMIN_APPLICATION_ID | <none. needs to be set> | Find it in Fusionauth admin panel -> Applications -> the one called "admin-local" |
LEGACY_BACKEND_HOST_URL | https://load_balancer:80/api | |
LEGACY_BACKEND_SHARED_SECRET | none | Can be found in back-end 's library/base/constants/base.constants.php |
MAILCHIMP_API_KEY | none | Can be found in back-end 's library/base/constants/base.constants.php |
MAILCHIMP_TRANSACTIONAL_API_KEY | none | Can be found in back-end 's library/base/constants/base.constants.php, where it is called MANDRILL_API_KEY |
MAILCHIMP_DATACENTER | us12 | |
MAILCHIMP_COMMUNITY_LIST_ID | 2736f796db | The default value corresponds to the dev list |
SENTRY_DSN | none | Can be found in Sentry under Projects > stela > Settings > Client Keys (DSN) |
DEV_NAME | none | Only set in local environments. Should be your given name. all lowercase. Used to create Sentry envs for developers |
AWS_REGION | us-west-2 | |
AWS_ACCESS_KEY_ID | none | The same one you use in devenv |
AWS_SECRET_ACCESS_KEY | none | The same one you use in devenv |
LOW_PRIORITY_TOPIC_ARN | test | Doesn't need to be set to a real ARN unless your work touches it specifically |
MIXPANEL_TOKEN | none | Found in Mixpanel at Settings > Project Settings > Project Token |
ARCHIVEMATICA_BASE_URL | none | It is the url of the EC2 instance on which archivematica is running |
ARCHIVEMATICA_API_KEY | none | Found in Bitwarden, not needed unless you're running the cleanup cron |
CLOUDFRONT_URL | none | Can be found as CDN_URL in back-end 's library/base/constants/base.constants.php. Not required for API server |
CLOUDFRONT_KEY_PAIR_ID | none | Can be found as CLOUDFRONT_KEYPAIR in back-end 's library/base/constants/base.constants.php. Not required for API server |
CLOUDFRONT_PRIVATE_KEY | none | Can be found in back-end 's library/static/certs/pk-APKAJP2D34UGZ6IG443Q.pem. Not required for API server |
Run
npm run lint -ws
Make sure the local database from devenv
's docker compose is running
docker compose up -d
then run tests with
npm run test -ws
or, for a single project, specify the workspace
npm run test -w @stela/api
Note that the database tests run against is dropped and recreated at the beginning of each test run.
For running tests on a single file in stela
, you can make an adjustment to the existing test
command in packages/api/package.json on your machine. See the example below (replace src/middleware/authentication.test.ts with a pattern to match your file):
"test:file": "npm run start-containers && npm run clear-database && npm run create-database && npm run set-up-database && (cd ../..; docker compose run stela node --experimental-vm-modules ../../node_modules/jest/bin/jest.js -i --silent=false -- src/middleware/authentication.test.ts)",
Preferred method: From the devenv
repo, run
docker compose up -d
or if you've added or updated dependencies, run
docker compose up -d --build stela
Outside a container: Run
npm run start -w @stela/api
- Build the lambda image
docker build --platform linux/amd64 -t <LAMBDA NAME>:test -f Dockerfile.<LAMBDA NAME> .
- Run the lambda container. Add additional --env arguments as needed. Note that the
CLOUDFRONT_PRIVATE_KEY
required by therecord_thumbnail_attacher
must include literal newlines; docker does not appear to interpret\n
correctly.
docker run --platform linux/amd64 -p 9001:8080 --env DATABASE_URL=postgres:https://postgres:permanent@database:5432/permanent <LAMBDA NAME>:test
- Find the container name
docker ps
- Connect to the local env docker network
docker network connect devenv_default <YOUR CONTAINER NAME>
- Trigger the lambda
curl "https://localhost:9001/2015-03-31/functions/function/invocations" -d '<YOUR PAYLOAD>'
stela
deploys to dev
automatically upon any merge to main
.
To deploy to staging
and prod
, create a Release with a tag of the form vX.X.X
(this should conform to semantic
versioning). This will trigger a deploy to staging. If that is successful, the workflow will pause and wait for manual
approval to deploy to prod. Given manual approval, it will deploy to prod.
To deploy to staging
without deploying to prod, run the "Deploy to staging" workflow from the Actions tab.
Because dev
and staging
run on the same EKS cluster, deploys to each of these environments just target the stela
deployments and won't update the underlying infrastructure they run on. To update that infrastructure, manually trigger
the "Deploy to all test envs" workflow from the Actions tab in Github. This will deploy the current main
branch to
dev
and staging
in addition to updating the test cluster infrastructure.