sfdx package:version:create fails, tests failing due to a missing profile which should be there

[mwannamaker41]

Summary

Trying to build a package version via the following command
sfdx package:version:create -p 0Ho.... -r -c -x -w 100
Fails due to tests failing.
This project has been built many times, the tests are not new and have existed in previous packages created.

Steps To Reproduce

Have a project with a profile in the profiles/ directory.
Build a package version using the command:
sfdx package:version:create -p 0Ho.... -r -c -x -w 100

IMPORTANT
No Repository

Expected result

New package version is created

Actual result

All tests are failing:
Error (1): Multiple errors occurred:
(1) Apex Test Failure: Class.PTT_TestHelper.createTestUsers: line 291, column 1
Class.PTT_TestHelper.createResource: line 605, column 1
Class.PTT_TestHelper.createResourceDirectorate: line 526, column 1
Class.PTT_ResourceDirectorateTriggerTest.should_change_enddate_of_remaining_records_on_delete: line 321, column 1 System.NullPointerException: Attempt to de-reference a null object

All tests fail at same place Class.PTT_TestHelper.createTestUsers: line 291, column 1

Here we create a test user and assign them a profile 'PTT_ProjectUser' profile which is in the profiles/ folder of our package directory. I believe that this profile can't be queried in the test because it doesn't exist.

In the temp directory under the md-files/ directory I see a profiles/ directory but it is empty. I would expect that my PTT_ProjectUser.profile-meta.xml should be in that directory.

System Information

Using zsh but running the command through a bash script file.
On a mac

My SFDX output

{
  "cliVersion": "sfdx-cli/7.204.6",
  "architecture": "darwin-arm64",
  "nodeVersion": "node-v18.15.0",
  "osVersion": "Darwin 22.5.0",
  "shell": "zsh",
  "rootPath": "/Users/mwannamaker/.local/share/sfdx/client/7.204.6-fbe290c",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.0 (core)",
    "@oclif/plugin-commands 2.2.15 (core)",
    "@oclif/plugin-help 5.2.9 (core)",
    "@oclif/plugin-not-found 2.3.24 (core)",
    "@oclif/plugin-plugins 3.1.2 (core)",
    "@oclif/plugin-search 0.0.17 (core)",
    "@oclif/plugin-update 3.1.16 (core)",
    "@oclif/plugin-version 1.3.4 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.37 (core)",
    "@oclif/plugin-which 2.2.21 (core)",
    "apex 2.2.22 (core)",
    "auth 2.7.17 (core)",
    "community 2.3.0 (core)",
    "custom-metadata 2.1.24 (core)",
    "data 2.3.20 (core)",
    "deploy-retrieve 1.11.0 (core)",
    "info 2.6.16 (core)",
    "limits 2.3.17 (core)",
    "org 2.9.3 (core)",
    "packaging 1.18.0 (core)",
    "schema 2.3.10 (core)",
    "settings 1.4.10 (core)",
    "signups 1.4.20 (core)",
    "source 2.10.12 (core)",
    "telemetry 2.2.0 (core)",
    "templates 55.4.18 (core)",
    "trust 2.4.20 (core)",
    "user 2.3.14 (core)",
    "sfdmu 4.28.0 (user)",
    "sfdx-cli 7.204.6 (core)"
  ]
}

Additional information

I had a colleague build a package version and they were successful. They checked and the profile is being copied into the profiles/ folder in the md-files/ directory. They are on a windows machine and here is their sfdx information:

{
  "cliVersion": "sfdx-cli/7.193.2",
  "architecture": "win32-x64",
  "nodeVersion": "node-v18.12.1",
  "osVersion": "Windows_NT 10.0.19045",
  "shell": "cmd.exe",
  "rootPath": "C:\\Users\\mullingm\\AppData\\Roaming\\npm\\node_modules\\sfdx-cli",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.1.5 (core)",
    "@oclif/plugin-commands 2.2.10 (core)",
    "@oclif/plugin-help 5.2.8 (core)",
    "@oclif/plugin-not-found 2.3.22 (core)",
    "@oclif/plugin-plugins 2.4.2 (core)",
    "@oclif/plugin-search 0.0.14 (core)",
    "@oclif/plugin-update 3.1.7 (core)",
    "@oclif/plugin-version 1.3.0 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.31 (core)",
    "@oclif/plugin-which 2.2.16 (core)",
    "apex 2.2.5 (core)",
    "auth 2.7.8 (core)",
    "community 2.2.5 (core)",
    "custom-metadata 2.1.7 (core)",
    "data 2.3.6 (core)",
    "info 2.6.0 (core)",
    "limits 2.3.8 (core)",
    "org 2.5.0 (core)",
    "packaging 1.16.2 (core)",
    "schema 2.3.3 (core)",
    "settings 1.4.2 (core)",
    "signups 1.4.7 (core)",
    "source 2.8.0 (core)",
    "telemetry 2.1.3 (core)",
    "templates 55.4.4 (core)",
    "trust 2.4.4 (core)",
    "user 2.3.5 (core)",
    "@salesforce/sfdx-plugin-lwc-test 1.0.1 (core)",
    "sfdx-cli 7.193.2 (core)"
  ]
}

