Deployment CI

[davenquinn]

We need a deployment CI! A functional production deployment CI for this project will check that

• The version has been incremented (using a new git tag)
• The current version references the main branch
• The repo is not dirty
• The UW-Macrostrat/web-components submodule is also on the main branch and pushed.
• A Changelog entry exists for this release

It would also be nice to check that a few pages render properly, as a basic test

[davenquinn]

More info: automated process should be

1. build app for production
2. run tests (ssr a few pages, maybe check some common routes and 404s). Probably no need to actually execute in a browser environment, at least to start
3. make sure repo and submodules are not dirty and that changes are pushed
4. grab version tag from the package.json file, make sure it isn't equivalent to a previous tag
5. apply version tag
6. push to github

Presumably CI kicks in at that point and runs tests (again) and builds the docker container. I guess we could also build locally and upload.

An example of this type of release process can be found in the Sparrow repository although this one should be in Javascript, not Python.

[davenquinn]

@CannonLock it would be great to get an automated deployment process rolling at some point. Do you think this is feasible?

[CannonLock]

@davenquinn That all looks good minus:

make sure repo and submodules are not dirty and that changes are pushed

If this is running as a github CI I don't see how this is possible.

[davenquinn]

@CannonLock I agree that if everything is handled within GitHub CI, these checks take care of themselves, as the deployment will fail if submodule commits don't exist.

I was envisioning this as part of the "end-to-end" workflow, where there is an internal "deploy" script that tests locally, and runs some pre-checks before tagging/uploading the. version. This can ensure that all submodules are available, etc. before sending it to CI.

Fundamentally, either way should work

[CannonLock]

#102 Adds the a tagging system that with the correct kubernetes objects ( documented ) can be used to set this up.

It additionally tests the build which will test that the above items are valid.

I think the one thing left to build from this list are:

• Having each new change check for a new version tag