Adding env variables to use for google api

[MooseQuest]

This closes #500

The secrets file associated with this is deployed into bit warden. Need a chime-ops admin to retrieve. Environment variables are called within the app itself.

[lottspot]

If we apply this to prod before the secrets are added, it's gonna break deployments. We should probably hold this merge until the secrets are created.

[MooseQuest]

I created the secrets in preprod — I’ll create the in prod after testing.

On Mon, Apr 6, 2020 at 20:05 James Lott notifications@github.com wrote:

If we apply this to prod before the secrets are added, it's gonna break deployments. We should probably hold this merge until the secrets are created.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/CodeForPhilly/chime/pull/501#issuecomment-610099224, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE7V5MNHVNHKCJO3DR4SBQDRLJU33ANCNFSM4MCVYYLQ .

[MooseQuest]

@lottspot The secrets were created at the time of this PR merged. I'm still a bit confused on how to rudimentary test this change with the branches, so it's just a matter of testing with...? (Code has to be updated in the app, and I could be mistaken but we don't build the container from the build process).

[MooseQuest]

@lottspot The secrets were created at the time of this PR merged. I'm still a bit confused on how to rudimentary test this change with the branches, so it's just a matter of testing with...? (Code has to be updated in the app, and I could be mistaken but we don't build the container from the build process).

I see this: https://github.com/CodeForPhilly/chime/blob/dsgit1-patch-1/.github/workflows/dockerpublish.yml

But I think what I'm missing is does this actually update preprod (in the PR? or does it do it after the PR is approved)

[lottspot]

But I think what I'm missing is does this actually update preprod (in the PR? or does it do it after the PR is approved)

It does neither. It operates completely independent of PRs. It will deploy tagged versions to preprod, because only tagged versions are being built into docker images (merges into develop are not currently triggering docker builds).

[lottspot]

The way you would test this now that the secret is added to preprod would be to attempt to deploy this change to preprod, and confirm the rollout completes successfully. So, using preprod kubeconfig:

kubectl apply -f k8s/app.yaml
kubectl -n chime rollout status deployment.v1.apps/chime

just... be sure you aren't using the wrong kubeconfig 😉

[lottspot]

The version of the code doesn't really matter as far as testing this change from an infrastructure perspective. You can simply run the test from this branch.

[MooseQuest]

The secrets have been applied to both environments. We can unblock this PR.

[lottspot]

The changes to app.yaml should be applied to/verified in preprod before we unblock/merge

[MooseQuest]

kubectl apply -f k8s/app.yaml kubectl -n chime rollout status deployment.v1.apps/chime

This is complete:

17:06:50 khende810 HQSML-1717855 /Users/khende810/repo/chime google-api-sheets
$ kubectl -n chime rollout status deployment.v1.apps/chime
deployment "chime" successfully rolled out

[rcknplyr]

@lottspot looking to close down open issues/PRs on this repo. Do we need to implement this in this repo, given we are moving to maintenance mode?