Possibly is due to the difference in our sfdx versions.

[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.

[WillieRuemmele]

Hi @mwannamaker41 - could you, and your colleague whose command is working run the command with sfdx doctor --command "<exact command>"?

that'll run the command with logging enabled and produce 3 files, could you attach those files for the two different versions?

[mwannamaker41]

1686837663910-command-debug.log
1686837663910-command-stdout.log
1686837663910-diagnosis.json.txt

Here are my files from the failed package creation. Had to rename .json to .json.txt in order to upload

[mwannamaker41]

1686840869047-diagnosis.json.txt
1686840869047-command-stdout.log
1686840869047-command-debug.log

Here are the files from my colleague with successful package creation. Had to rename .json to .json.txt in order to upload

[WillieRuemmele]

Thanks for providing those @mwannamaker41 - could you try having the working cli install the latest version of the packaging plugin... this will help us determine if it's a windows vs mac bug, or a bug in newer versions of packaging...

sfdx plugins install [email protected]

once you rerun the failing command, you can sfdx plugins uninstall packaging to get back to the bundled (working) version in that case

[mwannamaker41]

@WillieRuemmele Do you mean you want my colleague where it works to install this plugin? Or me where it doesn't work to install the plugin?

[WillieRuemmele]

I meant where to works, install the newer version of the plugin.

I met with some members of the packaging team that actually own these commands. They brought up this PR forcedotcom/packaging#265 that changed the way unpackaged profiles are bundled. It seems like before they were incorrectly being added to the package. They suggested that you might need to

as a potential workaround, perhaps they could move the profile to a “packaged” directory (vs unpackaged)
not sure if that’ll work, but would be worth a try

hopefully that PR will shed some insight into why things changed. It was also roughly released around 7.197.0, so that would make sense why it's working on your coworkers older version

[mwannamaker41]

Thing is my profiles are in package directory. Therefore that PR does not apply from what I can see.

My colleague just installed the package plugin and ran the package version create command and now it fails for him and in the md-files/profiles/ folder there is no profile metadata. So he is seeing the same behaviour as me with this new plugin.

But like I say the profiles are in the package directory.

[mwannamaker41]

Here are files from doctor command after installing new package plugin:

1686856958052-diagnosis.json.txt
1686856958052-command-stdout.log
1686856958052-command-debug.log

[WillieRuemmele]

Thanks for verifying that - your coworker can uninstall the new version, and you can install the old version by specifying the version like [email protected] to get that command working again for the meantime

I've let the packaging team know

[mwannamaker41]

When they say unpackaged metadata directories does it mean this in the project json file?

  "unpackagedMetadata": {
    "path": "force-app/core-application/test-only"
  }

[mwannamaker41]

If this is what the PR is talking about then we may have other issues. We have other projects that use that to push profiles to the packaging org for testing purposes. The profiles are actually from another package/project, but since profiles are not installed with the dependency, we have to put a copy of them in this unpackagedMetadata folder so that our tests will run. As long as these profiles in the unpackagedMetadata folder is still "pushed" to the packaging org to run tests, then all will be okay.

[WillieRuemmele]

yes, I believe that's what they mean by "unpackaged metadata"

[github-actions]

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.

[arafesthain]

#2153

[dudunato]

Facing the same issue in our github action. Any workaround on this?

[gikokopev]

This is also effecting us. We were forced to use older sfdx version - 7.196 for packaging for quite some time now. Is this on the roadmap to be fixed? Links for versions that this issue isn't present aren't even available on the older versions links lists.

[mshanemc]

this is fixed as of yesterday.

for sf: sf plugins uninstall packaging and then re-run your command. It'll update itself to the version that has the fix.

We don't plan to release further updates to sfdx. #2132

If you want to keep using sfdx, I think you could sfdx plugins install packaging and it should pull in a version with the fix

[WillieRuemmele]

forcedotcom/packaging#349