It's all about the answers!

Ask a question

Special editors for build definition properties?

Jeff Care (1.0k3733) | asked Dec 12 '13, 1:01 a.m.
retagged Dec 12 '13, 9:57 a.m. by Scott Cowan (966310)
The new & noteworthy for 4.0.5 had an intriguing image:

I'm interested specifically in the description for the runUnitTests property: this appears to be some sort of instruction for a custom field/editor for this property. Is this documented anywhere? My attempts at searching the web for anything turned up empty.

Scott Cowan commented Dec 12 '13, 9:58 a.m.

I believe this is a question for the enterprise team.  I don't see that property in base RTC.  I've added the "ee" tag.

Jeff Care commented Dec 12 '13, 10:35 a.m. | edited Dec 12 '13, 10:37 a.m.

The property itself is not interesting: what's interesting is the description of that property. That appears to be a very specific (and not particularly usefulto a human) format. It makes me think that the format is meant to be read & understood by RTC and presented in a specific manner to the user when requesting a build.

Scott Cowan commented Dec 12 '13, 4:08 p.m.

Ah right.  This is all I could find in our doc,

The extension point is used twice here, /, but I don't see "PULLDOWN {TRUE|FALSE}" anywhere.  Maybe it is extended by the enterprise team.  I'll get Nick to chime in.

Accepted answer

permanent link
Nick Edgar (6.5k711) | answered Dec 12 '13, 4:42 p.m.
This comes from the Build Forge integration, where extra property types and modes that we don't support directly are represented as keywords in the description.  This was a compromise done back in the first version of the BF integration, and hasn't been fixed since.  We really should provide direct support for these in RTC Build core, and map the BF properties to those without overloading the (human readable) description.

RTC does have an extension point for different build property types.  We've had a custom editor for workspace properties since RTC 1.0.  In recent releases (since 4.0.2), we provided a custom one for these pulldown properties, to restrict the choice to the given values, but it's chosen implicitly if the description has PULLDOWN.  There's no custom UI for defining such properties to begin with, so it's really only a partial solution.
Jeff Care selected this answer as the correct answer

Jeff Care commented Dec 12 '13, 6:01 p.m.

Thanks Scott and Nick.

I agree this would be a valuable addition: as our builds get more parameterized it would be very valuable to release engineers everywhere to make the build request process as fool-proof as possible. An enumeration picklist would simplify the request process for several of my builds considerably.

Nick Edgar commented Dec 12 '13, 9:19 p.m.

Agreed. Minimizing errors when requesting builds is important. Note that the (half-baked) feature above can be used by other kinds of builds, not just Build Forge builds.

It's also possible to validate choices early in the build script, and fail the build if any are found to be invalid, but this isn't nearly as nice as validating at request time.

Your answer

Register or to post your answer.