Skip to content

Latest commit

 

History

History
141 lines (96 loc) · 5.61 KB

README.adoc

File metadata and controls

141 lines (96 loc) · 5.61 KB
Raw

Build Status

This tool is intended to allow managing GitHub Contributor License Agreements.

Setup

Below are the steps that are necessary to set this project up.

Register a new OAuth application with GitHub

This application uses OAuth to access GitHub’s APIs. The first step is to Register a new OAuth application with GitHub.

Example values for the form might be:

  • Application Name - Pivotal CLA

  • Homepage URL - https://pivotal.io

  • Application description - Allows managing Contributor License Agreements for contributions to Pivotal sponsored projects

  • Authorization callback URL - This needs to point back to your application’s OAuth endpoint. For development it might be http://localhost:8080/login/oauth2/github If you are needing to test receiving GitHub events, you will probably want to setup ngrok. If you are using ngrok, the URL would look something like https://123456.ngrok.io/login/oauth2/github

After clicking Register application you should make the application aware of the Client ID and the Client Secret.

Create a new file named application-local.properties

src/main/resources/application-local.properties
# Replace values from registered application at https://github.com/settings/developers
# See the README for additional detail
security.oauth2.main.clientId=Value from Client ID
security.oauth2.main.clientSecret=Value from Client Secret

Register a personal access token

  • Generate a [New personal access token](https://github.com/settings/tokens/new) that contains only public_repo scope. This will be used for adding comments to pull requests that require the contributor to sign the CLA.

  • Copy the personal access token and place it in application-local.properties

Modify application-local.properties

src/main/resources/application-local.properties
# Replace values from registered application at https://github.com/settings/developers
# See the README for additional detail
security.oauth2.main.clientId=Value from Client ID
security.oauth2.main.clientSecret=Value from Client Secret
security.oauth2.pivotal-cla.tokenSecret=A Personal Access Token with public_repo scope

Setup ngrok

If you are needing to test receiving GitHub events, you will probably want to setup ngrok. If there is no need to test reciving the GitHub events from GitHub, then you can skip this step.

Running the Application

Gradle

You can run the application using:

$ ./gradlew bootRun

This mode enables the local profile which uses H2 for the in-memory database and Redis for storing sessions. Redis must be started locally on port 6379.

Open the Application

You can open the application at a context root of "/". If you are running, the default URL is at http://localhost:8080/

Cloud Foundry

Deploying the application to Cloud Foundry can be performed as part of the build using the [Cloud Foundry Gradle plugin](http://docs.run.pivotal.io/buildpacks/java/build-tool-int.html#gradle). It’s set up for TravisCI and manual deployment mode.

Required Properties

Deployment scripts for pivotal-cla require a set of properties to be deployed. Please keep in mind that secrets should not get published.

  • cfUsername: Your username to log into Pivotal Cloud Foundry

  • cfPassword: Your password to log into Pivotal Cloud Foundry

  • security.oauth2.main.clientId: Github Client ID

  • security.oauth2.main.clientSecret: Github Client Secret

  • security.oauth2.pivotal-cla.tokenSecret: A Personal Access Token with public_repo scope

  • For manual deployment only: space: Name of the space

Variants (aka. Blue/Green-Deployment)

Production and Staging have blue/green deployment set up. That’s done by setting the variants property of the [Cloud Foundry Gradle plugin](http://docs.run.pivotal.io/buildpacks/java/build-tool-int.html#gradle). Setting variants causes cfDeploy to check which variant is active and deploy to the inactive variant. The deployment task switches blue/green instances using cfSwapDeployed once the application is deployed and started.

To recover from a failed swapping or deployment, it’s required to unmap application routes and re-trigger deployment.

TravisCI

TravisCI builds for the master branch get deployed to production. Builds for branches starting with staging- get deployed to the staging space. The build is set up to provide deployment properties as environment variables:

  • CF_USERNAME

  • CF_PASSWORD

  • CLIENT_ID

  • CLIENT_SECRET

  • TOKEN_SECRET

Manual Deployment with Gradle

Manual deployment with Gradle can be performed by invoking Gradle directly from the command line:

$ ./gradlew assemble deploy -Pspace=<space>

The manual deployment with Gradle defaults to pivotal as organization and requires space to be provided. It activates the cloudfoundry profile which requires a MySQL database and a Redis instance.

Manual Deployment with cf push

You can deploy pivotal-cla using cf push. This mode is isolated from any organization and space preferences.

$ cf push -p build/libs/pivotal-cla-<version>.jar

Profiles

pivotal-cla uses two profiles to distinguish between running modes:

  • local (enabled by default): Use a H2 in-memory database

  • cloudfoundry: Use a MySQL database, Spring Session and Spring Data Redis. All connectors are obtained using Spring Cloud.