Setting up Windows 2012 Jenkins slave : Part 2

This is the second update on my experiences setting up a Windows 2012 Jenkins slave, where other Jenkins instances have been Unix based.

Let me just say that Jenkins isn't as easy to setup on Windows. You probably already knew that.

As an overview, this is the high-level way we write and build code and what is needed for continuous integration:

1) Java 7 and 8
2) Eclipse or IntelliJ for writing code and running tests outside the command line or Jenkins
3) Maven 3x
4) GIT 1.8.4 on Mac, GIT (msysgit 1.9.2) on Windows
5) Jenkins master running on Linux.
6) Jenkins slave agent running as a slave app on Windows
7) Cygwin for windows

Further problems encountered setting up Jenkins on Windows 2012, besides what I detailed in prior post.

1) SH scripts for running tests need to run on Windows
2) Access denied issues when running certain files (e.g BAT)
3) CreateProcess from Jenkins cannot find files to run

The first issue above is that we use SH scripts (in Bash) to setup testing and run our tests after all other packages are built. Windows won't recognize SH scripts as runnable. I decided that since I had Cygwin installed with Bash I could launch these SH scripts from within a BAT file.

The BAT file is basically one line:

C:\cygwin64\bin\bash.exe --login "C:\jenkins\workspace\...\deployScript.sh"

I originally had it start with bash, but the process couldn't be found when done through Jenkins, since it was launched through CreateProcess. I solved my 3rd issue above by fully qualifying what process I wanted to kick off under cygwin with the full path of where bash lived, and I was done with my BAT script.

The 2nd issue above was seen in build failures inside of Jenkins runs where I would see access denied. I thought I could change permissions in the POM files where these scripts were launched but that didn't work.

Ultimately, I found that access denied with my scripts was caused by Eclipse. Eclipse wouldn't make some of the new files I created executable. I clicked on properties and updated the scripts to make them fully executable, and had no further issues.

Reverse SSH tunneling to get around corporate intranet port blocking

Have a port that is blocked between two servers you use? Let's say you use ports above 1024, for example, in the 8000-9000 range for web applications or some other proprietary application you write.

Let's also say you have a Linux instance you SSH to that needs to connect back to you own laptop or another Linux machine, but the port on your local machine cannot be accessed from the remote Linux box unless you have IT open that port, which means bugging them with a ticket.

Here's something I learned the other day.

In my scenario I needed to connect to a web application, running on my local Mac Book Pro, using port 9999 when I was connected via VPN, from a Linux Openstack instance.

Unfortunately, I couldn't connect to the port with a simple program like curl since the port was blocked.

Here are the steps so I could allow SSH to serve up that port from the remote Linux instance back to my Mac.

Detailed Steps:

You need two terminal windows on the machine you need to connect back to. I had two tabs open in the Terminal window on my Mac.

1st terminal window:

     Change this string to what port you need to open >

     ssh -R 9999:localhost:9999 -l [root or whoever you connect as]@[the virtual server you connect to]

     If you don't want to use localhost, replace with server name you want to connect back to.

     You will now be on the remote linux box

2nd terminal window:

     ssh [root or whoever you connect as]@[the virtual server you connect to]

     You will now be on the remote linux box in the 2nd terminal window.

     Try using curl to test the port that you want to connect back to >

     curl https://localhost:9999//index.html --insecure

          Again, replace localhost with whatever server name you'd like to use to connect back to.

Show In Tree: Using Artifactory to update Maven pom.xml file

I use Artifactory on a monthly basis, not as often as my daily use of Maven. I did learn something today about using Artifactory that will make my life easier when I need to add further dependencies to a POM file.

As might be known by most Maven users your repository lives under the .m2 directory. Additionally, you may have libraries in your local repository that other users don't currently have.

I made the mistake of presuming that a library was in everyone else's .m2 branch when I added some new code that relied on some less common libraries.

The build failed.

Luckily, the library was in Artifactory.

A very convenient shortcut to update my POM was to find the library in Artifactory, hover over the library, select from the pop-up "Show In Tree," copy the string and paste in the POM file.

Here's a screenshot of what I'm talking about.

Setting up a Windows 2012 Jenkins slave from a Linux Jenkins master

There are some caveats to setting up a Jenkins slave on Windows (e.g. Windows 2012) from a Linux master box.

