It's all about the answers!

Ask a question

How can I pre-validate a stream-to-stream delivery using Java API or lscm?

Andy Jewell (24226173) | asked Oct 16 '14, 7:01 p.m.
We use multiple streams to manage our promotion between development, test, and production environments.  E.g.:

Dev StreamTest StreamProduction Stream

Our whole organization has this addiction to cherry picking work items.  So we get 30 or 40 different changesets against 10 or 20 different work items and then they choose 5-15 they want to promote.

When we try to promote (deliver) that subset of changesets we often get either the "can't promote changeset x because doing so would create a version gap" error or the "can't promote changeset x because this would cause a conflict.  Use a workspace instead and resolve the conflicts first" error.

Can anyone suggest a way to prevalidate that any given set of changesets would be "ok" to deliver -- before actually delivering?

Tim Mok commented Oct 20 '14, 10:56 a.m.

What are you trying to achieve with a validation check before delivering? The error you receive is your validation and gives a reason for why you can't deliver. The given reason will allow you to take the correct course of action to be able to deliver the change sets.

Andy Jewell commented Oct 20 '14, 11:20 a.m.

I suppose I could try this through LSCM and see if the results are parseable and useful.  In the UI I can tell you that the error provided is not useful because it doesn't tell you exactly WHAT the problem is.  This would be useful: "foo.h cannot be delivered because it would create a version gap by the undelivered changeset 7888".  Or this: "foo.h cannot be delivered because it would conflict with foo.h in changeset 4444".  But the UI doesn't give this information and if you have a lot of changesets involved it's a real hassle to find the culprits.  The other thing about making an attempt and observing the error is that we don't always WANT to deliver at that moment.  We just want to know if we would have a problem with a given combination of changesets to be delivered.  In the "try to and watch for an error" approach, if there is no error then the delivery would occur.  I guess the point is  pre-validation, not just validation in the course of execution.

Accepted answer

permanent link
Geoffrey Clemm (30.1k33035) | answered Oct 21 '14, 1:23 a.m.
You could create a temporary stream which is a copy of the existing stream (a cheap operation), and then try to deliver to the temporary stream.   Process the results of that operation, and then delete the temporary stream.
Andy Jewell selected this answer as the correct answer

Tim Mok commented Oct 21 '14, 10:01 a.m.

I think this will be the way to go to get validation without delivering to the target stream. The deliver operation API doesn't support this kind of checking in its validation as it's more of a client-side check (unresolved changes, sandbox in-sync, etc.).

Andy Jewell commented Oct 21 '14, 10:31 a.m.

Ah, thanks, that didn't occur to me.  It seems reasonable. 

One other answer

permanent link
Ralph Schoon (62.7k33643) | answered Oct 20 '14, 8:02 a.m.
Hi Andy,

I don't think there is anything built into RTC for that purpose so far. Maybe it is possible to call the operations that trigger this behavior in the API. However, I am not even sure and what behavior to call.

Andy Jewell commented Oct 20 '14, 10:54 a.m.

Hmmm. . . nuts.  Thanks for thinking about it. 

Your answer

Register or to post your answer.