This will trigger a docker build and push it to GCR on updates to the master branch (both PR merges and direct commits to master will trigger this). Closes #5 .
This assumes that we have a Dockerfile in the root of the repository, so I think the other open PR has to merge first.
I still need to create the GCR service account, generate the key, and add it to this repository's Secrets in the settings.
Two things:
does clingen have any sort of scripts or other config management code for creating service accounts, or are they generally created by hand?
For docker images, I generally favor a promotion approach for moving releases from dev -> stg -> prod. By namespacing our docker image in a clingen-dev registry, it kind of necessitates that we build and deploy different images for each environment, rather than promote the same artifact. Both approaches will work, but I just want to make sure that we understand the distinction between the two approaches. I don't want to bog us down now with too many questions, so I'm happy to chat about this later.
This will trigger a docker build and push it to GCR on updates to the master branch (both PR merges and direct commits to master will trigger this). Closes #5 .
This assumes that we have a Dockerfile in the root of the repository, so I think the other open PR has to merge first.
I still need to create the GCR service account, generate the key, and add it to this repository's Secrets in the settings.
Two things:
clingen-devregistry, it kind of necessitates that we build and deploy different images for each environment, rather than promote the same artifact. Both approaches will work, but I just want to make sure that we understand the distinction between the two approaches. I don't want to bog us down now with too many questions, so I'm happy to chat about this later.