You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Remove unused docker stacks
Update dev stacks to silence warnings
* Add start-bare-metal command to corgi cli
Effectively runs the same command as docker entrypoint
* Add build-frontend command; update fronted packages
Add python version and nvmrc
* Make environ optional for start-bare-metal
Easier to test this way
* Check python version matches docker version
* Add install script and source .env before start
* Add script to install secrets with aws ssm
For launch template
Add secrets spec; update install_secrets
For more information about how this secrets spec works, see openstax/aws-ruby repository
Turns out top_key is not optional in secrets spec
That README in openstax/aws-ruby should really be updated
When the secrets factory is being created, `.to_sym` is called on the top_key
That means it cannot be nil
Then top_key is used as a key for the secrets spec, even if it is an empty string
Consequently, top_key is required
* Support url-safe base64 encoding for session secret
* Add gunicorn logging configuration options
* Remove unused scripts
* Add .poetry-version file
We have had problems with poetry lock file compatibility in the past
This file will be read by the ansible playbook to determine which version of poetry to install
* Remove hotdog README section
This will need to work differently in the future if it's ever revived
Leaving the scripts for now as they might still be useful
* install_secrets: Ensure secret_name and secret_value have values for each secret
* Small update to corgi cli and ci tests
* Bump version for rollup-plugin-css-only
This version should be idempotent (hopefully)
* Get session secret from substitution
Copy file name to clipboardExpand all lines: README.md
-37Lines changed: 0 additions & 37 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -307,43 +307,6 @@ with requests.session() as session:
307
307
print(jobs.json())
308
308
```
309
309
310
-
## Testing Unmerged CORGI & Enki Changes in Concourse
311
-
312
-
[CORGI Hotdog](https://corgi-hotdog.ce.openstax.org/) is a testing environment for experimenting with changes before they go to staging.
313
-
314
-
URL: https://corgi-hotdog.ce.openstax.org/
315
-
316
-
### Use cases for hotdog
317
-
- Catching issues that do not appear on Enki GitHub actions but does error in Concourse
318
-
- Experimenting with changes that would be difficult/tedious to test locally (changes to concourse resource, upload steps, etc.)
319
-
320
-
### Deploy Porcess
321
-
322
-
- Two ways to deploy changes
323
-
-https://corgi-hotdog.ce.openstax.org/hotdog
324
-
* Enter the ref for one or both repos into the fields (ref can be commit sha or branch name)
325
-
- There is a script in [ce-scripts](https://github.com/openstax/ce-scripts/blob/c6c2e63d8941392003a4462c8a73e86aa06a598e/bash/hotdog)
326
-
* Run this script in Enki or CORGI.
327
-
* You can either specify a ref as an argument to the script or use your current ref by omitting this argument.
328
-
- At this point, the two ways converge and the following occurs
329
-
- Success message
330
-
- On concourse, corgi-hotdog, wait for hotdog-head to get new checked out version, this triggers a concourse build pipeline is set in build-deploy-Enki
331
-
- See api call: `corgi-hotdog.openstax.org/hotdog/head` if you would like more details
332
-
- Since concourse depends on production Enki tags on dockerhub, there isn’t a way to do concourse + dev Enki tag — except thru hotdog
333
-
- Hotdog tag on dockerhub: corgi-hotdog rebuild as whatever dev ref you give it, then rebuilds the docker image for Enki.
334
-
- Rebuild triggered by submitting a new ref.
335
-
- Wait to build hotdog tag and push to dockerhub. At this point, you can create a job. still have to wait for concourse (steps: corgi-git-pdf & corgi-resource) to fetch the tag. then eventually the job will run.
336
-
- Some additional details are
337
-
- If you checkout a branch, you will need to checkout the branch again if you want to pull the latest changes from the branch
338
-
- Jobs run on concourse. See logging & progress details on concourse/CORGI.
339
-
- In hotdog corgi ui: worker-version tells you what Enki ref it is & a timestamp
340
-
- Only one corgi-hotdog tag at a time
341
-
342
-
### Hotdog TODO
343
-
1. Automatically pull changes from branches
344
-
1. Automatically redeploy the stack if python dependencies change (maybe add a field to corgi refs that, when set, will trigger deploy on checkout?)
345
-
1. Consider creating a hybrid of PR pipeline so each PR can have a hotdog stack
346
-
347
310
## Generating an ERD
348
311
349
312
The corgi CLI supports generating an ERD from database data. The auto-generated ERD, as well as a small description, replaces the README section labeled `## CORGI ERD`.
0 commit comments