2

we have an unlocked package which we deploy via GitLab CI/CD. The deployment went well until we added the required --codecoverage to the gitlab-ci.yml, which we got from the official salesforce gitlab.

Unlike here we don't have problems with code deployment, and the code coverage is around 80%.

The pipeline has multiple steps:

  • Create a scratch org and deploy metadata
  • Run tests
  • Create a package version <- This one fails
  • Deploy package on dev sandbox
  • Deploy package on staging sandbox (manual)
  • Deploy package on production (manual)

The used command is the following:

sfdx force:package:version:create --targetdevhubusername DEVHUB --package <Package ID> --versionnumber 1.25.0.NEXT --installationkeybypass --wait 10 --codecoverage --json

We also checked sfdx force:package:list --targetdevhubusername <DevHubAlias> and the package is there.

sfdx-project.json:

{
    "packageDirectories": [
        {
            "path": "force-app",
            "package": "<packageName>",
            "versionName": "White Tulip",
            "versionNumber": "1.0.0.NEXT",
            "default": true
        }
    ],
    "namespace": "",
    "sourceApiVersion": "47.0",
    "packageAliases": {
        "<packageName>": "<packageId>"
    }
}

The last version deployed was 1.24.0.1. Does anyone have an idea what went wrong?

EDIT:

We tried to get more information by running sfdx force:package:version:create:report -i <requestId> --targetdevhubusername <username>. This lead us to the following error:

=== Errors
(1) Apex Test Failure: Class.<class>.<method>: line 137, column 1
Class.<class>.<method>: line 58, column 1
Class.<class>.<method>: line 100, column 1 System.UnexpectedException: Apex approval lock/unlock api preference not enabled.

(changed class and method names) which is a bit strange, because when we checked all used orgs, the setting was enabled on all of them.

2
  • Can you check if you are connected to right DevHub org from gitlab CI? Feb 11, 2021 at 13:16
  • We are using the authurl we got when issuing ' sfdx force:org:display -u <DevHubAlias> --verbose' as a CI variable.
    – Sam W.
    Feb 11, 2021 at 16:26

4 Answers 4

0

As discussed on the developer forum, the problem was solved by giving the below force:package:version:create command

sfdx force:package:version:create --targetdevhubusername DEVHUB --package <Package ID> --versionnumber 1.25.0.NEXT --installationkeybypass --wait 10 --codecoverage --json -f config/project-scratch-def.json

And by ensuring that Apex Setting ApexApprovalLockUnlock is added under OrgPreferenceSetttings in the definition file

I will pass on the feedback around including this in the documentation

1
  • How do you add the Apex Setting ApexApprovalLockUnlock under OrgPreferenceSetttings in the definition file?
    – compski
    Jul 13, 2023 at 9:40
0

The problem was solved by a Salesforce engineer. The solution was the following:

This error is due to the Apex Setting "ApexApprovalLockUnlock" so while creating package version it is advised to define scratch org definition file like this - sfdx force:package:version:create --targetdevhubusername DEVHUB --package <Package ID> --versionnumber 1.25.0.NEXT --installationkeybypass --wait 10 --codecoverage --json -f config/project-scratch-def.json and make sure this Apex Setting under OrgPreferenceSetttings added in the definition file - https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_orgpreferencesettings.htm?search_text=ApexApprovalLockUnlock

0

I had the same issue, the generic error didn't tell me much "no subscriber package version found..." but when I tried to list the packages using:

sfdx force:package:list

I got the actual error which was:

Error (1): Error authenticating with the refresh token due to: ip restricted
0

Two additional causes of this error message when running the newer sf package install:

  • omitting the Installation Key if one was provided during package version creation
  • providing the wrong Installation Key

Interestingly, if you add the -b | --publish-wait flag (e.g., -b 10), the command will instead fail with the error message, "The subscriber package version is not fully available," and then it will output a "try this" message which explains the issue, for example:

Please provide installationkey when querying against SubscriberPackageVersion that is protected by installationkey

Invalid InstallationKey for SubscriberPackageVersion

I think for now I will include -b with all of my package install commands.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .