Skip to content

Commit

Permalink
Merge pull request #21 from sul-dlss/2-wowza-deployment-jenkins
Browse files Browse the repository at this point in the history
automated build and deploy for wowza plugin
  • Loading branch information
ndushay committed May 24, 2016
2 parents 26c9cd0 + 297ca17 commit ea27ea2
Show file tree
Hide file tree
Showing 4 changed files with 72 additions and 11 deletions.
31 changes: 21 additions & 10 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -60,22 +60,33 @@ Alternatively, you can manually edit Application.xml and then reload the Wowza a
</Property>
```

### To deploy plugin code to VM:

- (ensure Wowza application on VM has the properties above)
- (update version file)
- (tag version on github)
- (trigger jenkins build that creates versioned deployment jar artifact)
- (update puppet script to use latest version)
### To deploy a new version of the plugin code to the VM:

- Configuring a Wowza application to use the plugin is described above, and can happen independently of the plugin Jar deployment.
- Release a new (tagged) version of the plugin:
- Update `conf/version`. This should be just the version number itself, e.g. `1.7.1` or `2.0.0-beta`.
- Create a version tag and release notes:
- Create a Github release for the tag with brief notes about changes since the last release. Note: when you publish a release in Github, the tag will be created for you if it doesn't exist already.
- The git tag's version number should use the `v` prefix, e.g. `v1.7.1` or `v2.0.0-beta` (corresponding with the `conf/version` example).
- In order to use the `deploymentJar` gradle task (a la Jenkins), the git tag (e.g `v1.7.1`) must match the contents of `conf/version` (e.g. `1.7.1`) other than the leading v, present only in the git tag.
- Note: if you do choose to tag from the command line, don't forget to push tags to Github.
- Trigger the Jenkins build (`wowza-auth-plugin`) that creates the versioned .jar artifact for deployment.
- Log into Jenkins, navigate to the 'wowza-auth-plugin' project, and invoke the 'Build Now' command.
- Note:
- the Jenkins build is configured to use the master branch; the jar will have the code from the last commit to the master branch.
- the jar created will be copied to an artifacts directory on jenkins, from which puppet will get the versioned jar.
- TODO: build the jar from the tagged branch indicated in conf/version (see issue #23)
- Update puppet to deploy the specific versioned artifact to the desired VM.
- make a PR in puppet to do this, following puppet practices. (or ask your friendly devops rep to help)

### To deploy locally (e.g. on dev laptop)

- install Wowza on laptop
- create Wowza application instance
- ensure Wowza application instance has properties above
- example Application.xml file at conf/example/Application.xml
- build the jar using gradlew
- deploy jar to /your/wowza/lib
- build the jar using `./gradlew deploymentJar` or `./gradlew deploymentJarRelaxed` (the latter is needed if `conf/version` doesn't match the head commit in the current branch)
- copy jar to /your/wowza/lib
- start up Wowza

### To see Gradle tasks
Expand All @@ -87,7 +98,7 @@ Alternatively, you can manually edit Application.xml and then reload the Wowza a
./gradlew --help


## (below to be removed from README??)
## Deprecated build instructions (possibly useful for troubleshooting, eventually remove?)

### To manually compile

Expand Down
50 changes: 49 additions & 1 deletion build.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,37 @@ plugins {
id 'java'
id 'jacoco'
id 'com.github.kt3k.coveralls' version '2.6.3'
id 'org.ajoberstar.grgit' version '1.4.2'
}

version = '0.0.1'
import org.ajoberstar.grgit.Grgit
def grgit = Grgit.open(project.rootDir)

String readVersionFile() {
return new File('conf/version').text.trim()
}

boolean deployVersionMatchesGitTag(deployVersion, gitTag) {
return "v${deployVersion}" == gitTag
}

String buildArtifactVersionString(deployVersion, gitTag, gitRevisionHash) {
// the convention is that the git tag starts with "v", but the number in the file is just the number
return deployVersionMatchesGitTag(deployVersion, gitTag) ? gitTag : "v${deployVersion}-untagged-${gitRevisionHash}"
}

ext {
gitTag = grgit.describe()
gitRevisionHash = grgit.head().id
gitRevisionHashShort = grgit.head().getAbbreviatedId()
gitCommitMessage = grgit.head().shortMessage
gitCommitMessageFull = grgit.head().fullMessage
deployVersion = readVersionFile()
artifactVersionString = buildArtifactVersionString(deployVersion, gitTag, gitRevisionHashShort)
}

version = artifactVersionString

sourceCompatibility = 1.8
targetCompatibility = 1.8

Expand Down Expand Up @@ -46,3 +74,23 @@ jacocoTestReport {
}

check.dependsOn jacocoTestReport

// for an intro to writing gradle tasks: https://docs.gradle.org/current/userguide/tutorial_using_tasks.html

task deploymentJarRelaxed(type: Jar) {
manifest {
attributes("gitTag": "${gitTag}",
"gitRevisionHash": "${gitRevisionHash}",
"deployVersion": "${deployVersion}",
"artifactVersionString": "${artifactVersionString}")
}
with jar
}

task deploymentJar(type: Jar) {
doFirst {
assert deployVersionMatchesGitTag(deployVersion, gitTag) :
"deployVersion must match current git tag (or invoke deploymentJarRelaxed instead). deployVersion=${deployVersion} gitTag=${gitTag}"
}
with deploymentJarRelaxed
}
1 change: 1 addition & 0 deletions conf/version
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
0.1.0
1 change: 1 addition & 0 deletions settings.gradle
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
rootProject.name='dlss-wowza'

0 comments on commit ea27ea2

Please sign in to comment.