A JBoss Project
Red Hat

Latest posts

A couple weeks ago, I started prototyping how we could enable building PRs submitted against the JBoss Tools projects, in order to more easily create installable update sites (Eclipse p2 repositories) from pull requests. This is part of our new thrust to provide more continuous integration and deployment, to better be able to release software faster.

Purpose

Verify a commit before pushing it to master. Continuous feedback. Easier installation testing. Ability to share a proposed change, including the whole built update site so peer reviews can be done against binaries as well as sources.

Job Config

Here’s how to configure a job to use the Github Pull Request Builder Plugin:

  1. add a sha1 parameter

    <hudson.model.StringParameterDefinition>
      <name>${sha1}</name>
      <description/>
      <defaultValue>master</defaultValue>
    </hudson.model.StringParameterDefinition>
  2. pull from git using this remote config:

    <name>origin</name>
    <refspec>+refs/heads/*:refs/remotes/origin/* +refs/pull/*:refs/remotes/origin/pr/*</refspec>
  3. pull from git using this branch:

    ${sha1}
  4. enable Github Pull Request Trigger

    <org.jenkinsci.plugins.ghprb.GhprbTrigger plugin="ghprb@1.20.1">
      <spec>H/5 * * * *</spec>
      <adminlist>nickboldt</adminlist>
      <allowMembersOfWhitelistedOrgsAsAdmin>false</allowMembersOfWhitelistedOrgsAsAdmin>
      <orgslist>jbosstools</orgslist>
      <cron>H/5 * * * *</cron>
      <triggerPhrase/>
      <onlyTriggerPhrase>false</onlyTriggerPhrase>
      <useGitHubHooks>false</useGitHubHooks>
      <permitAll>false</permitAll>
      <commentFilePath/>
      <whitelist>nickboldt</whitelist>
      <autoCloseFailedPullRequests>false</autoCloseFailedPullRequests>
      <displayBuildErrorsOnDownstreamBuilds>false</displayBuildErrorsOnDownstreamBuilds>
      <whiteListTargetBranches>
        <org.jenkinsci.plugins.ghprb.GhprbBranch>
          <branch/>
        </org.jenkinsci.plugins.ghprb.GhprbBranch>
      </whiteListTargetBranches>
      <msgSuccess/>
      <msgFailure/>
      <commitStatusContext/>
      <project>jbosstools-build-sites.aggregate.child-sites__pull-request_master</project>
    </org.jenkinsci.plugins.ghprb.GhprbTrigger>

Job Steps & Deployment

One way to react to a successful build of a PR is to simply deploy to a different URL than normal builds.

For example, a job could be set up such that if ${ghprbPullId} is defined, a deploy-pr profile is used; if not, the usual deploy-to-jboss.org profile could instead be used.

mvn deploy -Pdeploy-pr

However, we might also want a different sequence of build steps in a job. Normally, we orchestrate jobs to build, deploy, & test. But for a PR build, we might instead want to sequence the steps as build+test, and only deploy if successful.

So perhaps instead of parameterizing the job to publish to snapshots/pulls/ or snapshots/builds/, we might instead parameterize the maven lifecycle steps:

if [[ ! ${ghprbPullId} ]]; then
    mvnStep1="clean install -DskipTests" # build without tests
    mvnStep2="deploy -Pdeploy-to-jboss.org" # deploy if p2diff or SHA check shows difference into /builds/ folder
    mvnStep3="verify" # run tests & fail job if problems found
else
    mvnStep1="clean deploy -Pdeploy-pr" # build and test, then deploy to /pulls/ folder if successful or fail if tests fail
    mvnStep2="NONE"
    mvnStep3="NONE"
fi

Current experiment is here (sorry, VPN required):

Questions / TODOs

  • Can whitelists be set up programmatically? (git committerIDs which can trigger a build automatically)

  • Can admins be set up programmatically? (git committerIDs which can approve a PR to be built, rather than ANY submitted PR, to prevent malicious attacks)

  • How do we roll up a low-level project’s pull request build into a larger stack of projects or products? Do we rebuild everything that’s downstream? Or just the aggregates/product?

  • How aggressively should we purge pull request builds?

  • When running matrix jobs, what happens when one part of the job is running, another is waiting, and a force-push updated to a PR arrives? (Answer: the waiting configurations will fail because the expected SHA no longer exists, having been force-replaced.)

The second Beta of JBoss Tools 4.3.1 and JBoss Developer Studio 9.1.0 for our maintenance Mars release is available.

jbosstools jbdevstudio blog header
Remember that since JBoss Tools 4.3.0 we require Java 8 for installing and using of JBoss Tools. We still support developing and running applications using older Java runtimes. See more in Beta1 blog.

What is New?

Full info is at this page. Some highlights are below.

Eclipse Mars.2

JBoss Tools and JBoss Developer Studio are now targeting the latest Eclipse Mars.2 as a running platform with many issues fixed comparing to the previous Mars.1 release.

OpenShift 3

More than 60 issues targeting OpenShift 3 support have been fixed in this release. The OpenShift 3 integration was introduced as a technology preview feature in JBDS 9.0.0.GA but will graduate to a supported feature in the upcoming JBDS 9.1.0.GA release.

Incremental publishing

The OpenShift 3 server adapter now respects the auto-publish settings as declared in the server editor, giving the user the option to automatically publish on workspace changes, build events, or only when the user requests it. The server adapter is also able to incrementally deploy the server’s associated project with a quick call to rsync, ensuring minimal over-the-wire transfers and a fast turnaround for testing your project.

Support for Java EE projects

Experimental support for Java EE projects (Web and EAR) is now available. When the workspace project associated with the OpenShift 3 server is a Dynamic or Enterprise Application project, the server adapter builds an exploded version of the archive to a temporary local directory and replaces the version deployed on the remote OpenShift pod. That Pod Deployment Path, is now inferred automatically from the image stream tags on the remote Pod. A .dodeploy marker file is created for the remote server to redeploy the module if necessary (for EAP/WildFly servers supporting it).

Support for LiveReload

The new tooling includes LiveReload support for OpenShift 3 server adapters. This is accessible from the Show In > Web Browser via LiveReload Server menu. When a file is published to the server adapter, the Browser connected to the LiveReload server instance will automatically refresh.

openshift3-livereload-menu

This is particularly effective in conjunction with the Auto Publish mode for the OpenShift 3 server adapters, as all it takes to reload a web resource is saving the file under edition (Ctrl+S, or Cmd+S on Mac).

Simplified OpenShift Explorer view

Previously, the OpenShift 3 resources representation exposed a large amount of unnecessary information about OpenShift. The explorer view is now simplified and specific (and made much more robust) and focuses on an application-centric view.

simplified-openshift3-view

Everything that is no longer displayed directly under the OpenShift Explorer is accessible in the Properties view.

Red Hat Container Development Kit server adapter

The Red Hat Container Development Kit (CDK) server adapter now provides menus to quickly access the Docker Explorer and the OpenShift Explorer. Right-click on a running CDK server adapter and select an option in the Show In menu:

cdk-server-show-in-menus

Forge Tools

Forge Runtime updated to 3.0.0.Beta3

The included Forge runtime is now 3.0.0.Beta3. Read the official announcement here.

Stack support

Forge now supports choosing a technology stack when creating a project:

stack-new-project

In addition to setting up your project, choosing a stack automatically hides some input fields in the existing wizards, such as the JPA Version in the JPA: Setup wizard:

What is Next

We are approaching the final release for our first maintenance update for Eclipse Mars.2. It’s time to polish things up and prepare a release candidate.

Enjoy!

Alexey Kazakov

Looking for older posts ? See the Archived entries.
back to top