Creating custom Pre-Build and Post-Build options
I would like to create custom Pre-Build and Post-Build options that would be available to all build definitions in my repository. Currently there is only a 'Jazz Source Control' option for Pre-Build tasks, and 'ECJ Publishing' and 'Junit Publishing' for Post-Build tasks. The dialog layout leads me to believe that this functionality is meant to be extended. (Each option is a checkbox and there are 'Move Up' and 'Move Down' buttons to set the order in which the tasks are performed.) I have spent a good deal of time searching the jazz.net net documentation and the forums but have not found anything that would help me get started with this process. Is this even possible? Can anyone point me to documentation that would get me going in the right direction?
Thanks, -Dave |
26 answers
Glad to hear. When doing plug-in development, I recommend running with -clean -debug -consoleLog and maybe -console until things stabilize.
-clean clears out the plugin deployment and registry caches -debug can give more info in the error log around plug-in dependency issues -consoleLog routes the error log to the console -console gives you the OSGi console, which can be helpful for diagnosing plug-in dependency and activation issues (enter help for a list of commands, and check out the ss and diag commands especially) |
|
Thanks for the advice I will certainly use those options going forward.
I have also successfully implemented step 4 so I have a complete working test example of how to extend the build. I do however have one more question for you. How do you envision customers like myself extending the pre and post build processes? Right now I am hacking together some jars with my edited plugin.xml files and class files. Is there a better way to do this? Can I use some eclipse plugin magic to create a new plugin to add these features? (I have some plugin development experience, but it is limited.) I love the fact that I can extend RTC in this way, but the way I'm doing it now is a tedious manual process. Thanks, -Dave |
|
I just added an entry to the Build FAQ about using PDE Build. The instructions need to be updated (the example was done against 1.0) but the process is the same, so if you have plug-in development experience you should be able to make sense of it.
https://jazz.net/wiki/bin/view/Main/BuildFAQ#PdeBuild If you get stuck, just post here. |
|
Also, rather than manually knitting together jars, from the IDE you can use File > Export > Plug-in Development > Deployable plug-ins and fragments.
Both this and PDE Build use the build.properties file to drive what goes into the built plugins. |
Hi Nick,
Thanks for your response.
The background is that I'm writing a new build engine. Like the generic template, I'm hoping it can drive the build too. I've almost got it to work completely so that when I define a build with the generic template it can see build requests, do a checkout from a defined workspace (defined in my build engine that is) and then update Jazz with the result. What I don't want to lose out on however is the personal builds and for that I need to have the Jazz SCM pre build step. I had a look at the info in this post and it seemed that the easiest way to do this would be to extend the Generic template. perhaps not. Would it be as simple to take the generic template, copy it, add the Jazz SCM pre build step and then deploy as an all-new, additional Build Definition Template option - "Andrew's Build Template" for example? Hope this makes sense. Cheers, Andrew |
|
> Would it be as simple to take the generic template, copy it, add the Jazz SCM pre build step and then deploy as an all-new, additional Build Definition Template
Yes, that would work. Unfortunately templates are not currently extensible (i.e. to add new configurations after-the-fact), but I think they should be. |
> Would it be as simple to take the generic template, copy it, add the Jazz SCM pre build step and then deploy as an all-new, additional Build Definition Template Thanks Nick, No worries. I've a little PDE experience so what you''ve posted here should help me on my way. This would then let my Hudson plugin get access to the build request type and workspace name right? That should mean I could have "Personal Build" support. I really like that so its something I'm looking to implement. You're right though, it would be nice to extend existing ones ;-) Regs, Andrew |
|
As long as Hudson lets you change certain properties at the time of request, I don't see any reason why you couldn't support personal builds. You just need to set the right property for the build workspace (as discussed previously) in newOrModifiedBuildProperties, and set personalBuild to true in the call to IBuildRequestService.requestBuild, whose signature is:
Not sure how you were thinking of letting the user specify the build workspace though. It could be done just by name, though there's no guarantee of uniqueness on workspace names. Or you could bring up a workspace picker, though that would currently require using REST interfaces that are internal. |
Nick,
Thanks for the great tutorial on extending the build process. I suggest you promote this to something in the Articles or Library section so it is easier to find. |
|
Good idea, I should at least capture it as a wiki page. Are you extending Build? Care to share?
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.