To accommodate building on Windows 2012 from a master Jenkins server (where you may already have linux master to linux slave) I'd advise this high-level setup within the Jenkins master.

     1) Two JDKs defined in the Jenkins config: one for linux, the other for windows 2012.
     2) Two Perforces (or whatever your SCM solution is) defined under Jenkins config too: one for linux, and one for windows 2012.

Also, when you set up a JDK and Perforce in Jenkins for Windows you'll get Jenkins errors in a couple of places in the Jenkins web pages, which you'll need to disregard.

This will most likely be in the paths that will have forward slashes (/) instead of the Windows backslashes (\) to both the JDK and Perforce directories. Yes, you need to use forward slashes instead of the Windows backslashes for some of these paths.

Most likely, after these step, you'll use the JDK and SCM setups in a Maven build project.

In your Maven build project, make sure that:

     1) Your root POM for windows uses backward slashes
          a) for example: \some-directory\maven-directory\pom.xml

     2) Your archive directory also uses backward slashes

          a) for example: **\some-directory\assembly\target\archive-file*.zip

Again, you'll also encounter Jenkins error messages when setting up these two items in source code management. You can also disregard that too.

Ultimately, the best way to make sure things are working is actually run a build, look at the log and disregard some of the misplaced warnings/error messages.

Installing Apache on Ubuntu: apt-get versus doing a classic configure through make install process

We've been creating new virtual servers at work using Ubuntu snapshots on Openstack.

Most of these new instances are, unfortunately, bare bones. This is due to Openstack being new to most of us; and as our config engineers start to create more robust template snapshots - hopefully won't be as bare-bones going forward.

I was told by my manager during the initial setup that I shouldn't use apt-get for the installation of Jenkins. I was curious about that but didn't inquire at the time.

A day ago I did try using apt-get after my initial build of Apache 2.2 ran into issues when I enabled all modules.

At the initial install using apt-get I noted that the default install directory was under /etc/apache2.

Another unconventional difference was putting the port where the apache HTTP server runs into the ports.conf file under the root directory. I tried to override this by updating httpd.conf but that was not read when I restarted.

Finally I realized I had to use a2enmod command to install the rewrite module and then use the service command to restart Apache.

Ultimately, after all these quirky changes for Apache on Ubuntu, I tried to rebuild using the tar distribution I built earlier.

This time I specified all the modules that I wanted when I did configure on the command line [in addition to those supplied by default], ran make and did a make install. I was then able to start Apache and configure everything in httpd.conf under the conf directory.

Sometimes going back to the classic installation method is the best way to go.

Eclipse > Customizing the project explorer view. Not showing external libraries in your root directory

I do almost all of my automation development in Eclipse these days.

I usually import most projects through the Eclipse maven plugin, and then I can check out/in files through the Perforce plugin.

Before I build in Eclipse I usually run mvn clean install -Dmaven.test.skip=true, after I've gotten the latest changes from the depot.

The most recent time I did an mvn eclipse:eclipse -DdownloadSources=true build that reset my Eclipse project explorer view and one project I used started to show all the imported JAR files in the root directory making it bit cumbersome to use.

I was helped by a colleague to customize my view with the downward caret looking symbol to the right of the project explorer view.

Here are some screenshots:

After selecting the Customize View, scroll down to Libraries from Extenal and select the associated checkbox, then save.

This should resolve all the JARs showing in your root directory.

Finally resolved inability to change WebEx One Click Meeting Topic

When I first started using WebEx 3 years ago for my current job I accidentally set the WebEx One-click meeting topic to my colleagues' name.

When I tried to update the one click meeting topic it wasn't very intuitive and I gave up pretty quick.

I tried looking a couple of times when WebEx would launch but there didn't seem to be a way to do it in Meeting Center when you were actually in a meeting.

Finally decided to do another Google search and came up with Cornell's site:

Cornell's web site

Basically, you need to go to the WebEx Meeting Center website, which in my case is Meeting Center.

Then you click My WebEx on the top task bar in the browser winder, This will bring up a new page and on the left hand side gutter, click on Productivity Tools Setup.

When the Productivity Tools Setup page appears, there should be a 'virtual' card that appears in the middle of the screen.  Click Edit Settings on the top right of the card.

Then you'll be able to edit your meeting topic name.

Wouldn't it be easier for WebEx to have a global settings link from the Meeting Center main page instead of burying a change in settings with multiple mouse clicks?