-
Notifications
You must be signed in to change notification settings - Fork 2k
[Cloud Run] Identity Platform + Cloud SQL sample #1984
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I've started an extensive review, planning to send by end of day. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots to review here. The basic structure of the app seems good, and all the logic makes sense. Most of my feedback is around clarity, CI/CD practices, Secret handling practices, and library selection.
@@ -0,0 +1,64 @@ | |||
# Copyright 2020 Google LLC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: script provisions infrastructure when running cloud run button
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this script only usable in the context of cloud run button? If not, maybe it should have a name like setup.sh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rubberstamp lgtm
5fafcd7
to
98affc0
Compare
98affc0
to
60d5254
Compare
7d1672c
to
eff522c
Compare
@grayside from my investigation, most of the flaky tests come from trying to delete a resource already deleted or deleting it too soon. I haven't seen a case where the build or deploy fails when it should be successful. Using the cloud build for setup and clean up should prevent resources from being cleaned up before tests finish running. Though I've added a |
- '-c' | ||
- | | ||
. /workspace/test/retry.sh | ||
retry "gcloud secrets describe ${_SERVICE}-secrets" \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks nice and clean. We should spread the word. Note if retry.sh is directly the script we would just need to confirm it's executable in one step and not need to source it in each step for use.
run/idp-sql/test/e2e_test_setup.yaml
Outdated
args: | ||
- '-c' | ||
- | | ||
gcloud run deploy ${_SERVICE} \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While the "ensure-exists" model of the current retry script wouldn't work, we do want to retry this as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I've experience an error deploying unless it's my fault the service doesn't start. Since deployment failures seem rare, I would lean on not implementing retries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know that I've seen a trend in which operations fail most on nightly tests, I've seen build, deploy, and delete all have issues. We can leave it at this for now, but I'm strongly recommending every API interaction have a retry.
run/idp-sql/test/system.test.js
Outdated
if (!BASE_URL) throw Error('Cloud Run service URL not found'); | ||
console.log('Cloud Run service URL found.'); | ||
|
||
const idToken = execSync('gcloud auth print-identity-token'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I think using the client library is better than print-identity-token. This gcloud command is used in CI for lack of a better option, but it seems to me that it's meant to facilitate local dev with a tradeoff of reducing project security.
run/idp-sql/test/system.test.js
Outdated
|
||
const url = execSync( | ||
`gcloud run services describe ${SERVICE_NAME} --project=${GOOGLE_CLOUD_PROJECT} ` + | ||
`--platform=managed --region=us-central1 --format='value(status.url)'`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Since this file "owns" how the testing will work and the Cloud Build file is configurable, ideally the build substitutions will be set from this file instead of rely on synchronized defaults.
run/idp-sql/test/system.test.js
Outdated
const uuid = require('short-uuid'); | ||
const {execSync} = require('child_process'); | ||
|
||
describe('System Tests', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now/Future Enhancement: Given all the setup overhead for end-to-end tests, deeper coverage is worthwhile. It will cost seconds and we're already invested a couple minutes.
The existing "light" test coverage is not because it's preferred but because that's a level of test coverage I could add to many of the samples in an afternoon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how to extend test coverage here. Since we deploy with authentication, that conflicts with the authentication of POST request route.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can special case this to deploy without authentication.
The principle is that apps are not publicly accessible, but what you're saying is that this (mostly) isn't, because of a different auth mechanism.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from the package.json engine update, this is LGTM. Approving in anticipation of the easy fix before or after merge.
.kokoro/build-with-run.sh
Outdated
export DB_NAME="kokoro_ci" | ||
export DB_USER="kokoro_ci" | ||
export DB_PASSWORD=$(cat $KOKORO_GFILE_DIR/secrets-sql-password.txt) | ||
export CLOUD_SQL_CONNECTION_NAME=$(cat $KOKORO_GFILE_DIR/secrets-pg-connection-name.txt) | ||
|
||
export FIREBASE_KEY=$(cat $KOKORO_GFILE_DIR/secrets-firebase-key.txt) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could configure this to only work if the idp-sql sample is being tested. That seems like a higher level of secret paranoia than this repo applies.
run/idp-sql/app.js
Outdated
// Save the data to the database. | ||
try { | ||
await insertVote(vote); | ||
logger.info({message: 'vote_inserted', vote, traceId: req.traceId}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit/future: traceId here is ok, but makes the trace elements higher visibility around the code.
The pattern I'd expect is for the middleware to duplicate the global logger, set request-specific defaults, and provide a request-scoped logger for this controller. Given this code is not region tagged, it's a low priority.
run/idp-sql/index.js
Outdated
if (!process.env.GOOGLE_CLOUD_PROJECT) { | ||
try { | ||
const project = await auth.getProjectId(); | ||
process.env.GOOGLE_CLOUD_PROJECT = project; // Set GOOGLE_CLOUD_PROJECT for log correlation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit/future: code smell to pass this around as an environment variable. We could pass this in to the logger object immediately.
I wonder if this should do a knex.destroy() on sigterm. |
@grayside - I am specifically hesitant about the secret loading in
cloud-sql.js
.@kurtisvg - tagging for a Cloud SQL review.