Perming an action on build output - writing a custom application
Hey folks,
I'm trying to write a user-facing application that will allow them to select a directory containing build output. The action, specifically, is the automation of CD burning based upon the output. Has anyone done anything like this previously? What I was thinking is writing an PHP application that will run on the build server. Workflow is as follows: 1) A list of the build directories is generated for the user 2) The user selects one of the directories 3) The application calls the CD burning application with parameters This may not specifically Jazz-related, but let`s consider it a brainstorming session. If I could utilize the CLM stack to perform this without custom application writing, it would be preferrably. I`ve written a Java application to automate the CD burning; all I need is the `client` application to call it with appropriate parameters. Any suggestions would be awesome possum Thanks, Chris |
Accepted answer
Hi Chris,
Do you already have a build definition that creates these build directories? Are you looking to add an option to an existing build definition? If this is the case, creating a post-build option (like post-build deliver) is the best route, but it's not simple and requires extending RTC client, server and JBE. Or, are the build directories already residing on the build machine and you want to just create a brand new build definition to burn the CD? If this is the case, you could create an Ant or Command Line JBE build definition to call out to your application. The build definition could require a property set by the requestor that points to the directory you want to burn. This would just use the existing RTC client, server and JBE features. Scott Chris Ryan selected this answer as the correct answer
Comments
Chris Ryan
commented Oct 11 '13, 12:05 p.m.
I never even considered designing and script, and calling it from a build definition.
Excellent Chris! Glad to hear that option will work for you with the existing RTC features. :-)
If the name(s) of the file(s) are well-known, and are uploaded to the build result as part of the build, e.g. using the artifactFilePublisher Ant task, you can retrieve them using the artifactFileRetriever Ant task.
If that approach is prohibitive, e.g. due to size of files, you can put the files somewhere else, use artifactLinkPublisher to link to them from the build, then retrieve them from the other location when doing the burn step.
If you include ${buildResultUUID} in the file name or grouping directory, that would give another implicit association with the RTC build. buildResultUUID is an Ant property set by JBE to identify the build. Could also use buildDefinitionId + buildLabel, but they're not guaranteed to be unique, or to not change. They could be added in addition to buildResultUUID to make the mapping more human-readable though.
One advantage of publishing the files directly to the build, using artifactFilePublisher, is that they get cleaned up automatically when the build gets deleted (either manually or due to pruning settings on build definition). If they're stored externally, that cleanup has to be managed externally, and can be tricky. |
One other answer
Combination of sites with tips on the proper design of resumes and cartoons fill out our house. So far, I can advise you https://top5resumewriting.services/ because I found this list to help my eldest son to geta proper resume and they wrote a wonderful one for him. And I will be glad if you tell me more about Essentials in Writing for kids <style type="text/css"> &amp;amp;amp;lt;!--td {border: 1px solid #ccc;}br {mso-data-placement:same-cell;}--&amp;amp;amp;gt; </style> |
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.