How can I pre-validate a stream-to-stream delivery using Java API or lscm?
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
Geoffrey Clemm (30.1k●3●30●35)
| answered Oct 21 '14, 1:23 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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
Comments 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.). Ah, thanks, that didn't occur to me. It seems reasonable. |
One other answer
Ralph Schoon (63.5k●3●36●46)
| answered Oct 20 '14, 8:02 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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. |
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.
Comments
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.
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.