On package version creation receiving error: "Admin: An object 'Admin' of type Profile was named in package.xml, but was not found in zipped directory"

[jdschleicher]

Note
Before you submit your issue, make sure that:

• You're using the latest version of Salesforce CLI.
• You've searched both open and closed issues for related posts.
• You've used the doctor command to diagnose common issues.
• You understand that GitHub Issues don't adhere to any agreement or SLA.
  • If you require immediate assistance, use official channels such as Salesforce Customer Support.

Summary

Similar to : #2395 but this time with creating fully validated sf packages.

command used to create package version:

sf package version create --target-dev-hub $devhub_alias --package $package_name --tag "tag_name" --code-coverage --installation-key-bypass --wait 120 --json --verbose

Was not getting any issues running locally so I did a compare cli version compare and the only thing that was different was the operating system. I setup our CI jobs to run on windows-latest and it worked. Below is the working sf --version --verbose --json:

I would not want to use windows so is there anything here that can point to the issue?

WORKING WINDOWS VERBOSE IN GIHUB ACTIONS

{
  "cliVersion": "@salesforce/cli/2.5.8",
  "architecture": "win32-x64",
  "nodeVersion": "node-v18.17.0",
  "osVersion": "Windows_NT 10.0.20348",
  "shell": "cmd.exe",
  "rootPath": "C:\\npm\\prefix\\node_modules\\@salesforce\\cli",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.6 (core)",
    "@oclif/plugin-commands 2.2.22 (core)",
    "@oclif/plugin-help 5.2.17 (core)",
    "@oclif/plugin-not-found 2.3.37 (core)",
    "@oclif/plugin-plugins 3.2.6 (core)",
    "@oclif/plugin-search 0.0.22 (core)",
    "@oclif/plugin-update 3.1.32 (core)",
    "@oclif/plugin-version 1.3.8 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.48 (core)",
    "@oclif/plugin-which 2.2.30 (core)",
    "@salesforce/cli 2.5.8 (core)",
    "apex 2.3.10 (core)",
    "auth 2.8.12 (core)",
    "data 2.5.6 (core)",
    "deploy-retrieve 1.17.5 (core)",
    "info 2.6.39 (core)",
    "limits 2.3.30 (core)",
    "login 1.2.26 (core)",
    "org 2.10.0 (core)",
    "schema 2.3.23 (core)",
    "settings 1.4.25 (core)",
    "sobject 0.2.4 (core)",
    "source 2.10.31 (core)",
    "telemetry 2.3.0 (core)",
    "templates 55.5.10 (core)",
    "trust 2.6.1 (core)",
    "user 2.3.28 (core)"
  ]
}

Steps To Reproduce

Use the package version create command

IMPORTANT
Provide a repository that's configured to reproduce the issue. If you are unable to provide a repo, please explain why not. The more info we have from the start, the faster we can resolve your issue.
We may close your issue if you don't include proper instructions.

• Generate a project with sf project generate or fork dreamhouse-lwc.
• Provide detailed step-by-step instructions on how to reproduce the issue.

Expected result

created package version success

Actual result

failure with error: "Admin: An object 'Admin' of type Profile was named in package.xml, but was not found in zipped directory"

System Information

bash - > fails
when cmd.exe-> succeeds

FAILING UBUNTU VERBOSE IN GIHUB ACTIONS

{
  "cliVersion": "@salesforce/cli/2.5.8",
  "architecture": "linux-x64",
  "nodeVersion": "node-v18.17.1",
  "osVersion": "Linux 5.15.0-1041-azure",
  "shell": "bash",
  "rootPath": "/usr/local/lib/node_modules/@salesforce/cli",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.6 (core)",
    "@oclif/plugin-commands 2.2.22 (core)",
    "@oclif/plugin-help 5.2.17 (core)",
    "@oclif/plugin-not-found 2.3.37 (core)",
    "@oclif/plugin-plugins 3.2.6 (core)",
    "@oclif/plugin-search 0.0.22 (core)",
    "@oclif/plugin-update 3.1.32 (core)",
    "@oclif/plugin-version 1.3.8 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.48 (core)",
    "@oclif/plugin-which 2.2.30 (core)",
    "@salesforce/cli 2.5.8 (core)",
    "apex 2.3.10 (core)",
    "auth 2.8.12 (core)",
    "data 2.5.6 (core)",
    "deploy-retrieve 1.17.5 (core)",
    "info 2.6.39 (core)",
    "limits 2.3.30 (core)",
    "login 1.2.26 (core)",
    "org 2.10.0 (core)",
    "schema 2.3.23 (core)",
    "settings 1.4.25 (core)",
    "sobject 0.2.4 (core)",
    "source 2.10.31 (core)",
    "telemetry 2.3.0 (core)",
    "templates 55.5.10 (core)",
    "trust 2.6.1 (core)",
    "user 2.3.28 (core)"
  ]
}

