Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sourceSandboxName in developer-sandbox-def.json ignored in sandbox clone #3036

Closed
stafik opened this issue Sep 27, 2024 · 4 comments
Closed
Labels
validated Version information for this issue has been validated

Comments

@stafik
Copy link

stafik commented Sep 27, 2024

Summary

Cloning developer sandboxes using SF CLI and the --definition-file flag still creates a sandbox from production org.

Steps To Reproduce

Prerequisite: having a developer sandbox (sandbox name: dev1)

  1. Create a config/developer-sandbox-def.json file as described at the very bottom of https://developer.salesforce.com/docs/atlas.en-us.250.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_sandbox_definition.htm. It should look as follows:
{
    "sandboxName": "dev1clone",
    "sourceSandboxName": "dev1"
}
  1. Run sf org create sandbox --definition-file config/developer-sandbox-def.json --alias dev1clone --target-org productionAlias --no-prompt

I generated a new project using sf project generate and committed here - link. There's actually only the developer-sandbox-def.json file committed and relevant.

Expected result

A new sandbox (name: dev1clone) is being created and it's a copy of dev1 existing sandbox.

Actual result

A new sandbox (name: dev1clone) is being created and it's a copy of production.

Additional information

I fiddled around with different combinations of developer-sandbox-def.json settings and sf org create sandbox flags. The sourceSandboxName json setting seemed to be always ignored, no matter what.
On the other hand, when I run
sf org create sandbox --definition-file config/developer-sandbox-def.json --alias dev1clone --target-org productionAlias --no-prompt --clone dev1 (I added the -clone dev1 flag), it resulted in creating a cloned sandbox correctly. No matter if the sourceSandboxName was present in developer-sandbox-def.json or not.

To sum up, I got to the conclusion that --clone flag has always worked well but sourceSandboxName setting in developer-sandbox-def.json file has had totally no effect.

Here are two more SF CLI output examples. In both cases developer-sandbox-def.json looks like described in the Steps To Reproduce section above (it includes "sourceSandboxName": "dev1").
The only difference between them is that there's a SourceId 0GQ1i000000TQESGA4 line when I used the --clone dev1 flag.

$ sf org create sandbox --definition-file config/developer-sandbox-def.json --alias dev1clone --target-org productionAlias --no-prompt
Sandbox Create... 00:30:00 until timeout. 0%
 Field         Value                        
 ───────────── ──────────────────────────── 
 Id            0GRW60000000F3tOAE           
 SandboxName   dev1clone                    
 Status        Pending                      
 LicenseType   DEVELOPER                    
 SandboxInfoId 0GQW600000006i9OAA           
 Created Date  2024-09-27T11:30:18.000+0000 
 CopyProgress  0%                           
---------------------
Sandbox Create Stages
… - Pending
… - Processing
… - Activating
… - Authenticating
$ sf org create sandbox --definition-file config/developer-sandbox-def.json --alias dev1clone --target-org productionAlias --no-prompt --clone dev1
Sandbox Create... 00:30:00 until timeout. 0%
 Field         Value                        
 ───────────── ──────────────────────────── 
 Id            0GRW60000000F5VOAU           
 SandboxName   dev1clone                    
 Status        Pending Remote Creation      
 LicenseType   DEVELOPER                    
 SandboxInfoId 0GQW600000006lNOAQ           
 Created Date  2024-09-27T11:33:40.000+0000 
 CopyProgress  0%                           
 SourceId      0GQ1i000000TQESGA4           
---------------------
Sandbox Create Stages
… - Pending
… - Processing
… - Activating
… - Authenticating

System Information

I've noticed the issue using Windows 10 & Powershell 7, as well as in cloud GitLab pipelines using Bash.

{
  "architecture": "linux-x64",
  "cliVersion": "@salesforce/cli/2.59.6",
  "nodeVersion": "node-v20.17.0",
  "osVersion": "Linux 5.15.0-1045-aws",
  "rootPath": "/usr/app/.npm-global/lib/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.3 (core)",
    "@oclif/plugin-commands 4.0.14 (core)",
    "@oclif/plugin-help 6.2.11 (core)",
    "@oclif/plugin-not-found 3.2.20 (core)",
    "@oclif/plugin-plugins 5.4.7 (core)",
    "@oclif/plugin-search 1.2.8 (core)",
    "@oclif/plugin-update 4.5.6 (core)",
    "@oclif/plugin-version 2.2.12 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.15 (core)",
    "@oclif/plugin-which 3.2.13 (core)",
    "@salesforce/cli 2.59.6 (core)",
    "apex 3.4.9 (core)",
    "api 1.2.1 (core)",
    "auth 3.6.56 (core)",
    "data 3.6.5 (core)",
    "deploy-retrieve 3.12.7 (core)",
    "info 3.4.6 (core)",
    "limits 3.3.30 (core)",
    "marketplace 1.2.25 (core)",
    "org 4.5.8 (core)",
    "packaging 2.8.4 (core)",
    "schema 3.3.29 (core)",
    "settings 2.3.19 (core)",
    "sobject 1.4.[35](https://[EDITED]/-/jobs/3434331#L35) (core)",
    "source 3.5.19 (core)",
    "telemetry 3.6.12 (core)",
    "templates 56.3.18 (core)",
    "trust 3.7.27 (core)",
    "user 3.5.29 (core)",
    "sfdx-git-delta 5.45.0 (user) published 7 days ago (Fri Sep 20 2024)"
  ]
}

Thank you very much for your help!

@stafik stafik added the investigating We're actively investigating this issue label Sep 27, 2024
Copy link

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 github-actions bot added the validated Version information for this issue has been validated label Sep 27, 2024
@WillieRuemmele
Copy link
Member

Hi @stafik - thanks for reporting this. We're looking into it, and agree that it's a little weird. We're looking at how to make it work more like org create scratch where the flags can override what's in the file, or updating how the --clone flag works, but this could also be a breaking change.

@WillieRuemmele
Copy link
Member

W-16883274

@WillieRuemmele WillieRuemmele removed the investigating We're actively investigating this issue label Oct 2, 2024
@cristiand391
Copy link
Member

this was fixed (and added 2 new source flags) in RC if you want to give it a try:
https://github.com/forcedotcom/cli/tree/main/releasenotes/#2667-november-13-2024-stable-rc

will be promoted to stable next Wednesday.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
validated Version information for this issue has been validated
Projects
None yet
Development

No branches or pull requests

3 participants