It's all about the answers!

Ask a question

SCM deliver client fails due to non-existent operational behaviors


Norman Dignard (356688167) | asked Nov 28 '17, 2:28 p.m.

 env Jazz 602 ifix10, using liberty on RH 6.4, oracle 11gr2 backend


We have source code migration underway from Apex to JAZZ . We've exercised this on our testbed and now want to do it into production. Project areas are configured the same.  

When the user tries to deliver using the scm cmd line tool, it fails with the error precondistions have not been met.
 ( a checkin comment and associated work item).

I've removed all deliver preconditions, added then back in but disabled but regardless of what I've done in both the web and client for the project processes, this issue remains. 

Is there some hidden files on the client that may be causing this issue, if not any ideas??  Even with no pre-conditions it still complains for the same thing.
 


Comments
Geoffrey Clemm commented Nov 28 '17, 2:37 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Do you get the same behavior when you try the deliver via one of the GUI clients like Eclipse?


Norman Dignard commented Nov 28 '17, 2:45 p.m.

 We can't use the client. The cmdline runs a bunch of routines to setup the workspace , pull stuff out of Apex and then checkin/deliver to JAZZ


Geoffrey Clemm commented Nov 28 '17, 3:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I meant, can you deliver anything to that stream from any workspace.

This would help determine if there is something strange about that stream.
Assuming that you can, then I'd try a simplified version of that script that just sets up the workspace, and then tries to deliver a single change to the stream.
This would help determine if there is something strange about doing the deliver from the script.
If both of those succeed, then it is something that is happening when you are pulling stuff out of Apex.


Ralph Schoon commented Nov 28 '17, 3:40 p.m. | edited Nov 28 '17, 3:42 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

My experience so far. When user reported magical operation behavior issues, it was usually a configuration issue and not a tool issue. A process can inherit stuff, a user as well as a technical user can have multiple roles, operational behavior can be tied to an I teration or an iteration type. Usually the user is the issue in cases like this overlooking something or not understanding the consequences of a configuration. I have see it far too often over the years.


Geoffrey Clemm commented Nov 28 '17, 3:47 p.m. | edited Nov 28 '17, 3:48 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I agree with Ralph's comment above.   Since this behavior is determined by the stream receiving the deliver, and the ID of the user performing the action, a simple test of using the GUI to try a simple delivery to the stream, while logged in as the same user ID as is used by the script, will often expose this kind of problem.   If you can reproduce the problem in the GUI, you can use the process adviser to ask the system where that particular process check was coming from.


Norman Dignard commented Nov 29 '17, 11:13 a.m. | edited Nov 29 '17, 2:56 p.m.

The gui displays the same problem. -you need a WI and comment for deliver. So much for that.


Geoffrey Clemm commented Nov 29 '17, 2:58 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Yes, that is why it is important to reproduce in a simple test case from the Eclipse GUI ... once you are in the Eclipse GUI, you have many more mechanisms for exploring your environment, including detailed messages from the process adviser which allows you to drill into the reasons.

showing 5 of 7 show 2 more comments

Accepted answer


permanent link
Norman Dignard (356688167) | answered Nov 29 '17, 11:19 a.m.

After more poking around in the project's process it turns out that the problem was on the iterations. This is a formal project area, straight out of the box. 

The admin had removed all the team operational behaviors using the web I/f. Turns out that you can't see the iterations behaviors in the web.

Looking from the outside, we did not see any preconditions. On looking at the process model from the rtc client, we noted that each iteration had them enabled. After removing them, the user was able to deliver using the cmdline tools.

Lession learnt - deleting team operational behaviors does not remove them from the iterations.

A better error message would have helped in finding this quicker.

Ralph Schoon selected this answer as the correct answer

Comments
Ralph Schoon commented Nov 29 '17, 11:21 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Nope, I don't think there should be an error if the system works as expected.

Your answer


Register or to post your answer.