Structure Package type not taken from Git repository in nested package setup during Pull

[eoud]

Good day,

When my original nested package setup is:

• ZDEV (Structure Package)
  -- ZBC (Structure Package)
  -- -- ZBC_ABA (Structure Package)
  -- -- -- ZBC_ABA_ATF (Development Package)

All packages in the GitHub repository will reflect the correct types after staging, and I create the ZDEV package manually in the target system. So far so good.

However, when pulling the repository (Folder Logic = Full) in a new system the following error is given:

Besides that the error message (import of object...failed) is incorrect, since the package actually are imported, they are imported as type Development Packages, thus ignoring the source XML values for:
<RESTRICTED>X</RESTRICTED>
<MAINPACK>S</MAINPACK>

In the target system this then results in:

• ZDEV (Structure Package)(as manually created beforehand)
  -- ZBC (Development Package)
  -- -- ZBC_ABA (Development Package)
  -- -- -- ZBC_ABA_ATF (Development Package)

For both the stage and pull I've used the standalone version: abapmerge 0.16.0 - 2024-04-24T14:41:46.792Z and both SAP systems are S4H op2023.

[larshp]

when manually creating ZDEV, did you create it as a structure package?

[eoud]

Yes sir :-)

[eoud]

I've added you as a collaborator to the repository on GitHub, perhaps that will make it a bit easier for you

[larshp]

yea, well, we'd like a public accessible example, ideally in https://github.com/abapgit-tests

there is already https://github.com/abapGit-tests/DEVC_struct_package , not sure if it has broken, or there is another scenario

anyhow, I dont have time to look into it today(somebody else feel free to pick it up)

[eoud]

I've created a public repo https://github.com/eoud/DEVC_Nested_Struc_6923.git. There is no rush for it today, but if someone has time at some point it would be great. Thanks in advance.

[mbtools]

I was able to reproduce it.

abapGit automatically creates all packages as (template) development packages as a first step.

Then the packages (and other objects) are deserialized. However, in this case, the packages are processed in the wrong order:

In my case, the repo package ZTEST should be deserialized first. This would change it to a structure package. Then ZBC could be changed as well. And so on.

We do have method get_deserialize_order but it's not fully implemented yet, unfortunately. It's not trivial... I don't think I have time for it before July.