Beta packages can no longer be used in package dependencies

[alper-tovi-cko]

Summary

I am unable to create a new package with a beta package inside the dependency tree. Often times we create packages, and test them before releasing it into production. New change doesn't allow us to use a beta dependant package in the dependency tree.

Steps To Reproduce:

Enter the version number of a beta package in the dependency array in package.json. Try creating a new package. I get the error message Error: Can’t create package version. Package dependency [04txxxxxx] isn’t a valid subscriber package version ID. Correct the package ID in your sfdx-project.json file, and retry creating the package version.

Expected result

Package creation should succeed.

Actual result

Failure

System Information

{
"cliVersion": "sfdx-cli/7.137.1",
"architecture": "darwin-x64",
"nodeVersion": "node-v14.17.3",
"pluginVersions": [
"@oclif/plugin-autocomplete 0.3.0 (core)",
"@oclif/plugin-commands 1.3.0 (core)",
"@oclif/plugin-help 3.3.1 (core)",
"@oclif/plugin-not-found 1.2.6 (core)",
"@oclif/plugin-plugins 1.10.11 (core)",
"@oclif/plugin-update 1.5.0 (core)",
"@oclif/plugin-warn-if-update-available 1.7.3 (core)",
"@oclif/plugin-which 1.0.4 (core)",
"@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)",
"alias 1.2.1 (core)",
"apex 0.8.0 (core)",
"auth 1.8.1 (core)",
"config 1.3.19 (core)",
"custom-metadata 1.0.12 (core)",
"data 0.6.8 (core)",
"generator 1.2.2 (core)",
"info 1.2.0 (core)",
"limits 1.3.0 (core)",
"org 1.11.1 (core)",
"salesforce-alm 53.9.0 (core)",
"schema 1.1.0 (core)",
"sfdx-cli 7.137.1 (core)",
"source 1.8.11 (core)",
"telemetry 1.4.0 (core)",
"templates 53.5.0 (core)",
"trust 1.1.0 (core)",
"user 1.7.1"
],
"osVersion": "Darwin 20.6.0"
}

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

[alper-tovi-cko]

I tried working around this by promoting the beta package without deploying it to production, still no luck. I am blocked from creating a package because of Package dependency [04t08000000on4jAAA] isn’t a valid subscriber package version ID. Correct the package ID in your sfdx-project.json file, and retry creating the package version.", error. I can't understand what the issue is. This is affecting our development.

[alper-tovi-cko]

It seems like for packaging to succeed dependent package needs to be installed in DEVHUB, which doesn't work for us, as we are unwilling to deploy packages without proper testing is completed in sandbox environments. This is such a HUGE breaking change.

[jwalke]

We appear to be experiencing the same issue. This is breaking our our CI/CD process when we attempt to create package versions for our 2nd gen unlocked packages.

[241m241]

We are experiencing the same issue. This is happening for released packages as well. Not just beta.

[thomasminney]

We are experiencing the same problem too. Doesn't happen on version 7.136.2

In case this is the related change, the release notes for 7.137 mention that package ancestor is required for 2GP version creation but the article link (https://help.salesforce.com/s/articleView?id=release-notes.rn_packaging_ancestor_enhancements.htm&type=5&release=236) specifies the requirement only applies to 2GP managed packages.

This problem is affecting our CI/CD process for 2GP unlocked packages.

[iowillhoit]

Hello all, I am looking into this. Will respond with more info shortly.

[iowillhoit]

Alright, this looks to be a bug. Changes were added to the toolbelt in 7.137.x to account for the new ancestor requirement for 2GP managed packages in 236 described here. I will reach out to the packaging team to look into this further. In the meantime, you should be able to use CLI version 7.136.2. Thanks for all the input!

[yippie]

We are hitting this too for unlocked packages now.

Even for managed packages this would be a complete disaster as we don't have, or want, our 2gp managed packages installed in our dev hub either!

[arafesthain]

Unable to create new package version too

[GodertC]

Facing the same issue here.

[honeyverma]

We are also facing the same issue in our CI-CD, while creating a package version

ERROR running force:package:version:create: Can’t create package version. The ancestor version [undefined] you specified isn’t the highest released package version. Set the ancestor version to 4.2.0, and try creating the package version again. You can also specify --skipancestorcheck to override the ancestry requirement.

[richsabel]

As a workaround, adding --skipancestorcheck to the SFDX package version create command allows a package to be created. Note that specifying the ancestorVersion for an unlocked package does not have the same effect.

[iowillhoit]

The packaging team is making good progress on this. We are hoping to have a hotfix of sfdx out tomorrow. I will respond back when it is ready. Thanks for your patience!

[andynuk]

It is great that this issue is being addressed but many of us have solid CD/CI processes that are always going to use the latest version of the cli as part of the docker image and process. Not being able to create unlocked package versions is a pretty critical process so a bug of this significance is a major loss of trust.

If there was the ability on sfdx update to limit to no higher than a specific version (or say specific stable milestones) this would present a very easy workaround for these significant issues and we could have this in our CD/CI processes. Perhaps this is a feature request that could be considered

[arafesthain]

As a workaround, adding --skipancestorcheck to the SFDX package version create command allows a package to be created. Note that specifying the ancestorVersion for an unlocked package does not have the same effect.

Didn't make any diff for us. Just prompting a fresh new error.

[richsabel]

As a workaround, adding --skipancestorcheck to the SFDX package version create command allows a package to be created. Note that specifying the ancestorVersion for an unlocked package does not have the same effect.

Didn't make any diff for us. Just prompting a fresh new error.

Yeah this only worked in unlocked packages that did not have package dependencies, where we had dependencies listed in our sfdx-project.json then it still errored.

[iowillhoit]

Hey @andynuk, I completely understand how frustrating it is when CI/CD breaks. Especially since it is often not trivial to update CI/CD scripts. The CLI team does create a weekly release candidate to help catch issues like this before they are promoted to latest. We have several internal and external customers that will use the release candidate locally (or in a separate CI process) to try to catch issues early.

Unfortunately, this was not caught until after the promotion to latest happened. If you want to use the RC in the future to help catch issues, it can be installed multiple ways and there are also RC docker images available.

We do not currently have a way to limit a "no higher than" install version like you describe, but you should be able to implement something fairly easily using environment variables so that you could easily modify this in CI without and code changes. Something like this for shell would use the env var if it is set or fallback to latest:

# Set $SFDX_VERSION_TO_INSTALL to 'latest' if unset (or null)
npm install -g sfdx-cli@${SFDX_VERSION_TO_INSTALL:=latest}

Hope this is helpful.

[iowillhoit]

This fix has been released under latest-rc version 7.138.1. See this documentation on how to install release candidates. Docker images are also available for the RC here.

Please try this out and let us know if you are still having issues. Thanks again for everyone's patience.

[iowillhoit]

Hello all, this fix has been included in today's stable release 7.138.1. Update to the latest sfdx to get these changes. Release notes can be viewed here. If you are still having issues, please reopen this issue.

[dschach]

I am having this issue - the packaging command isn't seeing the latest released package as the latest released package and is telling me to specify a different version.

This would prevent everyone who is currently using the latest released version from upgrading.

--skipancestorcheck breaks upgradeability for managed packages, so it is a non-starter for us.
@iowillhoit