I am aware that MKSSI_PROJECT_CONFIG_PATH command displays the project configuration path.
If i had to display the configuration path of a subproject then what would be the command?
I would like to know if the below understanding is correct:
MKSSI_SUBPROJECT" + cnt + "_CONFIG_PATH when a normal subproject is configured as Build.
Due to the above command MKSSI_BUILD environment variable value is not getting set.
Hello Karthik Komarla,
Interesting! What kind of environment is this command available in? Could you provide some sample output?
Hi Kael, you can see the environment variables the Integrity Client has available by creating a custom button which runs "cmd.exe". That will pop-up a CLI window and you can run the "set" command to view all the variables available.
Karthik, you can also get the config path of a project/subproject by running si projectinfo --project=/MyProject/project.pj
You could also get creative and cut out everything but the Config Path: si projectinfo --project=/MyProject/project.pj | findstr "Configuration Path:"
Thanks Joe Bartlett,
I missed that this was from the context of a custom button.
Hello Joe and Kael,
Yes, as Joe mentioned its for custom button. I could find the commnad for sub-project in any of the guides.
I even tried the command mentioned by you and here is what happened:
But the actual Config path is:
Thanks in advance.
This looks to be working as expected.
/TestingMainline/Test1/project.pj is a valid project in the registry which is why #/TestingMainline#Test1 is returning as a valid config path.
However, this is not quite what you have in your project structure since Test1 is configured as a "build" subproject. That is why the config path is showing the project checkpoint in the config path #/TestingMainline#b=184.108.40.206#Test1.
Yes, you have got that right. I shall create a case with Support, before I do so could you please confirm if there is any command to view "Build subproject info"?
Well you would need to do this through a couple steps, as far as I can see:
1) Run 'si viewproject' to show contents of a project which will include a build subproject being identified. Eg:
si viewproject --project=/OtherProject/project.pj --recurse --fields=name,type
SubA/project.pj (1.2) build-subproject
2) Knowing the name and the revision ID of the build subproject, it could be possible to build a command to view the project info. Eg:
si projectinfo --project=/OtherProject/SubA/project.pj --projectrevision=1.2
Does that help?
The environment variable you want to use is MKSSI_SUBPROJECT#_CONFIG_PATH, where # is a number giving which subproject is selected. For example, if I only have one subproject selected, then the subproject environment variables will be:
A useful trick I've found is to create a custom toolbar button that has the Environment File set, and simply opens this file in Notepad or another text editor. e.g:
Then launch this with different selections.
To explain further about configuration paths:
#/TestingMainline#Test1 means the subproject Test1/project.pj as currently configured in the project /TestingMainling/project.pj. In your case, the subproject is configured as build. The project information has the details on the build subproject - in your screenshot I can see:
Build Project Name: /TestingMainline/Test1/project.pj
Respoitory Location: /TestingMainline/Test1/project.pj
Configuration Path #/TestingMainline#Test1
If the subproject was reconfigured to normal or variant, using "#/TestingMainline#Test1" to view the project information would show that.
You can also construct a configuration path to open the build subproject directly: #/TestingMainline#Test1#b=220.127.116.11
The GUI gives a different configuration path which still points to the same subproject. It's giving the top-level project build, and then navigating to the subproject, as follows:
Here is how the product reads each of the configuration paths:
In your case, these all open the equivalent subproject. But they could be different paths. If your button is launching on the current selection, and the configuration of the subproject is not going to be changing, then using #1, which is given in the environment variables will work fine.