Skip to content

[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

Merged
merged 40 commits into from
Oct 21, 2020
Merged

Conversation

averikitsch
Copy link
Contributor

@grayside - I am specifically hesitant about the secret loading in cloud-sql.js.
@kurtisvg - tagging for a Cloud SQL review.

@google-cla google-cla bot added the cla: yes This human has signed the Contributor License Agreement. label Sep 25, 2020
@product-auto-label product-auto-label bot added the samples Issues that are directly related to samples. label Sep 26, 2020
@grayside
Copy link
Collaborator

I've started an extensive review, planning to send by end of day.

Copy link
Collaborator

@grayside grayside left a 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
Copy link
Contributor Author

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

Copy link
Collaborator

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

Copy link
Contributor

@fhinkel fhinkel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rubberstamp lgtm

@averikitsch averikitsch force-pushed the cats-v-dogs branch 2 times, most recently from 5fafcd7 to 98affc0 Compare October 8, 2020 21:27
@averikitsch
Copy link
Contributor Author

@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 retry.sh utility to check for the resource before deleting and retrying if the deleting fails.

- '-c'
- |
. /workspace/test/retry.sh
retry "gcloud secrets describe ${_SERVICE}-secrets" \
Copy link
Collaborator

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.

args:
- '-c'
- |
gcloud run deploy ${_SERVICE} \
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

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');
Copy link
Collaborator

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.


const url = execSync(
`gcloud run services describe ${SERVICE_NAME} --project=${GOOGLE_CLOUD_PROJECT} ` +
`--platform=managed --region=us-central1 --format='value(status.url)'`);
Copy link
Collaborator

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.

const uuid = require('short-uuid');
const {execSync} = require('child_process');

describe('System Tests', () => {
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator

@grayside grayside left a 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.

Comment on lines 87 to 92
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)
Copy link
Collaborator

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.

// Save the data to the database.
try {
await insertVote(vote);
logger.info({message: 'vote_inserted', vote, traceId: req.traceId})
Copy link
Collaborator

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.

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
Copy link
Collaborator

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.

@grayside
Copy link
Collaborator

I wonder if this should do a knex.destroy() on sigterm.

@averikitsch
Copy link
Contributor Author

Tests failing are unrelated. @fhinkel @grayside can you merge this?

@JustinBeckwith JustinBeckwith merged commit edae294 into master Oct 21, 2020
@fhinkel fhinkel deleted the cats-v-dogs branch November 5, 2020 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes This human has signed the Contributor License Agreement. samples Issues that are directly related to samples.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants