2GP packages includes profiles which are not in the package directory

[wmigas]

Summary

following command sfdx force:package:version:create includes all profiles metadata which are in the project directory but are outside of the package source directory

Steps To Reproduce:

Repository to reproduce: sfdx-cli-bug

1. you need to configure one org with namesapce, then 2nd one with devhub and linked namespace to devhub org
2. update sfdx-project.json file (use your namespace from step 1)
3. create new package sfdx force:package:create -n YourPackageName -t Managed -v YourDevHub -r sfdx-source/packaged
4. create new package version sfdx force:package:version:create -v YourDevHub -p YourPackageName -x -r -w 30

Expected result

package is crated without admin profile definition

Actual result

package is created with Admin profile which is not part of the package source dir.

Additional information

The command sfdx force:package:version:create -v samdev -p xxx -x -r -w 30 has additional parameter -r which display temporary folder with converted metadata which will be used to create package. this folder container md-files where is admin profile which should not be included It can even go worse, because if there will be additional folder with admin profile (let's assume that it will contain page layout assignment with namespace, then page layout assignment will be filtered out and empty admin profile will not be included in the metadata and will throw error

ERROR running force:package:version:create: We couldn’t create this package version because new components were added or existing components were deleted. Add components {Profile=[Admin]} back into the package version, and create the package version again.

all that mess is caused by calling typesArr = this.profileApi.filterAndGenerateProfilesForManifest(typesArr); in https://github.com/forcedotcom/salesforce-alm/blob/e0c7ec04c248592cd25c7fb43f4a386cf5561557/src/lib/package/packageVersionCreateCommand.ts#L347 which then search for profiles in project directory. instead of the project directory it should be restricted to the package directory (sfdx-source/packaged)

SFDX CLI Version(to find the version of the CLI engine run sfdx --version): sfdx-cli/7.74.1 win32-x64 node-v12.16.2

SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core) @oclif/plugin-autocomplete 0.1.5 (core) @oclif/plugin-commands 1.3.0 (core) @oclif/plugin-help 3.2.0 (core) @oclif/plugin-not-found 1.2.4 (core) @oclif/plugin-plugins 1.9.0 (core) @oclif/plugin-update 1.3.10 (core) @oclif/plugin-warn-if-update-available 1.7.0 (core) @oclif/plugin-which 1.0.3 (core) @salesforce/sfdx-trust 3.4.3 (core) @sfdx-plugins-lab/plugin-apex-coverage 0.1.5 alias 1.1.1 (core) analytics 1.12.1 (core) config 1.1.8 (core) generator 1.1.3 (core) salesforcedx 49.10.0 (core) ├─ templates 49.9.1 (core) ├─ custom-metadata 1.0.10 (core) ├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core) ├─ apex 0.0.9 (core) └─ salesforce-alm 49.11.0 (core) sfdx-cli 7.74.1 (core) sfdx-codescan-plugin 1.0.4 sfpowerkit 2.1.5 shane-sfdx-plugins 4.39.2

OS and version: windows 10 PRO Version 10.0.19042 Build 19042

[azlam-abdulsalam]

I don't think this can be fixed easily, I guess its by design. The profile is reconciled only to contain the types carried out in the package. This is for the coverage validation testing and other aspects

[wmigas]

@azlam-abdulsalam I don't have issue that profile is stripped out from the items which are not part of the managed packaged. it is OK and it follows what is in the documentation. my issue is that it includes to the package profile from the folder which is outside package. If you create package, then in the sfdx-project.json file in the packageDirectories section you will get { "path": "sfdx-source/packaged", "package": "YourPackageName", "versionName": "ver 0.1.0", "versionNumber": "0.1.0.NEXT", "default": false, "definitionFile": "config/project-scratch-def.json" } then you can have multiple directories with packages or which have some additional code which is not part of the package like { "path": "sfdx-source/untracked" }

The Profile definition is put outside sfdx-source folder. It should not be picked up by command sfdx force:package:version:create. The above command correctly takes data only from the"sfdx-source/packaged" directory and convert it to metadata. Issue is related to method which cleanup profiles, because it search for profiles in project directory (workspace) instead of the sfdx-source/packaged. It should include and clean profiles only from the sfdx-source/packaged folder which is marked on yellow. it should not include profile from the profiles directory which is marked on orange. the orange one is just helper directory for developers.

[manisfdcsfdx]

#540 related issue.

[github-actions[bot]]

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.

[mhail]

Im getting error in one of my pr branches, where some items in a profile were updated: We couldn’t create this package version because new components were added or existing components were deleted. Add components {Profile=[Mobile Solutions Profile]} back into the package version, and create the package version again.. The profile Mobile Solutions Profile is in a folder outside of the packaging directory and is for a community that is deployed for development and testing.

I have submitted a support case related to this ticket.

As an additional note I checked and the profile was not in any of the released versions of my package. Changing the parameters --tag pr0 --versionname pr0 parameters in theforce:package:version:create command allowed me to package the master branch, possibly this is only tag or version name specific? Im running more tests packaging to see if there is a work around.

[balindersingh]

I am getting similar error .. Any solution?

1) Can’t create package version. Removing metadata components from a second-generation managed package is a pilot feature that requires acceptance into a pilot program. 

To join the Remove Metadata Components from 2GP pilot, file a case in the Salesforce Partner Community. 

To create a package version without removing metadata components, restore the removed components and try creating the package version again. Add components {Profile=[Admin]} back into the package version, and create the package version again.

[1ktribble]

Since this is "Working as designed" per the product team for packaging, I created this "Idea" on the idea exchange. Please share and upvote.

https://ideas.salesforce.com/s/idea/a0B8W00000JI9UYUA1/unlocked-package-version-creation-should-only-refer-to-components-within-itself

[kksanghi]

any one had the work around for above issue ? To create a package version without removing metadata components, restore the removed components and try creating the package version again. Add components {Profile=[Admin]} back into the package version, and create the package version again.

[wmigas]

the only option to fix it is to remove it from the package, by enabling custom metadata remove from the 2n generation packages. https://help.salesforce.com/s/articleView?id=release-notes.rn_sfdx_packaging_remove_components.htm&release=234&type=5

[kksanghi]

I have a cyclic dependency here, We have added Admin Profile Initial, Reason Behind this because Test Classes was failing reason in SOQL we have SECURITY_ENFORCEMENT.

Now If we remove again test coverage going to fail. Any Idea on this ?

I wanted to retain Admin Profile but CLI removes them automatically.

[amtrack]

We're facing the same issue. It feels wrong that Profiles from completely unrelated directories are being included. And it is very difficult to understand and debug when facing this issue.

In our Git repository we have an examples folder containing a demo Profile. I never thought about that this might cause problems, because insfdx-project.json > packageDirectories we only have a package directory for force-app.

• force-app has a Real Profile profile
• examples has a Demo Profile profile

However the Profile from the examples folder is processed.

To debug sfdx package version create I was using SF_LOG_LEVEL="debug" In ~/.sf/sf.log there are log entries like this:

The profile "Demo Profile" from the "/path/to/project/examples/main/default/profiles/Demo Profile.profile-meta.xml" directory was added to this package version.
The profile "Real Profile" from the "/path/to/project/force-app/main/default/profiles/Real Profile.profile-meta.xml" directory was added to this package version.

[shetzel]

This is fixed as of CLI v2.11.8 See release notes here: https://github.com/forcedotcom/cli/blob/main/releasenotes/README.md#2118-oct-4-2023