Skip to content

Commit a327c64

Browse files
mziccardmziccard
authored
Merge pull request #1054 from mziccard/pubsub-into-logging
Merge pubsub branch into logging
2 parents eb7f9b9 + 91d320a commit a327c64

File tree

602 files changed

+84087
-12609
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

602 files changed

+84087
-12609
lines changed

‎.travis.yml‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ before_install:
99
- cp target/travis/settings.xml ~/.m2/settings.xml
1010
install: mvn install -DskipTests=true -Dgpg.skip=true
1111
script:
12-
- utilities/verify.sh
12+
- travis_wait 30 utilities/verify.sh
1313
after_success:
1414
- utilities/after_success.sh
1515
env:

‎CONTRIBUTING.md‎

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -2,9 +2,9 @@ Contributing
22
============
33

44
1. **Please sign one of the contributor license agreements below.**
5-
1. Fork the repo, develop and test your code changes, add docs.
6-
1. Make sure that your commit messages clearly describe the changes.
7-
1. Send a pull request.
5+
2. Fork the repo, develop and test your code changes, add docs.
6+
3. Make sure that your commit messages clearly describe the changes.
7+
4. Send a pull request.
88

99

1010
Here are some guidelines for hacking on gcloud-java.
@@ -32,6 +32,8 @@ When changes are made to authentication and project ID-related code, authenticat
3232

3333
Known issue: If you have installed the Google Cloud SDK, be sure to log in (using `gcloud auth login`) before running tests. Though the Datastore tests use a local Datastore emulator that doesn't require authentication, they will not run if you have the Google Cloud SDK installed but aren't authenticated.
3434

35+
**Please, do not use your production projects for executing integration tests.** While we do our best to make our tests independent of your project's state and content, they do perform create, modify and deletes, and you do not want to have your production data accidentally modified.
36+
3537
Adding Features
3638
---------------
3739
In order to add a feature to gcloud-java:
@@ -41,6 +43,9 @@ The feature must work fully on Java 7 and above.
4143
The feature must not add unnecessary dependencies (where "unnecessary" is of course subjective,
4244
but new dependencies should be discussed).
4345

46+
Adding Support for a New Service
47+
--------------------------------
48+
See [SUPPORTING_NEW_SERVICES](./SUPPORTING_NEW_SERVICES.md) for guidelines on how to add support for a new Google Cloud service to `gcloud-java`.
4449

4550
Coding Style
4651
------------

‎README.md‎

Lines changed: 226 additions & 67 deletions
Large diffs are not rendered by default.

‎RELEASING.md‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -7,10 +7,10 @@ Most of the release process is handled by the `after_success.sh` script, trigger
77
1. Run `utilities/update_pom_version.sh` from the repository's base directory.
88
This script takes an optional argument denoting the new version. By default, if the current version is X.Y.Z-SNAPSHOT, the script will update the version in all the pom.xml files to X.Y.Z. If desired, another version can be supplied via command line argument instead.
99

10-
2. Create a PR to update the pom.xml version.
11-
The PR should look something like [#225](https://github.com/GoogleCloudPlatform/gcloud-java/pull/225). After this PR is merged into GoogleCloudPlatform/gcloud-java, Travis CI will push a new website to GoogleCloudPlatform/gh-pages, push a new artifact to the Maven Central Repository, and update versions in the README files.
10+
2. Create a PR to update the pom.xml version. If releasing a new client library, this PR should also update javadoc grouping in the base directory's [pom.xml](./pom.xml).
11+
PRs that don't release new modules should look something like [#225](https://github.com/GoogleCloudPlatform/gcloud-java/pull/225). PRs that do release a new module should also add the appropriate packages to the javadoc groups "SPI" and "Test helpers", as shown in [#802](https://github.com/GoogleCloudPlatform/gcloud-java/pull/802) for `gcloud-java-dns`. After this PR is merged into GoogleCloudPlatform/gcloud-java, Travis CI will push a new website to GoogleCloudPlatform/gh-pages, push a new artifact to the Maven Central Repository, and update versions in the README files. Do not merge in any non-release-related pull requests between the start of step 2 and the end of step 6. Between these steps, the project version is a non-snapshot version, so any commits to the master branch will cause Travis to spend extra resources attempting to redeploy artifacts.
1212

13-
3. Before moving on, verify that the artifacts have successfully been pushed to the Maven Central Repository. Open Travis CI, click the ["Build History" tab](https://travis-ci.org/GoogleCloudPlatform/gcloud-java/builds), and open the second build's logs for Step 2's PR. Be sure that you are not opening the "Pull Request" build logs. When the build finishes, scroll to the end of the log and verify that the artifacts were successfully staged and deployed. You can also search for `gcloud-java` on the [Sonatype website](https://oss.sonatype.org/#nexus-search;quick~gcloud-java) and check the latest version number. If the deployment didn't succeed because of a flaky test, rerun the build.
13+
3. Before moving on, verify that the artifacts have successfully been pushed to the Maven Central Repository. Open Travis CI, click the ["Build History" tab](https://travis-ci.org/GoogleCloudPlatform/gcloud-java/builds), and open the second build's logs for Step 2's PR. Be sure that you are not opening the "Pull Request" build logs. When the build finishes, scroll to the end of the log and verify that the artifacts were successfully staged and deployed. Search for `gcloud-java` on the [Sonatype website](https://oss.sonatype.org/#nexus-search;quick~gcloud-java) and check the latest version number. In rare cases (when the Maven plugin that determines the version of the repository fails), the artifacts may not be deployed even if the version in the pom.xml files doesn't contain `SNAPSHOT`. If the artifacts weren't deployed due to invalid version parsing or a flaky test, rerun the build.
1414

1515
4. Publish a release on Github manually.
1616
Go to the [releases page](https://github.com/GoogleCloudPlatform/gcloud-java/releases) and open the appropriate release draft. Make sure the "Tag Version" is `vX.Y.Z` and the "Release Title" is `X.Y.Z`, where `X.Y.Z` is the release version as listed in the `pom.xml` files. The draft should already have all changes that impact users since the previous release. To double check this, you can use the `git log` command and look through the merged master branch pull requests. Here is an example of the log command to get non-merge commits between v0.0.12 and v0.1.0:
@@ -26,7 +26,7 @@ As mentioned before, there is an optional version argument. By default, the scr
2626

2727
6. Create and merge in another PR to reflect the updated project version. For an example of what this PR should look like, see [#227](https://github.com/GoogleCloudPlatform/gcloud-java/pull/227).
2828

29-
7. Be sure to update App Engine documentation and [java-docs-samples](https://github.com/GoogleCloudPlatform/java-docs-samples) code as necessary. See directions [here](https://docs.google.com/a/google.com/document/d/1SS3xNn2v0qW7EadGUPBUAPIQAH5VY6WSFmT17ZjjUVE/edit?usp=sharing).
29+
7. Be sure to update Google Cloud Platform docs, [java-docs-samples](https://github.com/GoogleCloudPlatform/java-docs-samples) code/docs, and [getting-started-java](https://github.com/GoogleCloudPlatform/getting-started-java) code/docs. See directions [here](https://docs.google.com/a/google.com/document/d/1SS3xNn2v0qW7EadGUPBUAPIQAH5VY6WSFmT17ZjjUVE/).
3030

3131
### To push a snapshot version
3232

0 commit comments

Comments
 (0)