Merge pull request #83 from stewartbryson/stewart

README.md

Author: stewartbryson

src/markdown/README.md

@@ -39,7 +39,7 @@ recreated if its signature changed.
 I wanted an experience using Snowflake that is as natural to developers using IntelliJ or VS Code for standard Java
 projects.
 
-# The Snowflake Plugin
+# The Gradle Snowflake Plugin
 
 This plugin provides easy configuration options for those getting started with Gradle but also provides advanced
 features for teams already using Gradle in other areas of the organization.
@@ -146,9 +146,9 @@ It first loads all the default values, and replaces any values from the connecti
 Unfortunately, it doesn't yet look for a config file in all the places that SnowSQL does.
 Instead, it looks in this order:
 
-1. `<HOME_DIR>/.snowsql/config`
-2. `./snow-config` (Useful in CI/CD pipelines, where secrets can be easily written to this file.)
-3. A custom location of your choosing, configured with the `--snow-config` option in applicable tasks.
+1. A custom location of your choosing, configured with the `--snow-config` option in applicable tasks.
+2. `<HOME_DIR>/.snowsql/config`
+3. ./snow-config` (Useful in CI/CD pipelines, where secrets can be easily written to this file.)
 
 The nested 
 [`applications` DSL](https://s3.amazonaws.com/stewartbryson.docs/gradle-snowflake/latest/io/github/stewartbryson/ApplicationContainer.html)
@@ -327,7 +327,7 @@ functionalTest(JvmTestSuite) {
 I'll walk through a few of these points.
 So that the `SnowflakeSpec` is available in the test classpath, we have to declare the plugin as a dependency
 to the test suite.
-Notice that we use the library standard maven coordinates, which are different than the coordinates in the `plugin` DSL.
+Notice that we use the library maven coordinates, which are different from the coordinates in the `plugin` DSL.
 Additionally, our test specs are unaware of all the configurations of our Gradle build, so we have to pass our `connection`
 property as a Java system property to the `SnowflakeSpec` class.
 
@@ -416,6 +416,9 @@ The plugin is aware when it is running in CI/CD environments and currently suppo
 * [GitHub Actions](https://github.com/features/actions)
 * [Appveyor](https://www.appveyor.com)
 
+Because the plugin is aware when executing in CICD environments, we expose that information through the DSL, 
+and can use it to control our cloning behavior.
+
 Our build file change to enable ephemeral testing:
 ```groovy
 snowflake {
@@ -437,6 +440,7 @@ The `useEphemeral` property will determine whether the `createEphemeral` and `dr
 are added at the beginning and end of the build, respectively.
 This allows for the `functionalTest` task to be run in the ephemeral clone just after our application is published.
 We've also added a little extra magic to keep the clone when building a pull request.
+The `createEphemeral` task issues a `CREATE DATABASE... IF NOT EXISTS` statement, so it exists from a prior run.
 Remember that our `SnowflakeSpec` class doesn't automatically know the details of our build, so we have to provide
 the ephemeral name using java system properties. Here is our modified testing suite:
 
@@ -502,7 +506,7 @@ BUILD SUCCESSFUL in 6s
 ```
 
 When the CI/CD environment is detected, the plugin will name the ephemeral database clone based on the pull request
-number, the branch name, or the tag name instead of the auto-generated name based on Gradle project.
+number, the branch name, or the tag name instead of an autogenerated one.
 If we prefer to simply specify a clone name instead of relying on the plugin to generate it, that is supported as well:
 
  ```groovy
@@ -545,7 +549,7 @@ BUILD SUCCESSFUL in 7s
 13 actionable tasks: 4 executed, 9 up-to-date
 ```
 
-# Auto-configuration of `maven-publish` with External Stages
+# Autoconfiguration of `maven-publish` with External Stages
 This option is useful when you want your artifacts available to consumers other than just Snowflake without publishing
 them to disparate locations.
 Gradle has [built-in support](https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:s3-repositories)
@@ -666,11 +670,11 @@ the plugin will ensure it matches the metadata for the `stage` property.
 the `CREATE OR REPLACE...` statement.
 
 # Contributing
-Anyone can contribute!
+Anyone can contribute! You don't need permission, my blessing, or expertise, clearly.
 To make changes to the `README.md` file, please make them in the [master README file](src/markdown/README.md) instead.
 The version tokens in this file are automatically replaced with the current value before publishing.
 
-Three different unit test tasks are defined:
+Three different testing tasks are defined:
 ```
 ❯ ./gradlew tasks --group verification
 
@@ -698,9 +702,9 @@ BUILD SUCCESSFUL in 1s
 The `functionalTest` task contains all the tests that actually make a connection to Snowflake and test a deployment,
 except those involved with external stages.
 You need to add a connection in `~/.snowsql/config` called `gradle_plugin`.
-> WARNING: Ensure that the credential you provide below are for a safe development database.
+> WARNING: Ensure that the credentials you provide in `gradle_plugin` are safe for development purposes.
 
-The `integrationTest` requires the following external stages to exist in your Snowflake account:
+The `integrationTest` task requires the following external stages to exist in your Snowflake account:
 
 * `gcs_maven`: An external stage in GCS.
 * `s3_maven`: An external stage in S3.