Upgrading Sonatype nexus from 1.5 to 1.6

Here are the steps followed while upgrading Sonatype nexus server from 1.5 to 1.6 version in Linux server (RHEL)



1) Stop the nexus service
   service nexus stop
2) Copy the nexus 1.6.0 package to previously installed directory
     cp  nexus-oss-webapp-1.6.0-bundle.tar.gz  /usr/local
3) Extract nexus 1.6.0 package in a temp directory
    cd /usr/local/temp
    tar xvf ../nexus-oss-webapp-1.6.0-bundle.tar.gz
4) Copy nexus-oss-webapp-1.6.0 directory to installation directory
     mv /usr/local/temp/nexus-oss-webapp-1.6.0 /usr/local
5) Change ownership to the Unix user account nexus was running
    chown -R nexus:nexus nexus-oss-webapp-1.6.0
6) Create a softlink to the new nexus installation source directory
     ln -s nexus-oss-webapp-1.6.0 nexus
7) There are some changes in 'nexus' script and location of wrapper.conf. Hence we need to replace the previously installed /etc/init.d/nexus script
    diff nexus/bin/jsw/linux-x86-64/nexus /etc/init.d/nexus
     mv /etc/init.d/nexus /etc/init.d/nexus.old
     cp nexus/bin/jsw/linux-x86-64/nexus /etc/init.d/nexus
8) If you have made changes in old /etc/init.d/nexus script, restore it to the new script
    The notable change is the WRAPPER_CONF location got changed in 1.6 version. Hence correct path needs to be defined in /etc/init.d/nexus script
  For example, in our setup, we made these changes in old script, which is transferred to new script
   vi nexus

      #USER DEFINED VARIABLES
      NEXUS_HOME=/usr/local/nexus
      PLATFORM="linux-x86-64"
      JAVA_HOME=/usr/local/jdk1.6.0_27
       PATH="${JAVA_HOME}/bin:$PATH"

      # Wrapper
      WRAPPER_CMD="${NEXUS_HOME}/bin/jsw/${PLATFORM}/wrapper"
      WRAPPER_CONF="${NEXUS_HOME}/bin/jsw/conf/wrapper.conf"

     # Location of the pid file.
      PIDDIR="/var/run"

      #RUN_AS_USER=
      RUN_AS_USER=nexus
9) If you have changed the nexus storage location from the default /usr/local/sonatype-work or default tcp port, then make sure you update this path in the file nexus/conf/plexus.properties
     nexus-work=/export/nexus/sonatype-work/nexus
     application-port=8081

10) Restart nexus
    service nexus start

Read More

Jira workflows - Dealing with validator

Recently I got a request to make certain fields mandatory while marking a issue as 'Fix' (A step in our workflow'). Initially I made the requested custom fields as 'Required' in Field configuration, but it screwed !!!. After this change it started asking to provide values for fields which are not visible in 'create' page.
Finally I learnt it needs to be configured in Workflows validator.
I'm sharing my learning's here.

Introduction
Workflow is the place where we define business process. A JIRA workflow is the set of steps (or statuses) and transitions that an issue goes through during its lifecycle.
The below picture represents the default Jira workflow.

JIRA workflows consist of steps and transitions:
  A step represents a workflow's current status for an issue.An issue can exist in one step only at any point in time. In the diagram above the rectangular boxes represent steps/statuses.
 A transition is a link between two steps. A transition allows an issue to move from one step to another step. A transition is a one-way link, so if an issue needs to move back and forth between two steps, two transitions need to be created. In the diagram above the arrows represent transitions.



Workflow Administration
Creating Workflow:  Login -> Administration -> Workflows -> Add new Workflow  (Give name & desc)
Editing a workflow: 
   Inactive workflow:  You can simply edit steps & transition
   Active workflow:  Not possible to edit active workflow directly. 
         Create draft -> Edit  & validate ->  Publish -> Backup old workflow

• Login ->  Administration -> Workflows  -> Choose your workflow -> Edit
• There are two types of edit mode, Diagram and Text

How to make a field mandatory during a workflow transition change ?
Request: In the “Fix” page, (when the bug is marked as fixed), Make the following fields as mandatory
1) Fixed in build 2) Fixed in Iteration 3) Code reviewed by 4) Fix description

Solution:
Using Diagram edit mode.

• Login ->  Administration -> Workflows  -> Choose your workflow -> Edit 
• Using workflow diagram I tracked my workflow steps involved in the transition. The source step is 'New' and destination is 'Assigned to QE' through the transition label 'Fix - Release to QE'. 
• Click on round wheel as shown above and select 'View Validators'
• Click Add a new validator -> Select 'Fields Required' -> Add -> Select the custom fields names (in my case its 'Fixed in build', 'Fixed in Iteration', etc -> Add.
• Publish and Take backup
• That's it
• Alternatively to do the same from Text mode
• Select workflows ->  Edit in Text mode -> Create Draft 
• Find the Step name (in my case its 'New') and the transition ( In my case 'Assign to QE') -> Click on the transition -> Validators -> Add -> Fields Required
• Publish & Backup

    




  

Read More

jenkins nested views not displaying with read permissions after upgrade

Today I upgraded Jenkins from 1.444 version to 1.470 and to my surprise it was not showing any nested views for anonymous users. It was showing only the default 'All' view. But if we login to jenkins, then it shows all nested views.

When I googled I found this relevant link https://issues.jenkins-ci.org/browse/JENKINS-13429

As suggested I had already had Jenkins version > 1.459, Nested View Plugin 1.8. But I didn't had Role-based Authorization Strategy. Even I added this plugin to my jenkins.

Then I realized that this issue can fixed without adding Role based Authorization Strategy.

We are already using 'Project-based Matrix Authorization Strategy' and migrating to Role based authorization will be some additional tasks, which I didn't wanted to do.

Anyways the solution is enable 'Anonymous' account 'Read' 'View' in 'Project-based Matrix Authorization Strategy'

Here is the detailed way of doing it

Login to Jenkins -> Manage Jenkins -> Configure System -> Access Control -> Authorization -> Project-based Matrix Authorization Strategy

For Anonymous user -> View section -> Click 'Read'

Read More

How to run dos commands from cygwin? File name too long - fix

Typically we write shell scripts and run it under cygwin shell. The command used in scripts like rm, mv are obtained from cygwin installation. But recently we encountered a tedious issue with cygwin shell.
The 'rm' command run from cygwin fails with message "File name too long" for some of the files and it's causing build failure.

After a bit of research, I found there is a limit for file name length in cygwin (I guess 256 characters). Upgrading the cygwin may fix the issue, but I didn't want to do that.

Fix: I found that the native dos 'rmdir' command can delete these lengthy file names without any issue and hence I decided to call native dos commands from Shell scripts.

Here is a way to call native dos commands from cygwin shell
  cmd /C rmdir /S /Q <directory>


here
   cmd   -  Starts a new instance of the Windows command interpreter
       /C   - Carries out the command specified by string and then terminates

  rmdir - dos command to delete directory
     /S - recursive delete of files & sub-directories
     /Q  - Quiet


Just add this command to shell script. It may need some if condition to run this only on Windows platform.

Read More