Can't resume pre-validated deployment via quick-deploy in CI

[YodaDaCoda]

Summary

I have a CI job where a pre-validated deployment is quick-deployed. Calling sf project deploy quick works fine and returns the expected result, but I can't sf project deploy report, either with --use-most-recent (Error (1): There are no recent job IDs available. - indicating that project deploy quick doesn't store the resulting deployment id) or explicitly specifying the deployment id with --job-id (Error (1): No job found for ID: 0Af1y00000srNIqCAM.).

Steps To Reproduce

1. Deploy something to salesforce such that you get a pre-validated deployment that can be quick-deployed later.
   sf project deploy validate -m ApexClass:Cases -m ApexClass:CasesTest -l RunSpecifiedTests -t CasesTest
2. (In a separate execution context / on a different machine) Quick-deploy the resulting validated deployment
   sf project deploy quick --async --job-id 0Af1y00000srNIqCAM
3. Report on the progress of the quick-deployment
   sf project deploy resume --job-id 0Af1y00000srNIqCAM --wait 9999 - Error (1): No job found for ID: 0Af1y00000srNIqCAM.
sf project deploy resume --use-most-recent --wait 9999 - Error (1): There are no recent job IDs available.

Expected result

sf project deploy resume should be able to resume the quick-deploy using --use-most-recent
sf project deploy resume should be able to resume the quick-deploy using --job-id

Actual result

--use-most-recent produces error: Error (1): There are no recent job IDs available.
--job-id produces error: Error (1): No job found for ID: 0Af1y00000srNIqCAM.

System Information

CI is using bash, local machine is powershell 7

{   
  "cliVersion": "@salesforce/cli/1.85.8",
  "architecture": "win32-x64",
  "nodeVersion": "node-v18.16.1",
  "osVersion": "Windows_NT 10.0.22621",
  "shell": "cmd.exe",
  "rootPath": "C:\\Users\\will\\github\\rtba\\node_modules\\@salesforce\\cli",
  "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.85.8 (core)",
    "apex 2.3.3 (core)",
    "auth 2.8.3 (core)",
    "community 2.2.12 (user)",
    "data 2.4.1 (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)",
    "packaging 1.20.0 (user)",
    "schema 2.3.15 (core)",
    "settings 1.4.15 (core)",
    "sobject 0.1.29 (core)",
    "source 2.10.18 (core)",
    "telemetry 2.2.1 (core)",
    "templates 55.5.0 (core)",
    "trust 2.4.24 (core)",
    "user 2.3.19 (core)",
    "sfdx-git-delta 5.19.0 (user)",
    "sfdx-hardis 3.17.0 (user)"
  ]
}

Additional information

Interestingly, these commands work on my local machine. I suspect the issue is around the manifest cache - I can replicate the behaviour by deleting ~/.sf/deploy-cache.json before running project deploy quick.

By editing node_modules/@salesforce/plugin-deploy-retrieve/lib/commands/project/deploy/resume.js to pass false as the third parameter to the call to cache.resolveLatest(), I can get --job-id to work, but I have to run the command twice.

I find it interesting that a call to sf project deploy quick --json --job-id xxxx will spit out the same job id in the json output, rather than the new salesforce job id. This seems counter-intuitive to me and is not how I expect it to work.

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

[iowillhoit]

Hey @YodaDaCoda, it makes sense that you are seeing this. The results of the validate and quick commands store information in a local file. On a mac, this is located at $HOME/.sf/deploy-cache.json. The report and resume commands look up the deploy id from that cache. If those commands were ran on a different machine, the entries would not exist.

Worth noting that other information (not just the deploy id) is used from the cache to resume a deploy. Search for deployOpts in the resume command here. You could try extracting that cache from CI or checking on the deployment status in the UI (Setup > Deployment Status).

There are a few things we could potentially do to help support this use-case, we'll open a Github Discussion to explore some options (cc @mshanemc)

Thanks!

[mshanemc]

@YodaDaCoda here's a discussion--can you add your ideas/feedback there? #2300