Skip to content
This repository was archived by the owner on Jun 21, 2020. It is now read-only.

Bash: Continous Deliever with Jenkins

Jump to bottom
Scot P. Floess edited this page Dec 10, 2017 · 6 revisions

Jenkins

Configuration

We use Jenkins as part of our Continuous Delivery initiative. There is a "gotcha" you need to recognize: Jenkins not only builds and manages versioned files (like pom.xml or a spec file), but it also publishes those changes back to a remote Git repository. Therefore, when building, you need to instruct Jenkins to exclude changes from itself. If you do not, it will rev, build, commit, checkin...repeat - over and over again. To avoid this, configure Jenkins as follows:

  • Install the Git Plugin if not already installed.
  • Click on the Jenkins link (upper left), then "Manage Jenkins" and "Configure System."
  • Navigate to the "Git plugin" section and provide values for "Global Config user.name Value" and "Global Config user.email Value." We opted to name our user name "jenkins."
  • Click the "Save" button.
  • For your Jenkins job, choose it and click "configure."
    • Navigate down to the "Source Code Management" section for Git.
    • Add two "Additional Behaviour" options:
      • "Checkout to a specific local branch." For most cases use "master" as the branch name.
      • "Polling ignores commits from certain users." For the "Excluded Users" enter the name of the Jenkins user you configured above for "Global Config user.name Value."
    • Click the "Save" button.

FlossWare Scripts Job

