`_project.set_local_config` sets incorrect local_config_uri for GCM-enabled projects

[himi]

In ELM Python Client, the method set_local_config incorrectly selects the last matching contribution
from get_gc_contributions instead of the first one.
For GCM-enabled projects, this can result in returning the wrong local_config_uri.

Steps to Reproduce

1. Have a project with a Global Configuration (GCM) and multiple contributions for the same project/component.
2. Call:

set_local_config(name_or_uri, global_config_uri=...)

3. Observe that the returned local_config_uri corresponds to the last contribution in the flatList, not the first.

Expected Behavior

According to the official GC SDK documentation, the flatList returned by
flatListOfContributionsForGcHierarchy is depth-first ordered.
The first matching contribution should be used as it respects the "child overwrites parent" rule.

Actual Behavior

The last matching contribution is selected, which may be incorrect.

Proposed Fix

In set_local_config, break immediately after the first match:

for config in gc_contribs['configurations']:
    if config['componentUri'] == self.project_uri:
        config_uri = config['configurationUri']
        break  # first match is correct according to GC SDK

This ensures the local_config_uri is correctly selected according to the official ordering.

References

• https://jazz.net/gc/doc/scenario?id=GetFlatListOfContributionsForGcHiearchy

[himi]

I forgot to say that set_local_config() does not work properly if name_or_uri is None but global_config_uri is effective. In that case, simply skip the code to handle global_config_uri

[barny]

Thank you for your detailed issue.

You said "multiple contributions for the same project/component" - that's not valid: a component must only contribute once to a GC (stream/baseline), otherwise you get skew, and confusion.

I can imagine how set_local_config with name_or_uri being None could select the contribution that the component this is being called on makes to the specified GC,, except if you have >1 contribution from this component (which as I've said isn't valid) how could the "correct" contributing configuraiton be magically selected - there's no way to make this decision.

[himi]

@barny thank you for your reply. In my understanding, GC is actually a tree although we cannot get it from gcapi. Instead [GetFlatListOfContributionsForGcHiearchy](https://jazz.net/gc/doc/scenario?id=GetFlatListOfContributionsForGcHiearchy) returns a flat list that ensures the currently valid configuration first by using DFS. We actually get old and invalid configuration without this change. Please confirm that point. I believe someone in Rational knows this situation better.

[barny]

When you call set_local_config() is that on a component (i.e. not on the project)? Like calling src_c.set_local_config in this example (except you're also providing a global config)?

    # open the source project
    src_p = dnapp.find_project(src_proj)

    # find the component
    src_c = src_p.find_local_component(src_comp)
    src_comp_u = src_c.project_uri
    print( f"{src_comp_u=}" )

    # select the configuration
    src_config_u = src_c.get_local_config(src_config)
    print( f"{src_config_u=}" )
    src_c.set_local_config(src_config_u)

[himi]

Currently, I'm using single component project, so component_uri == project_uri.
Actually, I'm confused that the current ELM Python Client Library initialize the component uri of RMComponent as project_uri.

Anyway, we called find_local_component() with the project name. And we call set_local_config with global_config_uri, such as set_local_onfig(config_u, global_config_uri), but actually, config_u is ignored if global_config_uri is specified in the current code unless config_u is None. See the current implementation of set_local_config() for detail. I believe set_local_config() should work even if config_u is None as long as global_config_uri is specified.

[barny]

I'm confused that the current ELM Python Client Library initialize the component uri of RMComponent as project_uri

The RM Component class inherits from RM Project.

I've used this code with single-component projects so I don't think there's anything problematic about that.

Will have to get back to you, not likely to be quick :-(