Success Pull Request Comment is not send, while errors are working fine

[0ptaq0]

I am using sfdx hardis in my custom Gitlab pipeline.
Pipelines are running bounded to Merge Requests, 'Enable merged results pipelines' option is enabled >>
"This pipeline ran on the contents of the merge request combined with the contents of the target branch"

I have added following env variables:

• CI_SFDX_HARDIS_GITLAB_TOKEN
• MS_TEAMS_WEBHOOK_URL
• JIRA_TOKEN
• JIRA_HOST
• JIRA_EMAIL
• JIRA_TICKET_REGEX
• JIRA_PAT = $JIRA_HOST //as we use JIRA Cloud version
• CONFIG_BRANCH: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
• ORG_ALIAS: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
• DEPLOY_BRANCHES: /^(dev|sit|stage|production)$/

My validation/deployment command looks almost the same, only difference is --checkonly flag:

sfdx hardis:source:deploy --checkonly \
        --wait 300 \
        --testlevel $TEST_LEVEL \
        --manifest 'dx-delta/package/package.xml' \
        --ignorewarnings \
        --postdestructivechanges 'dx-delta/destructiveChanges/destructiveChanges.xml' \
        --verbose \
        --checkcoverage \
        --coverageformatters json-summary \
        --targetusername $SF_USERNAME

During deployment I would expect some success message posted to Merge Request comment and optionally to related JIRA in MR's description, but I am getting below:

Total Test Time:  3869366
=== Coverage or Junit Result Report Locations
Code Coverage formats, [json-summary], written to 0Af9X00000Zej0fSAB/coverage
Deploy Succeeded.
[sfdx-hardis] No commandsPostDeploy found to run
[sfdx-hardis] {"noPrData":""} && [object Object] && false
[sfdx-hardis] [Git Provider] Skip post pull request comment
[sfdx-hardis] hardis:source:deploy execution time 1:09:24.093

However, posting error comments works just fine:

Error (1): Deploy failed.
No sfdx-hardis tip to solve this error. Try google ?
[sfdx-hardis] No commandsPostDeploy found to run
[sfdx-hardis] [Git Provider] Try to post a pull request comment/note...
[sfdx-hardis] [Gitlab integration] Listing Notes of Merge Request...
[sfdx-hardis] [Gitlab integration] Adding Merge Request Note on Gitlab...
[sfdx-hardis] hardis:source:deploy execution time 0:07:17.252

And then I can see a comment with great tips on how to solve errors ;)

Also, nothing is posted to JIRA but that's a minor item, I would just need a success comment to Merge Request at this moment.

What am I missing?

[nvuillam]

@0ptaq0 that might be a bug :)
I investigate :)

[nvuillam]

There are many sfdx-hardis features embedded within hardis:project:deploy:sources:dx, including JIRA ones.

hardis:source:deploy currently only embeds the errors comment.

The corresponding call of your use case would be the following:

sfdx hardis:project:deploy:sources:dx --check \
        --packagexml 'dx-delta/package/package.xml' \
        --testlevel $TEST_LEVEL \
        --targetusername $SF_USERNAME

you would also need to define the following variables in your gitlab-ci.yml

  variables:
    SFDX_DEPLOY_WAIT_MINUTES=300
    PACKAGE_XML_TO_DELETE=dx-delta/destructiveChanges/destructiveChanges.xml

Please can you try to check if it works on your project ? :)

[nvuillam]

Additional note: after merge, if you use the following script, you will benefit of QuickDeploy :)

sfdx hardis:project:deploy:sources:dx \
        --packagexml 'dx-delta/package/package.xml' \
        --testlevel $TEST_LEVEL \
        --targetusername $SF_USERNAME

[0ptaq0]

Thank you Nicolas, JIRA integration now works like a charm :)

Regarding packagexml I needed to place it under ./manifest folder

I have only one issue with destructive changes, the env var PACKAGE_XML_TO_DELETE does not seem to take any effect. Also, like with packagexml I placed destructiveChanges.xml under ./manifest but also had no success, neither on validation nor deployment.

[sfdx-hardis] Empty package.xml: nothing to deploy
[sfdx-hardis] No deployment to perform
[sfdx-hardis] hardis:project:deploy:sources:dx execution time 0:00:06.365

My flow looks like this:

1. Open Merge Request -> Validation starts
2. Collecting approvals on peer code review
3. Manually click Run Pipeline button on Merge Request which initiates deployment
4. If Deployment is successful, then Merge Request is merged

SFDX Git Delta creates a diff package and package.xml + destructiveChanges.xml which I then archive and pass to sfdx-hardis.

Also as mentioned above I am using custom CICD and embedded sfdx-hardis so I do not have any .sfdx-hardis.yml in my repository, that may also be an issue?

As a workaround, I can also check if destructive Changes are not empty and then call yet another sfdx deployment command, but the best would be to fit everything in one shot ;)

[nvuillam]

@0ptaq0 do you know that sfdx-git-delta is also embedded within sfdx-hardis and project:source:deploy:dx ? :)

https://sfdx-hardis.cloudity.com/salesforce-ci-cd-config-delta-deployment/

I'm wondering if you are not trying to reproduce the standard sfdx-hardis pipeline :)

https://github.com/hardisgroupcom/sfdx-hardis/blob/main/defaults/ci/.gitlab-ci.yml

https://github.com/hardisgroupcom/sfdx-hardis/blob/main/defaults/ci/.gitlab-ci-config.yml

Can you compare with your pipeline ?

I feel the only difference is that

• the deployment validation job is automatically run with sfdx-hardis when you create a MR
• when you merge the MR, the deployment is processed (using QuickDeploy for better perfs ^^)

If you want, please share your gitlab-ci.yml and i'll tell you :)

