Tagging Build Results using Apache Ant
Hi,
how would it be possible to tag a build result using the provided Jazz tasks for Apache Ant? If this is not possible how could a REST API be leveraged from within Apache Ant to tag the current build result. My intend is that QA build definitions for instance should have a "for-qa" tag by default and it shouldn't be necessary to do such tagging manually. Cheers Daniel |
Accepted answer
Ralph Schoon (63.6k●3●36●47)
| answered Dec 14 '11, 8:19 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Daniel, I am unsure how i could miss that. The buildResultPublisher task allows to set tags....
http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.team.concert.dotnet.doc/topics/r_build_res_pub.html Daniel Stefan Haischt selected this answer as the correct answer
Comments
Hagit Segev
commented Mar 20 '14, 9:47 a.m.
Hi,
I could not use the documented command:
<buildResultPublisher
repositoryAddress="${repositoryAddress}"
userId="${xml.constant.username}"
passwordFile="${xml.constant.pw.file}"
buildResultUUID="${buildResultUUID}"
tags="${xml.build.full.number}" />
I get:
build.xml:491: buildResultPublisher doesn't support the "tags" attribute
Tried with "tag" and "tags"
Hagit
|
5 other answers
Ralph Schoon (63.6k●3●36●47)
| answered Dec 12 '11, 4:50 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Daniel,
I have looked through the ANT tasks and could not find a way to tag builds automatically. I am also not sure if there is a REST Api to do that. There would probably be a way to use the Java API to tag a build result. On the other hand I am confused why you would want to automatically tag. If this is something specific to the build definition, the build definition itself is common criterion for all the builds in a queue and thus acts as a "tag". Wouldn't that be enough, maybe even name the build definiton qa_. Otherwise I would see that tag being some non automated mechanism where a human has to decide to tag a build. |
Hi Ralph,
Hi Daniel, well yes maybe you are right. I am currently in the process of refactoring our build infrastructure now that our product went GA. Before GA we only had one build definition that was used to create installable images. It was use for creating both development images and images which were meant to be handed over to QA for testing. Thus we tagged each build result accordingly to indicate whether it's a result meant to be handed over to QA. After refactoring we now have separate build definitions for QA and development so tagging them explicitely might not be necessary any more. Cheers Daniel |
Ralph Schoon (63.6k●3●36●47)
| answered Dec 13 '11, 2:24 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Daniel,
I think that is a better solution in the long run. |
Hi Ralph,
Hi Daniel, I am also thinking to establish a similar stream structure. Right now we only have one development stream where we do development, integration and QA driver delivery. Maybe it's more scalable to have a dev, integration and QA stream. The JKE Banking sample uses such a stream structure... what do you think? Cheers Daniel |
Ralph Schoon (63.6k●3●36●47)
| answered Dec 13 '11, 2:43 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Daniel,
yes, that would be a reasonable approach. That way you can have more control over what is delivered to the QA team. Actually the Stream used for the builds would be the major difference between the build definitions. You could also have more than one build server to increase throughput. There are several articles here about Stream strategies, I just picked the first I found. https://jazz.net/library/article/649, https://jazz.net/library/presentation/750, http://www.ibm.com/developerworks/rational/library/parallel-development-rational-team-concert/index.html?ca=drs-. Maybe there are some suggestions you want to follow. |
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.