Conflicts between local & remote since migration to sf project deploy quick

[jcarmignani]

Summary

sf project deploy quick command is often reporting a conflict between local and remote
sf project deploy quick --job-id $QUICK_DEPLOY_ID --target-org $CI_ENVIRONMENT_NAME --wait 60

It was not happening when using sfdx equivalent command
sfdx force:source:deploy --ignore-conflicts --wait 60 -q $QUICK_DEPLOY_ID -u $CI_ENVIRONMENT_NAME

I have tried to add the add the ignore conflicts flag as suggested but still the same
Error (1): There are changes in the org that conflict with the local changes you're trying to deploy. Try this: To overwrite the remote changes, rerun this command with the --ignore-conflicts flag. sf To overwrite the local changes, run the "sf project retrieve start" command with the --ignore-conflicts flag.

This workaround is not mentioned in the official documentation

Steps To Reproduce

Previous validate the deployment and then deploy using a Job ID

Expected result

Can override the conflicts

Actual result

Cannot override

System Information

Using a Gitlab runner running on Ubuntu

mkdir sfdx
CLIURL=https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-linux-x64.tar.xz
wget -qO- $CLIURL | tar xJ -C sfdx --strip-components 1
export PATH=./sfdx/bin:$PATH

sfdx --version
sfdx-cli/7.208.10 linux-x64 node-v18.15.0

sfdx plugins --core
You acknowledge and agree that the CLI tool may collect usage information, user environment, and crash reports for the purposes of providing services or functions that are relevant to use of the CLI tool and product improvements.

@oclif/plugin-autocomplete 2.3.1 (core)
@oclif/plugin-commands 2.2.16 (core)
@oclif/plugin-help 5.2.10 (core)
@oclif/plugin-not-found 2.3.26 (core)
@oclif/plugin-plugins 3.1.5 (core)
@oclif/plugin-search 0.0.17 (core)
@oclif/plugin-update 3.1.21 (core)
@oclif/plugin-version 1.3.5 (core)
@oclif/plugin-warn-if-update-available 2.0.40 (core)
@oclif/plugin-which 2.2.22 (core)
apex 2.3.3 (core)
auth 2.8.4 (core)
community 2.3.3 (core)
custom-metadata 2.1.28 (core)
data 2.4.2 (core)
deploy-retrieve 1.13.3 (core)
info 2.6.24 (core)
limits 2.3.22 (core)
org 2.9.17 (core)
packaging 1.20.1 (core)
schema 2.3.15 (core)
settings 1.4.15 (core)
sfdx-cli 7.208.10 (core)
signups 1.4.22 (core)
source 2.10.19 (core)
telemetry 2.2.1 (core)
templates 55.5.0 (core)
trust 2.4.24 (core)
user 2.3.19 (core)

Additional information

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

[github-actions]

Hello @jcarmignani 👋 It looks like you didn't include the full Salesforce CLI version information in your issue.
Please provide the output of version --verbose --json for the CLI you're using (sf or sfdx).

A few more things to check:

• Make sure you've provided detailed steps to reproduce your issue.
  • A repository that clearly demonstrates the bug is ideal.
• Make sure you've installed the latest version of Salesforce CLI. (docs)
  • Better yet, try the rc or nightly versions. (docs)
• Try running the doctor command to diagnose common issues.
• Search GitHub for existing related issues.

Thank you!

[jcarmignani]

{
  "cliVersion": "@salesforce/cli/1.86.1",
  "architecture": "linux-x64",
  "nodeVersion": "node-v18.15.0",
  "osVersion": "Linux 5.15.0-1038-aws",
  "shell": "bash",
  "rootPath": "/builds/odaseva-frontend/odaseva-salesforce/sfdx/sf",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.1 (core)",
    "@oclif/plugin-commands 2.2.16 (core)",
    "@oclif/plugin-help 5.2.10 (core)",
    "@oclif/plugin-not-found 2.3.26 (core)",
    "@oclif/plugin-plugins 3.1.5 (core)",
    "@oclif/plugin-search 0.0.17 (core)",
    "@oclif/plugin-update 3.1.21 (core)",
    "@oclif/plugin-version 1.3.5 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.40 (core)",
    "@oclif/plugin-which 2.2.22 (core)",
    "@salesforce/cli 1.86.1 (core)",
    "apex 2.3.3 (core)",
    "auth 2.8.4 (core)",
    "data 2.4.2 (core)",
    "deploy-retrieve 1.13.3 (core)",
    "info 2.6.24 (core)",
    "limits 2.3.22 (core)",
    "login 1.2.13 (core)",
    "org 2.9.17 (core)",
    "schema 2.3.15 (core)",
    "settings 1.4.15 (core)",
    "sobject 0.1.29 (core)",
    "source 2.10.19 (core)",
    "telemetry 2.2.1 (core)",
    "templates 55.5.0 (core)",
    "trust 2.4.24 (core)",
    "user 2.3.19 (core)"
  ]
}

[iowillhoit]

Hey @jcarmignani, I am not able to replicate this issue. With a fresh copy of Dreamhouse, I am running:

sf project deploy validate --source-dir force-app
and then running
sf project deploy quick --job-id THE PROVIDED_ID

I also tried changing metadata both locally and in the org between the validate and deploy quick commands to see if something was wrong with that. Could you please try creating a fork of Dreamhouse and provide the exact steps/commands you are using to replicate the issue?

Thanks

[jcarmignani]

Hello @iowillhoit Same on my side. I have forked your repository but I cannot reproduce using Dreamhouse project.

The only thing I can tell is that it happens under the following context under this context:

• A Patch branch is created from the Prod branch in Gitlab
• Some commits are done in this branch (Commits are signed)
• A Gitlab pipeline is triggered to deploy the commits on the Patch environment
• A validation job is triggered on this branch on the Production org
• Then when the patch is validated all the commits are merged into the Prod branch
• A Quick deploy is triggered from Gitlab using the Package ID from Gitlab from the Prod branch
• Getting conflicts

From what I have seen it is happening weirdly when we are dealing with the Patch environment that is not part of the standard pipeline we have.

Also something weird I observed several times is that I can do a validate on the Patch org running all the tests but them when I launch a deploy on the same org running all the tests I have a conflict and it requires to add the flag to ignore the conflicts.

The point is that I have more than 700 tests to run so I really need to use the quick deploy as it takes time to validate all of them when I have the Go to push to Production

I also can tell you that triggering the Quick deploy from Salesforce with my User is perfectly working.

Is it plan to have the ignore conflicts flag on the quick deploy sf command at one point as it used to be possible with SFDX (See above)

[iowillhoit]

Thanks for the additional info. I've tried several more things and I am still unable to reproduce this on my end.

I find it strange that the quick command is hitting source tracking. If you look at the source for the quick command, there are no calls to source-tracking or source-deploy-retrieve, it just calls straight into jsforce with deployRecentValidation. Even the error message itself seems to be coming from deploy start and not deploy quick. Here is the error message, here are references to error.Conflicts.

A few questions and suggestions:

• Please confirm that you are not using deploy start or retrieve start anywhere in your pipelines
• What type of an env is your Patch environment?
• Can you try adding the --dev-debug flag to your quick command and providing the results?
• You could potentially work around this by running the sf project reset tracking command before the quick deploy. Although this may not be desired
• You could try manually toggling the tracksSource property in the orgs auth file located in ~/.sfdx prior to the deploy

[jcarmignani]

@iowillhoit Thanks for your answers. Just to be clear with the several issues because I made a confusion on my side as well.

Patch environment:

• Type: Sandbox / Developer Pro
• sf deploy validate works but not sf deploy start reports some conflicts => Today I have added the --ignore-conflits flag and it is working fine
• We have the deploy start on the pipeline but it is a manual job and the sf deploy validate is triggered before

The quick deploy for which I have created the issue is in fact the Production org:

• Triggered a sf quick deploy that has completed in around 30 secs. Normally it is taking between 6 and 8 minutes.
• While looking at the Deploy status in Production we have seen that the validate was there but no trace of quick deploy
• That's the first time we use sf quick deploy. Before we were using sfdx force:source:deploy -q
• sf quick deploy is quite verbose compared to the previous command. Before it was just adding 3 lines to the Terminal
• CLI is listing files with Unchanged and Changed keywords added at the beginning of each file deployed => Maybe normal. It is why you recommend to add --concise?

To answer your questions:

• We do not use retrieve start. Git is the source of truth so nothing retrieved from the Org
• I have added the --dev-debug to the pipeline. We will surely redeploy on Production next week so I will be able to tell you if we can reproduce the issue again
• I am not adding sf project reset tracking so I can give you the logs when I will have more to provide but thanks for the suggestion
• Do you have a doc explaining the tracksSource parameter on the Org Auth file. For info we authenticate the org using JWT as it is Gitlab integration

I hope it is more clear now and sorry again for the confusion. I will update you next week after the quick deploy (or before if it happens before).