I have reported this to Microfocus as well. This breaks build processes that use your StarTeam actions:
It appears some switches have been dropped from the SDK. We use FinalBuilder 7.0.0.1724 (current version) and it tries to pass -x -stop to stmd.exe within its actions supported for StarTeam.
stcmd.exe rejects those switches and fails to execute. While we can report this to FinalBuilder to change their interfaces, anyone using the current FinalBuilder (or older) will be unable to use the new SDK. Once they support it anyone using the 12.0 SDK will have to upgrade FinalBuilder.
We are working around this by converting everything to DOS commands where I determine the command-line instead FinalBuilder's StarTeam actions (until either FB changes or StarTeam changes the SDK).
Error: The command syntax "update-status -is -cfgl "12.2.0.20" -p "BuildMachine:******@SSISPDEVS2:49201/SSIS Worker/Main/" -cmp -x -stop "*.*"" is invalid. The parameter(s) "x,stop" is/are not supported by this command. Please check the Command Line Documentation for a list of supported parameters
It appears that no error code is returned, so Finalbuilder also thinks the command succeeded. FB does not analyze the output looking for 'The command syntax'. The old command switch -stop used to stop the process on the first failure.
I ended up reinstalling the StarTeam 2006R2 to use its version of the stcmd.exe to get my build process working. Using the 12.0 SDK I couldn't easily tell if a command succeeded or not. The old version appears to work with a 12.0 Server so I can re-enable my StarTeam actions and disable my DOS attempts to do the same thing.
That’s bad form from Microfocus to remove command line options. The better way for them to handle that would have been to just ignore it and perhaps just print a warning that it’s no longer used. As for not returning a non zero return code, that makes it very difficult to handle errors… parsing the output to deal with that is not my idea of fun (playing guess the error message, especially if the tools are localised). IMHO Starteam has always been problematic, they never did understand command line usage (they were not alone, PVCS and Clearcase have similar issues).
I have some feedback for you. The reason you are receiving the following error message "The parameter(s) "x,stop" is/are not supported by this command. Please check the Command Line Documentation for a list of supported parameters" is because as you know they have been deprecated. In previous versions of the STCMD they could be added to the update-status command but the actually did not provide any value, and this is why they have been removed in 12.0 SDK. The update-status cannot fail on an exit code, it will always return status. In Star Team 12.0 STCMD R&D have basically corrected the SDK and documentation by removing –x and –stop from available update-status syntax. In the documentation I have attached (Page 57) outlines all available syntax that can be used with update-status command.
Regards,
Graeme
--------------------
Guy: Actually, none of the commands suppotr -x and -stop, so all FB StarTeam actions fail. Evidentally, they were marked as Deprecated some time ago and finally removed (rejected). The only work around at this point is to user older versions of StCmd.exe until FB removes -x and -stop.
I am not sure if the commands will return an error code or not. It did not appear that they do in some tests.
I have done further testing on my own building the commands myself and they return codes on some failures.
However, I have an on going argument with Microfocus that syntax errors in the command-line arguments should not return a code '0' as if it succeeded. I could cause a syntax error with a bad variable string within your action, so even if you fix your command-line, I could mess it up with a bad embedded string.
I found out that Logon failures do return code '1'. However, I tried an invalid label and they sent back a return code of '0'.
I just downloaded the command line reference. I cannot find any reference to deprecated options in the 2009R2 (the link for 2009 is broken) or 12. The -x option if for batch mode, and was always needed to stop the command line from prompting for input. So have they changed their command line tool so it never prompts for input? As for detecting errors, it seems it only ever returns 0 or 1 - not very useful at all. I seriously doubt that these guys understand the whole concept of command line non interactive usage.
I’d seriously think about looking for another version control solution.
I will look at adding an option that takes off the depreciated options.
12.0 StCmd has lots of issues. Not sure if there is much point in fixing your actions yet, since you cannot easily identify success. Your customers are better off sticking to an older version of the command until they clean things up. (FYI: I requested permission to send their documentation to you).
Things that do not work: Creating a label on a view that does not exists returns a code of ‘0’. Updating status on a label where the label does not exist returns a ‘0’. Syntax errors return a code of ‘0’
Things that work: Bad user name or password returns code ‘1’ Trying to creat a label that already exists returns a code ‘1’
It’s not going to a quick fix to add an option, the UI for all the actions will need some serious rework (these actions haven’t been touched in some time).
As a work around for now, you should be able to Add the following to the OnGenerateStarTeamOptions script event for each starteam action in your project (Javascript) :
Return code of ‘1’ is useful if you can rely on treating that as an action failure. As it is, with some failures returning ‘0’ you would have to parse the output. I wouldn’t expect you to do that. You would have to try every possible thing to see what the output looks like.
Just for label creation, you would have to try the following to see what you get back: User does not exist User cannot create a label User cannot access a view Label already exists Project does not exist Server name is invalid Port is invalid Time patter is invalid
You need to be able to count on the return code to at least make your action know if there is a failure. If it fails, then you users can look in the build log and see what the scoop is. However, if it pretends to not fail, it will be much harcer to trace.
Thanks for the work around. However, using the old version in our build environment seems to be a better solution. Your work around will be useful to test their functions as they fix them. However, with return code often returning 0 on an error, it will be hard to detect failures in the right places.
I'll try removing the two arguments once they cleanup their return codes.
There is a chance we might be able to migrate to Team Founday Source Control. Draw back would be loosing our file history. How well does that work with FinalBuilder? I noticed you support that as well.
As a work around for now, you should be able to Add the following to the OnGenerateStarTeamOptions script event for each starteam action in your project (Javascript) :
This worked to cleanup the command-line to run, but we still prefer to be able to count on errors being reported as an action failure. We may use this once StarTeam gives us a fix (if they give us a fix). I am waiting for them to admit that a return code of '0' on any failure is a bug.
We do have TFS support (and will continue to), however I would say moving from Starteam to TFS would be a step down… TFS has to be the slowest version control system out there (not that starteam was ever that fast).
If you want to stick with a non distributed version control system then I can recommend Surround SCM, we use it here and it’s been very reliable. We’re using Mercurial on new products though, the DVCS model does give a big increase in productivity once you learn how to use it.
I have been dialoging with the SDK developer at MicroFocus on the forum and they are escalating the issue to be fixed as a high priority. The Error code issue with failures returning '0' was more understandable to the developer than the support people (probably non programmers). Here is the latest post on my incident:
I have been liaising with Anil (SDK Forum) on this and we have escalated the bug internally. Under #4419. R&D are now working on the fix for this issue and aim to have a patch released soon as possible. Thank you for making us aware of this issue. I will keep you update on progress.
I will use the script event to remove the legacy arguments from the command-line as suggested on an earlier post in this forum. I confirmed that works fine. VSoft/FinalBuiler will need to figure out a better solution for their users so that the actions inherently use or do not use -x -stop based on the version of StarTeam.
I can see an invalid argument being rejected because it might not be doing what the user intended. It is a hassle for some developers. A removed option that is ignored could be doing something other than what the user intended. Usage needs to re-evaluated. For example, suppose they changed the filter syntax and made the old one invalid. If they just ignored the invalid filter, they would apply the update to everything, not just the items the user intended to filter. The result could be very different from what the user intended.
Microfocus has a new version of the StarTeam 12.0 SDK (12.0.0.26) that now returns codes of '1' for errors: Invalid Userid, invalid password, invalid Server Name, Invalid Port, Invalid Project Name, Invalid View Name, and Invalid Label.
We do need to remove the obsolete arguments in the OnGenerateStarTeamOptions event: