sorry to bring back an old item, but I have a related question..

because of the way we do software, I want to replace 'release' artifacts with a workitem.
can I customize the 'create a release' link in the build record ui?

Hi Sam, do you mean you want a release to be associated with a work item instead of a build, or that you want the build to be associated with a work item instead of a release?

Bill asked about API to set the build associated with an existing release.  Instead of creating a new release like in the UI code mentioned above, you'd modify an existing one -- set its artifact to be the build result handle, then save.

well.. 

we have a lot of software products. they range from mobile platforms to mainframe.
of course we have new development and we have product maintenance development.
the product maintenance can be as small as a mainframe module patch to a full cumulative release of a product on a quarterly basis (sort of like rtc deliveries)

we have at least 5 different targets of 'delivery' of some artifact package.
an External SaaS runtime, our internal Operations platform, our QA platform, our product manufacturing platform (create media, etc) and our Customer Support platform.

log story short, I need an artifact in the system that I can attach attributes, workflow with states, approvals, links to physical entities (zip package in library for example, aka , build output), links to contributing sources (defects, stories, ...), (aka, a workitem).

and these 'workitems' are built as part of the process.

A change set causes build, which creates a thing that is distributed to test, which creates defects ('found in'),
cycle repeats.. that produces a similar artifact with additional materials (links to bill of materials), now its an
'official' releasable entity.which has to be delivered,

but then has customer support issues/defects against (found in), which causes a change set, which creates an artifact, that has OS, pre-reqs (released thning), co-reqs(released thing) and supercedes (released thing), and some of our product teams have multiple streams active at customers. so one 'defect' resolution might appear in multiple future 'released' things. (and we track 'planned to be delivered' vs 'actually delivered')

so some of these deliverables are for the future, and we 'collect' defect and other contributions, and fire off a release on a schedule.

and I need to automate the transport of the artifacts to their destinations.. fix artifacts go to the support delivery system, saas to that channel, internal IT to that channel, etc.

and with full traceability back to their origins (all the way back to the requirement in the product mgmt system maybe)

the IDeliverable is 'nice', but way too primitive

I want the 'system' to help do all this, in some consistent way.. you build a deliverable, it was tested and approved. and it should flow to its target. for those that have complex flows, it may be a bi directional workflow
customer gets test fix, confirms it, then we repackage with the final doc etc.. (all of which flows thru the support system which has different artifact objects, numbers, ...)

so, if I end up with a new workitem(to hold all this metadata), I need to be able to change the 'create a "release"' link to create one of these, and link back to the build record (which links it to the contributing change sets, workitems, testcases executed (and not))

'reported against build' link.. see that semantic has a problem.. why isn't it 'reported against'  and the target workitem is just a deliverable. (I built found in/fixed in links , but I think a 'workitemlist' type object is really the semantic (altho I want a different UI to reduce the presentation space consumption).. 1 to many (without the burden of link artifacts too).. but its got to be a concrete workitem on the other side.

if you did it all with a workitem, automated test could run a scheduled query , find all the new 'delivery' workitems created since last scan of type 'build' (or push a record on a queue) and decompose their linked sources and gen the test set that verifies that content. 

a 'product' deliverable would test a different set of stuff. something that transitions to 'approved' flows to its target channel. this is where the back part of DevOps picks up. Taking the deliverable and loading it into the runtime for that channel under the direction of the approved processes.