We presently do not yet have the capability to RPM-ify our scripts (this will be resolved in Issue #30). However, in OpenShift, we won't be able to install any RPM we generate and have to, instead, have a Jenkins job that monitors our Scripts Git Repo for changes to the master branch. Our job is entitled Flossware-scripts and it can be utilized by other jobs refering to the scripts in the form of $WORKSPACE/../FlossWare-scripts/bash. Below you will see how we execute the FlossWare Scripts.

Additionally, you may want to consider installing the Build Blocker Plugin and block any of your jobs from building if a build of FlossWare Scripts is executing. Please note, a build of FlossWare Scripts may be misleading - we simply need the job to update (aka checkout the latest) when there are changes to the scripts.

OpenShift

If you use a Git hosting service such as GitHub, the Jenkins ~/.ssh directory is inaccessible as it's owned by root. If you want Jenkins to affect change to your versioning files (pom.xml or spec file), you will need a way to provide an SSH key so commits can be automatically propogated back. Presently we are defaulting to an SSH directory at ${HOME}/app-root/runtime/.ssh. Additionally, we've provided the script bash/openshift/openshift-keygen.sh that can create the aforementioned directory and setup a passwordless SSH key. You can then add the public key ${HOME}/app-root/runtime/.ssh/id_rsa.pub to your Git hosting service.

The OpenShift script bash/openshift/openshift-push-to-gitrepo.sh will ensure that the ${HOME}/app-root/runtime/.ssh/id_rsa.pub is used.

Bintray

Below we denote examples that indirectly call out to Bintray to publish artifacts. Two notable examples are:

These two scripts reside with the other Bintray scripts and honor the same command line parameters. More information can be found below in the Bintray section.

Maven

Pre Build

For a pom.xml, versioning increments the third digit of an assumed three digit versioning scheme as denoted in the version element (namely incrementing Release): Major.Minor.Release. As an exmaple:

  <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<groupId>org.flossware</groupId>
	<artifactId>scripts-test-maven</artifactId>
	<version>1.0.3</version>

The next version will be 1.0.4 as seen below:

  <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<groupId>org.flossware</groupId>
	<artifactId>scripts-test-maven</artifactId>
	<version>1.0.4</version>

Add an "Execute Shell" command before any Maven invocation line as follows:

cd $WORKSPACE &&
$WORKSPACE/../FlossWare-scripts/bash/continuous-delivery/prepare-maven-git-release.sh

Post Build

After your Maven invocation line (something akin to "Invoke top-level Maven targets" within the "Build" section of your job), you will want to have an "Execute Shell" command like:

cd $WORKSPACE &&
$WORKSPACE/../FlossWare-scripts/bash/openshift/openshift-push-to-gitrepo.sh

Should you use an artifact hosting service such as Bintray, you will want to do something similar to the following:

cd $WORKSPACE &&
$WORKSPACE/../FlossWare-scripts/bash/openshift/openshift-push-to-gitrepo.sh &&
$WORKSPACE/../FlossWare-scripts/bash/bintray/maven-publish.sh --bintrayUser someUser --bintrayKey abcdefghijklmnopqrstuvwxyz0123456789ABCD --bintrayAccount someAccount --bintrayPackage somePackage

The line $WORKSPACE/../FlossWare-scripts/bash/openshift/openshift-push-to-gitrepo.sh will commit and tag your pom.xml and push it out to either GitHub or Bitbucket.

Please note, supply the appropriate values to the maven-publish.sh script based upon your account - see the Bintray section below for more information.

RPM

Pre Build

For a spec file, versioning increments the Release section of the file (as in Release: xyz). As an example:

Summary: A set of scripts to help aid in Salesforce.com development and deployment
Name: flosswareScriptsTest
Version: 1.0
Release: 1

The next release will be 2, as can be seen below:

Summary: A set of scripts to help aid in Salesforce.com development and deployment
Name: flosswareScriptsTest
Version: 1.0
Release: 2

Add an "Execute Shell" command before any statements you use to build your RPM as follows:

cd $WORKSPACE &&
$WORKSPACE/../FlossWare-scripts/bash/continuous-delivery/prepare-rpm-git-release.sh /path/to/your/file.spec

Post Build

After your RPM building invocation line, you will want to have an "Execute Shell" command like:

cd $WORKSPACE &&
$WORKSPACE/../FlossWare-scripts/bash/openshift/openshift-push-to-gitrepo.sh

Should you use an artifact hosting service such as Bintray, you will want to do something similar to the following:

cd $WORKSPACE &&
$WORKSPACE/../FlossWare-scripts/bash/openshift/openshift-push-to-gitrepo.sh &&
$WORKSPACE/../FlossWare-scripts/bash/bintray/rpm-publish.sh --bintrayUser someUser --bintrayKey abcdefghijklmnopqrstuvwxyz0123456789ABCD --bintrayAccount someAccount --bintrayRepo someRepo --bintrayPackage somePackage --bintrayFile /path/to/the.rpm --bintrayContext /path/to/the.specFile

The line $WORKSPACE/../FlossWare-scripts/bash/openshift/openshift-push-to-gitrepo.sh will commit and tag your spec file and push it out to either GitHub or Bitbucket. The tag is generated from the spec file (using the Version dash Release) and a comment is added to Git. Additionally, git commit messages since the last tag will be included in the %changelog section.

As an example:

%changelog
* Mon Dec 29 2014 OpenShift <jenkins@jenkins-camponotus.rhcloud.com> 1.0-2
- Fixed the null pointer.
* Sun Dec 28 2014 OpenShift <jenkins@jenkins-camponotus.rhcloud.com> 1.0-1
- Broke the build.

Please note, supply the appropriate values to the rpm-publish.sh script based upon your Bintray account - see the Bintray section below for more information.

All in One Build

You can just lump everything together to pre build, create the rpm and publish like so (using the above as an example):

cd $WORKSPACE &&
$WORKSPACE/../FlossWare-scripts/bash/continuous-delivery/prepare-rpm-git-release.sh /path/to/your/file.spec &&
$WORKSPACE/someScriptToCreateYourRpm.sh &&
$WORKSPACE/../FlossWare-scripts/bash/openshift/openshift-push-to-gitrepo.sh &&
$WORKSPACE/../FlossWare-scripts/bash/bintray/rpm-publish.sh --bintrayUser someUser --bintrayKey abcdefghijklmnopqrstuvwxyz0123456789ABCD --bintrayAccount someAccount --bintrayRepo someRepo --bintrayPackage somePackage --bintrayFile /path/to/the.rpm --bintrayContext /path/to/the.specFile
Clone this wiki locally