javajenkinsjenkins-pluginsjenkins-clijenkins-scriptler

inhouse build tool to Jenkins


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?


Solution

  • 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.