Skip to content
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

Run cross-release SQL integration tests #403

Merged
merged 2 commits into from Dec 12, 2019

Conversation

@weiminyu
Copy link
Collaborator

weiminyu commented Dec 6, 2019

Run SQL integration tests across arbitrary schema and server
releases.

Refer to integration/README.md in this change for more information.

TESTED=Cloud build changes tested with cloud-build-local
Used the published jars to test sqlIntegration task locally.


This change is Reviewable

@weiminyu weiminyu requested review from jianglai and mindhog Dec 6, 2019
@googlebot googlebot added the cla: yes label Dec 6, 2019
Copy link
Member

mindhog left a comment

Reviewed 8 of 9 files at r1.
Reviewable status: 8 of 9 files reviewed, 6 unresolved discussions (waiting on @jianglai, @mindhog, and @weiminyu)


gradle.properties, line 25 at r1 (raw file):

dbPassword=

# Maven repository for internal use. It hosts the Cloud SQL schema jar and the

I think "internal use" may be a little confusing here (I'm confused by it). Should it be "for use by the integration testing framework" or something? More generally, how do we envision communicating how to use this to external users?


db/build.gradle, line 111 at r1 (raw file):

artifacts {
  schema schemaJar

Nit: change order to put schema after compileApi as above.


integration/README.md, line 24 at r1 (raw file):

## Usage

The ':integration:sqlIntegrationTest' task is the test runners. It uses the

*runner


integration/README.md, line 39 at r1 (raw file):

```shell
current_prod_schema=$(fetch_version_tag schema production)

The "fetch_version_tag" thing is confusing, if your intent is to convey that the user must supply a schema version, you should probably just use . If you intend that it be programmatically determined, you should say something above like "given a program fetch_version_tag that outputs the version number of the production schema". Same with has_schema_change_since_tag below (current_prod_schema needs a leading '$' BTW)


integration/README.md, line 42 at r1 (raw file):

current_prod_server=$(fetch_version_tag server production)
has_schema_change=$(has_schema_change_since_tag current_prod_schema)
has_schema_change & ./gradlew :integration:sqlIntegrationTest \

This will run the "has_schema_change{" program in the background and unconditionally run gradlew, which almost certainly isn't what you intended :-)

For clarity and correctness, you probably want this to be something like:

if $has_schema_change; then
./gradlew
fi


integration/README.md, line 77 at r1 (raw file):

the shell snippet shown earlier can be implemented as:

```shell

Similar notes as above, though it's not necessary repeat the description of the commands since you would have covered it above.

Copy link
Member

mindhog left a comment

Reviewed 1 of 9 files at r1.
Reviewable status: all files reviewed, 6 unresolved discussions (waiting on @jianglai and @weiminyu)

weiminyu added 2 commits Dec 6, 2019
Run SQL integration tests across arbitrary schema and server
releases.

Refer to integration/README.md in this change for more information.

TESTED=Cloud build changes tested with cloud-build-local
       Used the published jars to test sqlIntegration task locally.
Run SQL integration tests across arbitrary schema and server
releases.

Refer to integration/README.md in this change for more information.

TESTED=Cloud build changes tested with cloud-build-local
       Used the published jars to test sqlIntegration task locally.
@weiminyu weiminyu force-pushed the weiminyu:run-tests-in-jars branch from c50a444 to 99cd1f2 Dec 10, 2019
Copy link
Collaborator Author

weiminyu left a comment

Reviewable status: 5 of 9 files reviewed, 5 unresolved discussions (waiting on @jianglai and @mindhog)


gradle.properties, line 25 at r1 (raw file):

Previously, mindhog (Michael Muller) wrote…

I think "internal use" may be a little confusing here (I'm confused by it). Should it be "for use by the integration testing framework" or something? More generally, how do we envision communicating how to use this to external users?

Reworded


db/build.gradle, line 111 at r1 (raw file):

Previously, mindhog (Michael Muller) wrote…

Nit: change order to put schema after compileApi as above.

Done.


integration/README.md, line 24 at r1 (raw file):

Previously, mindhog (Michael Muller) wrote…

*runner

Done.


integration/README.md, line 39 at r1 (raw file):

Previously, mindhog (Michael Muller) wrote…

The "fetch_version_tag" thing is confusing, if your intent is to convey that the user must supply a schema version, you should probably just use . If you intend that it be programmatically determined, you should say something above like "given a program fetch_version_tag that outputs the version number of the production schema". Same with has_schema_change_since_tag below (current_prod_schema needs a leading '$' BTW)

Done.


integration/README.md, line 42 at r1 (raw file):

Previously, mindhog (Michael Muller) wrote…

This will run the "has_schema_change{" program in the background and unconditionally run gradlew, which almost certainly isn't what you intended :-)

For clarity and correctness, you probably want this to be something like:

if $has_schema_change; then
./gradlew
fi

Revised with actual command to check schema change.


integration/README.md, line 77 at r1 (raw file):

Previously, mindhog (Michael Muller) wrote…

Similar notes as above, though it's not necessary repeat the description of the commands since you would have covered it above.

Done.

Copy link
Member

mindhog left a comment

Reviewed 4 of 4 files at r2.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @jianglai and @mindhog)

@weiminyu weiminyu merged commit f48e393 into google:master Dec 12, 2019
6 of 7 checks passed
6 of 7 checks passed
code-review/reviewable 1 discussion left (jianglai, mindhog)
Details
LGTM analysis: JavaScript No code changes detected
Details
LGTM analysis: Python No code changes detected
Details
LGTM analysis: Java No new or fixed alerts
Details
cla/google All necessary CLAs are signed
kokoro-foss Kokoro build finished
Details
kokoro-internal Kokoro build finished
Details
@weiminyu weiminyu deleted the weiminyu:run-tests-in-jars branch Dec 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.