Re-label a checkpoint recursively

[gschwarz]

I have the situation, that release candidates of the software are checkpointed and labeled. If now a release candidate is verified and accepted as the final release, I'd like to add the release label to this checkpoint and all its sub-projects as well, like the checkpoint command does. Unfortunately I could not figure out how to do this. The command "addprojectlabel" just works for the current location in the project tree, but does not add the label to the sub-projects contained within that folder. I tried the following command:

si addprojectlabel --label="LabelOfSWRelease" --projectRevision="LabelOfReleaseCandidate" --project="e:/a/path/to/a/project/within/a/PTC/project.pj" --hostname=servername.domain.com --port=1234

The hostname and port options are just to access a specific server and is not always required. The command does not allow '-r', like it is commonly used for recursive Integrity operations.

Is there another way of doing this? Any help is appreciated.

   Regards

       Guenter Schwarz

[MichaelChatel · Accepted solution]

Hi Guenter,

Currently, the -r or recurse option, is not available for the addprojectlabel (or deleting project labels) command.

The only interim workaround, if that is desired, is for one to implement their own recursion over the project tree (via a script, for example), to find the subprojects, and execute the commands on them (ex. execute the command n times).

However...

We are adding this option into Integrity 10.8, when it eventually gets released. 

FYI, we have a public article on this:

https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS86796&lang=en_US

[KaelLizak]

Hello Günter,

Was Michael's answer helpful?  If not, could you let us know what you feel is missing from the answer, or why the results weren't satisfactory?  If it is, could you press the Correct Answer button on his post to let everyone know the solution to this problem?

Thanks,
Kael

[gschwarz]

Hello Kael,

the answer was sufficient, it is like I'd expected, so it was just to be sure I did not miss a "hidden" command or option. So it is not really a big deal, I guess. I'll just have to see, if there can be problems when one of the sub-projects is a build sandbox or a development path sandbox if it might interfere and to be sure that, if multiple pj-files reside in a directory to not miss one. You'll never know what situations will occur, when the command is applied in the field.

I was glad to read, that there are plans to integrate the recurse option to the command and also for "deleteprojectlabel". I'm looking forward to the new version. Maybe it'll be faster rolled out than I find the time to finish the script for applying the label recursively.

   Best Regards,

     Guenter Schwarz

[kthierer]

An optional workflow here might be to use a devpath for the release process.

si createdevpath --projectRevision="LabelOfReleaseCandidate" --project="e:/a/path/to/a/project/within/a/PTC/project.pj" --devpath=V2_1_Release_process

Then do the needed work (like adding verification reports, binaries? , ...) for the release process on the devpath

and do the final release checkpoint on the devpath with a proper label.

I'd be interested what you all in this thread would think of such an approach.

Regards Jürgen

[kthierer]

For "post checkpoint labeling" it might be interesting that the checkpoint command will not label those subprojects

that are already configured as build projects (e.g. shared build projects).

Anyhow, what would be the approach to recurse in the subproject tree of a build project?

The only method I found generating some kind of parseable project tree was

si viewproject -R -P D:/project/on/server/project.pj --projectRevision=1.3 --filter=file:NO_MATCH

Are there better methods (with or without CLI)?

Regards Juergen