Cloud Tools for Eclipse Release Instructions

Currently, we follow a fairly manual process. We want to automate this and make it more robust.

1. Update the version number in these three files:

   • features/com.google.cloud.tools.eclipse.suite.e45.feature/pom.xml
   • features/com.google.cloud.tools.eclipse.suite.e45.feature/feature.xml
   • gcp-repo/metadata.product

   Commit/push/review/merge. See #1565 for an example of the necessary changes.

2. Tag the release in github. This is just for source code. We don't publish the binaries or update site from Github. The tag name should be something like v1.0.1A. If we've had to do this multiple times before releasing we go v1.0.1B, v1.0.1C, and so forth.

3. In your local client, checkout the master branch: git checkout master

4. Sync with origin/master: git pull

5. Checkout the tag: git checkout <tag>.

6. Use git status to verify there are no local changes. Make sure you see "nothing to commit, working directory clean".

7. Build the binary with

    mvn -Doauth.client.id=<OAuth client ID> \
        -Doauth.client.secret=<OAuth client secret> \
        -Dga.tracking.id=<Analytics tracking ID> \
        clean install
   

   • Close any open Eclipse instance in case its auto-build interferes with the Maven build.
   • Builds are much faster and less flaky on Linux than other platforms.
   • For the details about the system properties above, see Section Compile Time Constant Injection.

8. Run gcloud auth login in a terminal and login with your google.com credential.

9. gcloud config set project google.com:gcloud-for-eclipse-testing

10. Delete everything in the gcloud-for-eclipse-testing bucket.

    gsutil -m rm gs://gcloud-for-eclipse-testing/**
    

11. With gsutil upload the following files and folders you just built into the gcloud-for-eclipse-testing bucket in the the gcloud-for-eclipse-testing project:

    gsutil cp gcp-repo/metadata.product gs://gcloud-for-eclipse-testing
    gsutil cp gcp-repo/metadata.p2.inf gs://gcloud-for-eclipse-testing
    gsutil cp gcp-repo/target/repository/index.html gs://gcloud-for-eclipse-testing
    gsutil cp gcp-repo/target/repository/artifacts.jar gs://gcloud-for-eclipse-testing
    gsutil cp gcp-repo/target/repository/content.jar gs://gcloud-for-eclipse-testing
    gsutil -m cp -r gcp-repo/target/repository/features gs://gcloud-for-eclipse-testing
    gsutil -m cp -r gcp-repo/target/repository/plugins gs://gcloud-for-eclipse-testing
    

12. (Optional) If you want to send out a testing link before signing the binaries you can share these files publicly and send the public link to trusted testers or team members.

    gsutil -m acl ch -r -u AllUsers:R gs://gcloud-for-eclipse-testing 
    

13. Grant kokoro read permissions to your newly uploaded files:

    gsutil -m acl ch -r -u [email protected]:READ gs://gcloud-for-eclipse-testing
    

14. Run kokoro "Build with parameters" on the google-cloud-eclipse project using your release branch.

15. Wait for kokoro to complete successfully. Note that depending on how overloaded kokoro servers are, this may take several hours. The build doesn't really take that long, but the resources are oversubscribed so at peak times it takes a while before kokoro starts our job.

16. Run release/release_after_kokoro.sh. (You need to set $ECLIPSE_HOME to your local Eclipse installation directory to run it.)

    • When asked to enter the Kokoro GCS bucket URL, copy and paste the URL of the GCS bucket link found on the Kokoro build page.
    • For the details about what the script does, consult the section Steps Covered by release/release_after_kokoro.sh.

17. Verify that you can install the plugin into Eclipse from the public link. This looks like https://storage.googleapis.com/cloud-tools-for-eclipse/*version*/. Links that begin with https://storage.cloud.google.com/ do not work.

18. Update Lorry.

19. Search for "google-cloud-eclipse".

20. Clone the approved version of the link.

    • If it's a beta release, update the /eclipse/google-cloud-eclipse/beta URL to point to the new version.
    • If it's a stable release, update the /eclipse/google-cloud-eclipse/stable URL to point to the new version.

21. Update the target in the cloned entry.

22. Send the direct URL of the update site and the URL of the newly created Lorry entry to the teammate who will follow the qualification process. Assuming no serious bugs are uncovered during testing, this teammate should approve the Lorry entry.

23. Find a version of Eclipse with the old version installed and Help > Check for Updates to verify the new version is found.

24. Make sure you can install from the update site into a clean instance of Eclipse.