Deployment plan still looks for a default package.xml

[gintoMathew]

Issue
I have set deployment plan with multiple package xmls; but when the pipeline executes, it errors out saying 'no such file or directory, open ./config/package.xml'

Here is how the .sfdx-hardis-yml looks like

projectName: hardisPOC
developmentBranch: dev_poc
deploymentPlan:
  packages:
    - label: Package One
      packageXmlFile: manifest/package-one.xml
      order: 1
    - label: Package Two
      packageXmlFile: manifest/package-two.xml
      order: 2

Command executed
sfdx hardis:project:deploy:sources:dx --check --testlevel RunRepositoryTests --debug

Expected
According to the documentation the deploy command, a default package.xml is not needed and the xmls in the deploymentPlan will be used to create a 'calculated-package.xml' for the deployment.

Additional Note
Does this command support deployment from a multi package source i.e, 'force-app' is broken into different projects with separate components.

[nvuillam]

@gintoMathew the default manifest/package.xml is looked for by default (and it added in the deployment plan with "0" position)

You can solve the issue by using such configuration:

projectName: hardisPOC
developmentBranch: dev_poc
deploymentPlan:
  packages:
    - label: Package One
      packageXmlFile: manifest/package.xml
      order: 0
    - label: Package Two
      packageXmlFile: manifest/package-two.xml
      order: 2

or even the following (the result will be the same, as manifest/package.xml is implicitely added

projectName: hardisPOC
developmentBranch: dev_poc
deploymentPlan:
  packages:
    - label: Package Two
      packageXmlFile: manifest/package-two.xml
      order: 2

If for some reason you don't want to have a main manifest/package.xml, please explain your use case and we'll see if we can make an update that will allow the command to work without it :)

[nvuillam]

@gintoMathew thanks for your feedback , I'm glad to know that sfdx-hardis works with multiple local packages :)

The only issues you could find could be about performances if you have too many metadatas, how long is taking a validation pieline ?

Do you use an integratiion with Github / Gitlab / Azure / Bitbucket PRs ? ( if so it will use QuickDeploy so improve your perfs)

https://sfdx-hardis.cloudity.com/salesforce-ci-cd-setup-integrations-home/

[gintoMathew]

We are using Github Actions and ,no performance issues for direct validation of a major branch to sandboxes.
One issue I have now is that for the a pull request, I am not able to validate the PR on a sandbox.

the .sfdx-hardis.yml file,

projectName: hardisPOC
developmentBranch: dev_poc
useDeltaDeployment: true
availableTargetBranches:
 - dev_poc
allowedOrgTypes:
 - sandbox

Here is what I am trying to do,
Pull request raised for -
Source branch - features/dev/feature1
into ->
Target branch - dev_poc

Here are the lines in the Action yml file

      # Login & check deploy with test classes & code coverage
      - name: Login & Simulate deployment
        env:
...
          CONFIG_BRANCH: ${{ github.event.pull_request.base.ref }} # Defines the target branch of the PR
...
        run: |
          echo "Simulate SFDX deployment using Hardis against \"$CONFIG_BRANCH\""
          sfdx hardis:auth:login
          sfdx hardis:project:deploy:sources:dx --check

Here is the error

[Warning] You may have to define targetUsername in config/branches/.sfdx-hardis.dev_poc.yml
Error: Proces completed with exit code 1.

The tergetUsername is already defined in the yml file

[nvuillam]

@gintoMathew to validate using a sandbox, you need to configure the sandbox associated to the git branch

In your case, you need to run hardis:project:configure:auth and enter dev_poc when the branch name is prompted

You can do it directly from your sub branch features/dev/feature1

Note: GitHub Workflows require to specify variable names , so you need to manually add the auth secret variables names in your check-deploy.yml and process-deploy.yml , using the variable names provided by the auth config command

Eample here

sfdx-hardis/defaults/ci/.github/workflows/check-deploy.yml

Line 54 in 333cf2d

SFDX_CLIENT_ID_INTEGRATION: ${{ secrets.SFDX_CLIENT_ID_INTEGRATION}}

[gintoMathew]

@nvuillam Thanks for the inputs.
This was the issue -
Our company has restrictions around how Github Actions run - the permissions, the environments set, checkouts made etc. I had to make some tweaks to the check-deploy.yml and process-deploy.xml files to make it work. The validation and deploy pipeline works as expected now (with Mega-linter).
Hoping to test this some more before we onboard all our team members to Hardis.

[nvuillam]

@gintoMathew i'm glad to know that you find workarounds :)

I have a problem with one of our clients using custom github action runners, and i had to disable MegaLinter, woukd you mind sharing your updated workflows in case it can help ? :)

(and also the check & deploy workflows, out of curiosity ^° )