1

I am working on to migrate inhouse written java based build tools to Jenkins. The inhouse build tools has more than 1000 jobs for various products and their respective release and each job has 10+ steps and each step has some lines of code to executed. This inhouse build tool is written in Java.

inhouse build tools doing nothing but reading following files and creating a dynamic jsp view and load the build history from db and display it.

  1. Step.prop - which has all the step and respective commands e.g

pdplanner : clean : YES : YES : runant -Dproperties_file=build/dallas78.build.properties -f buildjars.xml clean_all

pdplanner : version : YES : NO : runant -Dproperties_file=build/dallas78.build.properties version

  1. Clearcase config spec files .cs for each job

If we start setting up each jobs in jenkins for all 1000 jobs, it will take a more than a year to get the successful build for all. I am thinking to do some automation whereas the dynamically Jenkins config.xml can be created by reading all these properties n spec files for each project.

One more specification from product mgmt team is that - we should be having each step as a checkbox in jenkins job so if someone does want to execute some of the steps, they can uncheck it accordingly.

I am puzzling my mind to do this task with different options but have not concluded...i did consider template plugins which might not suite my way. Can you please share your views/suggestion on this problem and share your ideas?

Rajesh Kumar
  • 355
  • 3
  • 19
  • I found that Multi-Configuration Jenkins Job type is best suited but its not giving options to disable the value in form of checkbox of anything else? ANy idea? – Rajesh Kumar Nov 18 '14 at 13:15
  • Is there any possibility where matrix plugins use same workspace for all the options??? I am stuck there – Rajesh Kumar Nov 18 '14 at 14:30

2 Answers2

3

Management needs to look down at the earth, once in a while. An apple is not an orange. If you have an apple, and want an orange, you cannot paint the apple in orange color and call it an orange.

Jenkins is not the same as your in-house java build system. If you are moving to Jenkins, that's because you want Jenkins, not something else. Don't expect (or rather management shouldn't expect) it to be exactly like the previous system, otherwise: why did you start the change over in the first place?

Automatically creating config.xml.
If you can script something that will automatically create the config.xml on the file system, then do it. These configs won't be loaded to Jenkins until you select "Reload from disk" from Global Configuration, or restart Jenkins.

There are many plugins that can construct the job dynamically, ranging from simple Jobcopy Builder that simply replaces some token text, to more complicated like Job DSL which provide it's own job description language.

Checkboxes for every step.
Read my comment about painting apples into orange. Jenkins doesn't have this. The best you hack together is to create checkbox parameters for every step, and then wrap every step into Conditional Buildstep plugin, which will check for the value of the variable, and execute the step only if checked.

You would probably also need Flexible Publish plugin to have the same functionality for post-build steps.

Slav
  • 27,057
  • 11
  • 80
  • 104
1

I am not sure if you are still looking for this solution to have checkboxes on every step, but I have a similar situation & I just thought of sharing the approach I took.

First, Jenkins seems to be a wonderful tool, giving us many options with the remote execution capabilities it provides. From there, I think we should handle the rest in our programming logic.

So for the situation we have, where I would like the end user to select which part (steps) of the job is to be executed for each run, I added a build parameter - Text type, but I made the description to guide the user to enter a binary figure which captures the input we want (like 11111 - execute all steps, 10000 - execute only first step etc... We can add some checks to make sure its binary). Then, I used this build parameter in the script run by the (main) step in Jenkins to decide which sub steps (This is not a Jenkins step so to say) to run. Good luck. Cheers.

Although it looks a bit crude, it serves the purpose. It helps to add major conditions to group of commands to be run atleast, if not a condition for each step - I dont think you will need the user to decide whether each micro step is to be run for every job run.

Satish
  • 11
  • 1