Skip to content

Cloud Tools for Eclipse Release Instructions (old)

Jump to bottom
Chanseok Oh edited this page Apr 9, 2018 · 1 revision

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.feature/pom.xml
    • features/com.google.cloud.tools.eclipse.suite.feature/feature.xml
    • gcp-repo/metadata.product

    Commit/push/review/merge. See #3003 for an example of the necessary changes. Make sure you delete the branch after merging, both locally and remotely, to avoid potential branch/tag naming conflicts.

  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. Drop the .qualifier in gcp-repo/metadata.product (e.g., version="1.3.0.qualifier" to version="1.3.0") and use the exact release version (rationale, rationale (#2211)). Do not commit. git status should show that gcp-repo/metadata.product is the only file that changed.

  8. Build the binary with

    xvfb-run mvn -Doauth.client.id=<OAuth client ID> \
             -Doauth.client.secret=<OAuth client secret> \
             -Dga.tracking.id=<Analytics tracking ID> \
             clean verify
    • Close any open Eclipse instance in case its auto-build interferes with the Maven build.
    • Running with xvfb-run is optional but highly recommended. Without it, test Eclipse instances will pop up on the monitor during tests, and integration tests fail easily if such test Eclipse instances lose focus.
    • 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.

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

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

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

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

  12. 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

  13. (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

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

    gsutil -m acl ch -r -u kokoro-dedicated@system.gserviceaccount.com:READ gs://gcloud-for-eclipse-testing

  15. Run kokoro "Build with parameters" on the google-cloud-eclipse project using your release branch (which is the tag name you created earlier).

  16. Wait for kokoro to complete successfully. (This doesn't usually take long.)

  17. 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.

  18. 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.

  19. Update Lorry.

    1. Search for "google-cloud-eclipse".
    2. 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.
    3. Update the target in the cloned entry.
    4. Update the embargo date in the cloned entry. Generally, we only release Monday-Thursday between 10:00 AM and 3:00 PM so someone will be around if the release goes sideways.

  20. 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.

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

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

End User Documentation

Contributor Docs

Clone this wiki locally