Additional information

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[ashishrajbanshi]

Try renaming files which contains .profile-meta.xml" and ".profile" before version creation.

[jdschleicher]

thank you @ashishrajbanshi ! we took a look, we dont have any profiles in our codebase. it's the strangest thing and i don't think it has anything to do with what is in the package/codebase because we've seen this error in other random steps when we converted from sfdx to unified sf

[olektymchenko]

Hi @jdschleicher
Maybe it's somehow related to this?
#2336

[jdschleicher]

thank you @olektymchenko , there are no profiles in the codebase. The word "Admin" doesn't even exist. It has nothing to do with profiles but something to do with what was listed in the above details around the github actions run. We can run the package version creation commands fine localy but the moment the same exact commands with the same exact codebase run in github actions on an ubuntu system they put out the "admin not found in package.xml" error. The moment the operating system is changed to windows, it works fine.

[AllanOricil]

weeeird 😐

[mshanemc]

This is a duplicate of #2336 (same root cause). We have a fix for that in progress...stay tuned.

[jdschleicher]

Our workaround using windows is no longer working at what seems like that update from yesterday @mshanemc .

I'm not sure if it's related. We've experienced this error with brand new packages that have no profiles present.

The only workaround found was to use windows operating systems and it looks like they could be broke now too.

[jdschleicher]

just confirmed, in reverting back, the package version created and installed successfully

[shetzel]

@jdschleicher - this has more to do with the version of your packaging plugin and dependencies than the CLI version. It's possible that the "JIT plugins now respect a lock file during install" CLI change modified your packaging plugin in a way that makes your workaround stop working. I believe my recent fix to the packaging library and plugin should resolve your issue so it would be great if you could test that out. Please run sf plugins:install packaging@latest. You should then be on packaging plugin version 1.25.1. Then try your package version create command again.

I think the reason for this error is that the packaging library code was looking for profile metadata files anywhere within your project, including node_modules and other non-package directories. It must have found an admin profile and added it to the manifest but it wasn't included in the zip of metadata to be packaged. The most recent packaging plugin scopes the profiles it cares about to just the package directories defined within sfdx-project.json, so it should fix the problem for you.

[jdschleicher]

thank you @shetzel would the sf plugins:install packaging@latest apply in github actions virtual machine as well?

that is where we are receiving the errors and having a hard time reproducing locally.

We have done global searches for admin profiles and even the word "admin". This may not have looked through any node_module folders though so I will take a look.

We have had projects that were brand new, no profiles added and they would generate the same error.

I'm attempting to get the temp folder results from the dev-debug but not quite sure where it's landing in github actions. I just came across the github contexts for temp but haven't tried it yet: https://docs.github.com/en/actions/learn-github-actions/contexts#runner-context

[shetzel]

thank you @shetzel would the sf plugins:install packaging@latest apply in github actions virtual machine as well?

Yes it should.

[jdschleicher]

thank you, will give it a go

[jdschleicher]

hey hey @shetzel i gave it a go, and i do believe i tried this before as the second to last ditch effort before we changed our "runs-on" to use windows-latest. It did not seem to make a difference.

This seems separate but it may be related since our workaround for package versoin creatoin and scratch org creatoin ended in recent releases.

Our scratch org creatoin has stopped working recently

I just added you as a collaborator https://github.com/jdschleicher/sf-sfdx-cli-version-troubleshooting/actions/runs/6291942045/job/17080829071

Feel free to adjust the code to log what you feel you need.

For whatever the reason, when we auth devhub jwt we get the error " ENOENT: no such file or directory, ...". Which I don't think we've had any issues creating scratch orgs utnil 2.7.11.

When I use authentication for devhub auth url, the scratch org creation works just fine.

If you have any insights or want to jump on a call i would very much appreciate it.

I'm also having issues capturing out the debug logs as the runner.temp context in github actions doesn't seem to capture the debug/verbose/preserve items from the sf cl.

[AllanOricil]

@jdschleicher change SFDX_LOG_LEVEL to fatal and then add a job step to save this directory as an artifact. Use if: always() in the job step that creates the artifact.

Then download the artifact and post the log here.

[jdschleicher]

thank you @AllanOricil !

Did not expect that artifact to be so massive 🚀

I am not seeing a folder under the "sf-sfdx-cli-version-troubleshooting" that looks like a guid that was highlighted in the image above.

