Skip to content

CHP Expansion - #701

Closed
Bill-Becker wants to merge 59 commits into
developfrom
chp-expand
Closed

CHP Expansion#701
Bill-Becker wants to merge 59 commits into
developfrom
chp-expand

Conversation

@Bill-Becker

Copy link
Copy Markdown
Collaborator

Please check if the PR fulfills these requirements

  • CHANGELOG.md is updated
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)
  • Any new Django model inputs have also been added to job/test/posts/all_inputs_test.json

What kind of change does this PR introduce?

(Bug fix, feature, docs update, ...)

What is the current behavior?

(You can also link to an open issue here)

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change?

(What changes might users need to make in their application due to this PR?)

Other information:

@Bill-Becker Bill-Becker changed the title Chp expand CHP Expansion Feb 3, 2026
@Bill-Becker
Bill-Becker changed the base branch from master to develop February 3, 2026 16:56
GUI added 21 commits April 20, 2026 20:08
- Remove old deployment files and dependencies. Some of these were even
  from older setups no longer used.

- Try to begin work on cleaning up configuration approach to make things
  easier to configure via environment variables. The previous approach
  had several layers of legacy approaches that had built up over time.
  There was also a lot of duplicate config where there were subtle
  drifts in configuration that this attempts to de-duplicate and unify.

None of this is actually hooked up yet, this is just the beginnings of
trying to work on new deployments.
Fixes various syntax errors and missing imports.

Also renames `keys.py` to `keys_env.py` just so we don't end up
conflicting with people's existing `keys.py` that was gitinored
previously.

Also sets up docker to use optional `.env` files which should simplify
the setup instructions and migration for existing users with custom
keys.py files.
This leverages GitHub Actions, along with other changes we've adopted,
like Vault for secrets, Pkl for Kubernetes configuration management, and
Carvel for deployments.

This also removes some areas that I believe are now unused, like the
nginx proxy layer, since it doesn't seem like that was previously being
used in production any longer.
Since these values were output in the metadata's own output, GitHub
Actions would fail, since it would prevent the metadata's output from
occurring since it thought it contained masked secrets.
This appears to be an existing staging issue, but it looks like django
keeps bumping into this limit and restarting workers inside the
container.
This brings back the restart job that used to be implemented in Jenkins.
While this is a bit funky to shoehorn this into this Python app, we have
other components of our deployment process that use this library to
provide easy database restores, so by leveraging this library, this is
the easiest way to integrate that process with this app.
GUI and others added 29 commits June 3, 2026 17:14
Since this is an optional container only used in local development,
shift it to a profile so that it doesn't start by default. This
container will only work for NLR developers, so we don't want it
starting/building by default in the CI environment or for other users.
Also update the nojulia docker compose variant to align with the main
docker compose file that uses the default postgres superuser now (to
better align with other environments).
If the user doesn't have CREATE privileges at the database level, then
even if the schema already exists, the `CREATE SCHEMA IF NOT EXISTS`
will fail.
Align everything on the `reopt` database name as the default. This
matches the other `DB_NAME` environment variables being passed into the
Celery and Django containers.
PostgreSQL v18 updates; Database restores
Move to GitHub Actions for deployments; other deployment updates/cleanup
Part of the larger, manual rollout of the deployment changes in
#714
Reenable staging deploys after dry-run tests
Part of the larger, manual rollout of the deployment changes in
#714
Reenable production deploys after dry-run tests
Remove the duplicative nrel.gov ingress now that everything with
developer.nlr.gov is cutover to use the nlr.gov ingress.
This was a copy-paste issue from staging, but the production variable
name differs.
Fix ingress to set explicit host for production ingress
@Bill-Becker Bill-Becker closed this Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants