search

forcedotcom / cli

Salesforce CLI
https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/
BSD 3-Clause "New" or "Revised" License
488 stars 78 forks source link

Deprecated `sfdx source/mdapi/org` commands will be removed on November 6th, 2024 #2974

Open VivekMChawla opened 1 month ago

VivekMChawla commented 1 month ago

What's Happening?

On November 6th, 2024, Salesforce will…

  1. Stop bundling plugin-source with the Salesforce CLI sf(v2).
  2. Remove the force:org:create and force:org:delete commands from plugin-org.

What's the Impact of This Change?

  1. force:source:* and force:mdapi:* commands will not be available for use with sf(v2).
    • Solution: Migrate to sf project/org commands (migration guide)
    • Workaround: Manually install plugin-source after installing the CLI.
  2. force:org:create and force:org:delete will not be available for use with sf(v2).
    • Solution: Migrate to sf org commands (migration guide)
    • Workaround 1: Manually install an older version of plugin-org after installing the CLI.
    • Workaround 2: Use a version of the CLI released before November 6th.

Why is Salesforce Making This Change?

  1. Standardizing the sf command syntax and structure is part of our strategic vision for sf(v2).
  2. Distributing deprecated code for a prolonged period increases complexity and technical debt for the CLI as a whole.
  3. A large majority of CLI users have already transitioned to the new commands.

Why is This Change Being Made Now?

We understand this will be a disruptive change for customers who postponed migrating away from the deprecated commands.

While there's never a "good" time for changes like this, we decided to make this change now because:

  1. The impacted commands have been deprecated for over a year.
  2. Tools and resources exist to help customers make this transition (see below)
  3. Workarounds exist for customers requiring additional time to make this change.

As mentioned in the "workaround" notes above, customers who need more than four months to migrate can pin themselves to the latest (stable) CLI version available on November 5th. Changes specific to Winter ’25 (e.g., support for new metadata types) will be incorporated into this version, giving it a reasonable "shelf life" beyond November 6th.

Additional Resources

Questions or Feedback?

Please share any questions or feedback by commenting on this issue.

avesolovksyy commented 2 weeks ago

@VivekMChawla To be able to switch to new style commands in a painless way, first of all feature-parity should be in place.

But as of now, is it possible to force new command sf project deploy start to ignore source tracking altogether, i.e. even if the target org has source tracking enabled? Maybe by setting some property or global env variable.

We would really like to have such option/feature to have 100% confidence that nothing will break in our CI process after switching to new commands, since we currently have ~100 sandboxes (that were created with source tracking supported, just in case so to say) and connected to our pipelines.

Or maybe you happen to know how to disable source tracking at sandbox level without refreshing/re-creating it? Open to any suggestions except the one involving refresh of 100 sandboxes)

VivekMChawla commented 2 weeks ago

@avesolovksyy - Thanks for your feedback and question!

@cristiand391 notes that we added a command to disable source tracking for operations against a specific org.

sf org disable tracking

Salesforce CLI stores the setting in the org's local configuration file so that no source tracking operations are executed when working with the org. This would be a reasonable option in long-lived developer environments that work with those sandbox orgs.

As for CI environments, if they don't require source tracking with any orgs, you can set the environment variable SF_DISABLE_SOURCE_MEMBER_POLLING=true.

Please try this and let us know if you still believe there's a feature-parity gap here.

avesolovksyy commented 2 weeks ago

@VivekMChawla Thanks a lot for quick response and provided suggestions - we have tried both of them.

sf org disable tracking works perfectly, although it is inconvenient to prefix every sf project deploy start command in every CI job with this command - but I unerstand that CI is not the main use case for sf org disable tracking.

Setting up SF_DISABLE_SOURCE_MEMBER_POLLING=true doesn't work at all, i.e. it is still trying to pull for SourceMembers at the end of successful deploy, basically no difference with previous behaviour when no variable is set: image

But then we just updated name of variable to use older SFDX prefix, i.e. SFDX_DISABLE_SOURCE_MEMBER_POLLING=true, naturally we got a warning re usage of deprecated variable, but eventually it started ignoring source tracking:

image

No polling for SourceMembers as you can see below: image

To be on the safe side we've decided to set up both in our final implementation, but seems like there is some issue with supporting SF_DISABLE_SOURCE_MEMBER_POLLING variable:

export SF_DISABLE_SOURCE_MEMBER_POLLING="true"
export SFDX_DISABLE_SOURCE_MEMBER_POLLING="true"

While doing these experiments we were using latest avaialbe sf cli version @salesforce/cli@2.56.7 installed into ubuntu-latest docker image. And test sandbox with source tracking enabled was upgraded to Winter 25 (i.e. api version 62.0) just rigth before we started our experiments.

To summarize, setting global variables seems to be working fine and has solved our current challenge (but still need to monitor logs for next few days), we just need some clarification re which variable name to stick with.

avesolovksyy commented 2 weeks ago

@VivekMChawla We have bumped into one more difference in behaviour of sf project deploy start VS sf force source deploy commands that is creating challenges for us.

In our CI scripts quite often we are creating an adhoc temporary directory and copying there some metadata to be deployed. Nothing special just mktemp -d command in bash + some subdirectory beneath it. So the final path that is passed to sf project deploy start command looks something like this: /tmp/tmp.QhJxv99Xpy/02-meta-enableSettings

sf project deploy start -d "/tmp/tmp.QhJxv99Xpy/02-meta-enableSettings" -o myTestOrg ...

But we are running this deployment when current directory is pointing to our project checkout. And it seems like sf project deploy start internally converts absolute path to some relative one, i.e. how to get from current directory to directory with metadata to be deployed. Not a problem, but then it throws an error complaining about unsafe path due to these '..', as on screenshot below. But again we are passing an absolute path, these '..' have appeared as result of internal path conversion.

image

Error (MetadataTransferError): Metadata API request failed: The filepath "../../../../../tmp/tmp.QhJxv99Xpy/02-meta-enableSettings/settings/FieldService.settings-meta.xml" contains unsafe character sequences

Have something like this been already reported? Any suggestions how to deal with it at a large project scale, i.e. without changing current directory before running sf project deploy start command etc.

avesolovksyy commented 2 weeks ago

@VivekMChawla When trying to apply naive workaround like this, i.e. navigating to tmp deploy dir and run command already from that dir as current:

pushd $ourTmpDirWithMetadataToBeDeployed
sf project deploy start -d . -o myTestOrg
popd

We are getting the following error complainig about lack of SF DX project structure: image

Any suggestion how can we just deploy simple directory with metada from outside of our current project checkout? I don't want to generate every time temporary sfdx project just to do adhoc deploy. There is no problem like that when using sf force source deploy command.

nvuillam commented 2 weeks ago

If it can help readers, here is the list of all commands I migrated for the next version of sfdx-hardis :)