Don't add fullname tag in 2GP package.xml

[leboff]

Fixes #3415

[davidmreed]

@leboff I'm ... very surprised that this works, but I should have long since given up being surprised by the need for such tweaks!

A few questions for you, as I think I will probably need to discuss this change with the Packaging team to fully understand the impact and expected behavior.

• What kind of 2GP package are you building? Managed, unlocked, org-dependent? Namespaced?
• When you built the package with this change, what happened? Did you obtain a fully viable/installable package version, with the problem component (a Quick Action, I believe?) included?
• Have you ever promoted a 2GP package version built with this change?

Thank you for your efforts in investigating and addressing this subtle issue.

[leboff]

@davidmreed thanks for looking into it. Answers below

• What kind of 2GP package are you building? Managed, unlocked, org-dependent? Namespaced?

Managed + Namespaced

• When you built the package with this change, what happened? Did you obtain a fully viable/installable package version, with the problem component (a Quick Action, I believe?) included?

Yes

• Have you ever promoted a 2GP package version built with this change?

Yes, I use a forked version of CCI with this change and have close to 10 2GP packages promoted and in many production environments with this change applied

[davidmreed]

@leboff Fascinating. I'll check in with my colleagues on Packaging to help me understand what's happening here. Using <fullName> naively should be correct. I'll also compare and contrast with SFDX. On a quick review it appeared to me that SFDX was using it.

There is a related, known bug where packaging a CustomObject subentity in a 2GP that is owned by another package fails. I wonder if this behavior is related, and the distinction you're seeing is an emergent interaction between a couple of different edge cases!

One last question - are your repos in SFDX metadata format?

[davidmreed]

Sorry, further last question: have you ever tried to upload a package version with this structure using SFDX directly? If so, what behavior did you see?

[leboff]

are your repos in SFDX metadata format?

yes

Sorry, further last question: have you ever tried to upload a package version with this structure using SFDX directly? If so, what behavior did you see?

I think that's how I found the issue. Comparing the zip sfdx CLI used (which worked) and the zip CCI used (which did not)

[davidmreed]

Thank you again for the exceptional detail and research here!

[winterrk]

Is there an ETA on release of the fix?
We're setting up some build processes & wondering if we'll need to include the workaround into the pipeline.

[yippie]

Please fix this. While nice to name your packages, it completely breaks any ability to deploy tweaks or updates to metadata that is in a package.

Interestingly, the same bug/limitation also affects change sets.

[yippie]

I am currently running into an issue where this is preventing me from creating new 2GP Unlocked package without a namespace. My package has a quick action in it that references a namespaced (2gp unlocked also) lwc and it fails with

Can’t add component MED_Translate_Interaction because it’s associated with metadata from a managed 2GP package. Managed 1GP packages can’t depend on managed 2GP packages.

Please merge and fix this

[jstvz]

Fixed in #3636

[pasres]

@jstvz sorry for commenting on this closed PR. We are currently experiencing this issue as well and it is citically blocking our progress while developing 2GP packages.

Context:

• 2GP package A contains: Apex, Custom Metdata Types and Records, Layouts and Triggers
• 2GP package B references package A and some of its content
• While creating a beta package for package B (flow: release_2gp_beta, task create_package_version) we get:
  Can’t add component xyz because it’s associated with metadata from a managed 2GP package. Managed 1GP packages can’t depend on managed 2GP packages.
• When I create it via sfdx, it works without issues

We understand there might be larger implications of @leboff 's fix, but we are not able to move forward while the issue persists.
We would really appreciate if you could take another look at this, especially considering @leboff 's mentioned track record of successful package creation and deployment.

Thanks in advance!

mentioning @winterrk and @yippie to check-in if they still experience the issue as well.

[leboff]

@pasres I've already opened #3748 as I'm still experiencing the issue as well. I currently use a forked version to get around the issue in our packages.

[pasres]

@leboff thanks for your answer, the initial effort to figure it out and the new PR! Really appreciate it.