The only thing I see under the sf-sfdx-cli-version-troubleshooting folder is the actual codebase.

I'm going to change the path to point to just the sf-sfdx-cli-version-troubleshooting

[AllanOricil]

@jdschleicher check the cli doc to find the path where logs are located

[jdschleicher]

@AllanOricil will do, that last artifact didn't seem to have anything that screamed logs.

On my local windows machine it ends up in my appdata/local/temp folder.

The artifact that was downloaded was from the github actions machine path D:\a\

I'll check out what salesforce has for debug/logging files documenation

[shetzel]

FYI: see the latest release notes for when this bug fix will be included in a CLI release.

It will be CLI v2.11.8. More specifically, the fix is in @salesforce/plugin-packaging v1.25.1 and @salesforce/packaging v2.3.10. After the CLI is installed, you can install a specific version of the packaging plugin to get the fix immediately. To do that, you would run sf plugins:install packaging@latest or if you'd prefer to target a specific plugin version you can run sf plugins:install packaging@1.25.1

[ctardif35]

@shetzel I have the same issue when I try to create a new package.
I have installed the latest version and I still encounter this issue.

How can I solve this

[shetzel]

@ctardif35 - append --dev-debug to your packaging command and check the output. There should be some clues where it's finding the profile. Also, check the generated package.xml to ensure it looks correct.

[rlbarreto]

I'm still facing the same issue. I'm using @salesforce/cli/2.15.8 darwin-x64 node-v18.15.0

[shetzel]

@rlbarreto - what version of the packaging plugin do you have? Did you run the command with --dev-debug and look at the output to get additional information about where that profile is coming from?

[rlbarreto]

My sfdx-project file looks like this:
{ "path": "resources", "package": "UnlockedPackageName", "versionNumber": "0.1.1.NEXT", "default": false, "versionDescription": "" }, { "path": "force-app", "default": true, "package": "SourcePackage", "versionNumber": "1.0.0-NEXT", } ...
The profiles are part of the SourcePackage. When I try to create a package version for the UnlockedPackageName it fails with the message above(however, using my profiles names, of course).
I'm using the latest plugin version(installed today)

[shetzel]

I believe this is working as expected then. There is a new feature coming soon to further scope profiles to just the package directory being packaged. It could be added as soon as the next CLI release candidate tomorrow. Watch for the release notes.

[shetzel]

@rlbarreto - I just published a new version (1.26.5) of @salesforce/plugin-packaging that you should install and try with the new scopeProfiles attribute you can set on the packageDirectories definitions. I believe that is the behavior you are looking for, but it's only available in version 1.26.5 (and any newer versions after it) of the packaging plugin.

[petter-eikeland]

@shetzel I tested the scopeProfile, and it seems to be working for us at least! Dreamhouse LWC

Before update:

Stable RC:

[shetzel]

@petter-eikeland - Great to hear! Also note that if you enable debug output for that command (e.g., --dev-debug) you should see output that makes it clearer which profiles are being included.

[mpaul1]

Confirmed upgrading the packaging plugin solves the issue. Upgrading to the latest SFDX and SF versions did not work. I had to update the packaging plugin directly: sf plugins:install packaging@latest sf package version create succeeded after that. Thank you!

[gsbasso]

Issue suddenly appeared after upgrading CLI (2.21.8) and packaging plugin (2.0.1). Adding "scopeProfiles": true to the package declaration in the project file fixed the problem.

To me it appears to be trying to pull in all profile source from our unpackaged folder, which frankly makes no sense (the package folder contains no profile source).

I suspect I will need to add scopeProfiles to every package declaration, though if the package folder does contain any profile source (I can't recall if any do) I'm not sure whether that source will also be excluded?

[shetzel]

@gsbasso - I'm not a packaging expert but from what I understand from that team it's intended behavior that by default all profiles within the source project are included and then trimmed to only contain things relevant to the source being packaged. If you add scopeProfiles to the package definition it should only include profiles that are directly in the target package.

[gsbasso]

@shetzel I took a closer look at the profiles from the unpackaged folder that were reported as missing and those profiles that did have references to the package content were not among them. This contrasts with previous behaviour whereby all profiles within the unpackaged folder were being excluded (which forced us to refactor a # of tests that were suddenly failing). Arguably what is happening now is an improvement (as we would want dependent profiles to be included), but those are are excluded should not generate any errors. Presumably someone is looking into how to prevent these errors other than through scopeProfiles?

[omareljundi]

@shetzel adding "scopeProfiles": true to my package setup did the trick for me.

Windows OS
sf version: 2.47.4 w/ packaging version: 2.4.6