Welcome to the Jazz Community Forum
How can I pre-validate a stream-to-stream delivery using Java API or lscm?
![](http://jazz.net/_images/myphoto/f57199c599264a4bb3727ecda32b753f.jpg)
We use multiple streams to manage our promotion between development, test, and production environments. E.g.:
Dev Stream → Test Stream → Production 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?
Accepted answer
![](http://jazz.net/_images/myphoto/f57199c599264a4bb3727ecda32b753f.jpg)
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.
Comments
![](http://jazz.net/_images/myphoto/dbae95bdb19ad8361907d9b236827b71.jpg)
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.).
![](http://jazz.net/_images/myphoto/f57199c599264a4bb3727ecda32b753f.jpg)
Ah, thanks, that didn't occur to me. It seems reasonable.
Comments
Tim Mok
JAZZ DEVELOPER 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
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.