[0ptaq0]

Hi Nicolas,

I made it work to some extent.
I believe the issue was with using --packagexml 'dx-delta/package/package.xml' \ argument along with sfdx hardis:project:deploy:sources:dx commands.
When I removed it and simply copy pasted package XML and destructiveChanges XML under the manifest folder it started to work.

My commands are:

        mkdir -p manifest
        cp dx-delta/package/package.xml manifest/
        cp dx-delta/destructiveChanges/destructiveChanges.xml manifest/

        sfdx hardis:project:deploy:sources:dx --check --debug \
        --testlevel $TEST_LEVEL \
        --targetusername $SF_USERNAME

I have a slight difference compared to your standard sfdx-hardis pipeline, as you do merge 1st, and 2nd is a quick deploy, while I want to do the opposite - 1st deploy if that succeeds, merge the Pull/Merge Request.

Is there any chance to add some flag in the future for sfdx-hardis to support this "opposite" approach that I am using?
So when using sfdx hardis:project:deploy:sources:dx --check it will place Deployment ID as a comment in merge request, BUT then when using sfdx hardis:project:deploy:sources:dx it will search for deployment ID NOT via CI_COMMIT_REF_NAME (source branch) but via CI_MERGE_REQUEST_TARGET_BRANCH_NAME or some other variable in the public async getBranchDeploymentCheckId method. I believe there are more features like success comments to MR after deployment finish which I am lacking because of my unusual approach.

I am not a Typescript expert so I don't feel comfortable with opening my Pull Request to sfdx-hardis to support that ;)

[nvuillam]

@0ptaq0 i'm not a DevOps expert (anyway, not more than I am a Salesforce expert), but deploying before merging the Pull Request feels like a really strange pattern ^^

Imagine, for example if you have conflicts you'll have deployed in target org before merging them

If you need deployment success messages, with current pattern you can already have them with Slack/Teams/Email notifications

I'm ok with exotic behaviors if they are triggered only in case some specific parameter or env var is set, but I'm not sure i've understood everything that you need, maybe you'd like to post a schema to explain ? :) ( like a draw.io for example )

[0ptaq0]

When there is a conflict no validation, or deployment will be triggered.
I will create some drawings and present them to you, it may sound exotic but I have worked with this approach successfully for more than 4 implementations, including one that had circa 80 developers in peak time working together, so it is not only a theory.

[nvuillam]

@0ptaq0 great, don't bother detailing a lot, just a few boxes with arrows between them will do :)

And I never had 80 developers in parallel on the same project (we are mostly middle market at Cloudity), so I might learn a thing a 2 from your approach for when we'll catch bigger accounts :)

[0ptaq0]

I am having something like this in Gitlab: (main branch is just example)

So everything works well with hardis until the last point.

After I posted I realized that there will be cases when I have multiple quick deploys available for different merge requests - if the approach with deploy before merge would be supported, that would be great to just get deploy-id from the Merge Request, no need to look at latest merge requests to CI_COMMIT_REF_NAME as it is now (at least that is what I understood from source code)

Happy to explain more if some step is not clear ;)

And regarding that big project - I wasn't the only DevOps, I was part of a great team of 5-8 DevOps engineers so we somehow managed it :D

[nvuillam]

Ok I get it, interesting :)

So basically, all you need is to be able to get the "QuickDeploy" deploymentId from the current MR and not try to get it in the latest merged MR comments ? :)

[0ptaq0]

Haha, yes, but not only, I also see some notifications after deployment, like JIRA labels, MR comments after deployment etc.
These are based on the source branch (CI_COMMIT_REF_NAME) and therefore not working in my scenario

[nvuillam]

hmmmm I'll see what I can do, while you use hardis:project:deploy:dx I think we will find a way if you add some variable SFDX_HARDIS_DEPLOY_BEFORE_MERGE=true ^^

[0ptaq0]

Oh yes, that would be perfect, thanks in advance Nicolas!
Should I close the issue now or you want it to keep it open for tracking the above idea?

[nvuillam]

let's keep it open, that's where I'll ask you for some tests :)

[nvuillam]

@0ptaq0 if we are lucky I think that #649 could do the job for Quick Deploy + Slack / Teams / Jira notifications :)

Please can you test with sfdx-hardis@alpha and tell me if it works ? :)

• sf plugins install sfdx-hardis@alpha
• or docker image hardisgroupcom/sfdx-hardis:alpha

Define SFDX_HARDIS_DEPLOY_BEFORE_MERGE=true in your env vars :)

[0ptaq0]

Wow! Many Thanks @nvuillam for such a quick action.
I have tested it and I can say it works like a charm.
Quick deploy ID was taken from the Open Merge Request, notifications went through to Jira and MS Teams.
I can now work with my exotic flow ;)

THANKS AGAIN!!

[nvuillam]

@0ptaq0 i'm glad your use case works :)

Modular architecture was almost ready to handle your use case (that you described very well), so it wasn't that long :)

I'll release the update in an official version tonight ^^

Ps: if you like to post, don't hesitate to post about sfdx-hardis 😇

[0ptaq0]

No worries, when I will be creating some tip or post for BeyondTheCloud I will surely mention sfdx-hardis

feature suggested, feature implemented in hours - I love it ;)

[nvuillam]

@0ptaq0 Oh you are from BeyondTheCloud 🤩
I'm a fan of the blog :)

Would be great to appear on it indeed 🙃

[nvuillam]

@0ptaq0 released in https://github.com/hardisgroupcom/sfdx-hardis/releases/tag/v4.46.0 :) (latest)

Have fun :)

[0ptaq0]

Thank you @nvuillam

Great to hear you like BeyondTheCloud, we trying our best :D