It's all about the answers!

Ask a question

JBE questions and best-practices


Tom Frauenhofer (1.3k58435) | asked Jan 14 '08, 10:08 a.m.
Using 1.0Beta2.

Some questions about the JBE and building"

1) Jazz assigns a label to each build which (I believe ) can be
overridden using buildResultsPublisher. If I don't override the Jazz
assigned build label, is there a way for the build to find out what
label has been assigned ?? (perhaps there's a property that can be
queried).

Why ? because I'd like to encode the Jazz assigned label into the
Artifact file names that my build publishes.

2) The JBE needs a userid and password and each ANTTask also appears to
need a user id and password. Is there a way for the ANT Tasks to just
use the userid that was passed to the JBE ?

3) Similar to Q2 .. must I provide a password on the JBE command line ?
What best-practices exist for setting up builds and the JBE so that real
passwords are not coded within build files and on the JBE command line ??

4) I know the documentation discusses creating a special 'Build' user.
But even so, doesn't the password still need to be coded in the JBE
command line and within the build.xml file.

Any help appreciated

2 answers



permanent link
Ryan Manwiller (1.3k1) | answered Jan 14 '08, 12:48 p.m.
JAZZ DEVELOPER
Hi David,

Regarding the build label being available in an ant property. There is
currently no way to get it in ant. But, this is a good idea. Please create a
work item for this, category = Build.


Regarding passwords in the jbe command line and in the ant tasks. I
understand this approach is not sufficient. We have a work item where we are
investigating alternatives. I would like to keep the current behavior since
it is simple, but also provide an alternative that does not have passwords
in clear view. Follow along in work item 39649
https://jazz.net/jazz/web/projects/Jazz%20Project#action=com.ibm.team.workitem.viewWorkItem&id=39649


In the meantime, it is recommended to keep the user/password in a separate
properties file that is not in source control (it is only accessible to the
build machines) and read that into your build script. For example, create
auth.properties with contents:

userId=build
password=abc

Then in your build script:
<property file="auth.properties"/>

Reference these properties when using jazz ant tasks:
<startBuildActivity
userId="${userId}"
password="${password}"


It is also recommended to use a special build user. The password will still
be visible, but at least it is not "your" password.


Ryan Manwiller
Jazz Team Build Lead

permanent link
Tom Frauenhofer (1.3k58435) | answered Jan 14 '08, 2:08 p.m.
Thanks for the advice

Opened Defect 41192 for access to Jazz assigned build label.

I'm presently using your suggested technique for coding the
userid/password as build properties.

I'll follow your advice and create a special build user for now..

Cheers

David Ward wrote:
Using 1.0Beta2.

Some questions about the JBE and building"

1) Jazz assigns a label to each build which (I believe ) can be
overridden using buildResultsPublisher. If I don't override the Jazz
assigned build label, is there a way for the build to find out what
label has been assigned ?? (perhaps there's a property that can be
queried).

Why ? because I'd like to encode the Jazz assigned label into the
Artifact file names that my build publishes.

2) The JBE needs a userid and password and each ANTTask also appears to
need a user id and password. Is there a way for the ANT Tasks to just
use the userid that was passed to the JBE ?

3) Similar to Q2 .. must I provide a password on the JBE command line ?
What best-practices exist for setting up builds and the JBE so that real
passwords are not coded within build files and on the JBE command line ??

4) I know the documentation discusses creating a special 'Build' user.
But even so, doesn't the password still need to be coded in the JBE
command line and within the build.xml file.

Any help appreciated

Your answer


Register or to post 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.