New answers tagged deployment
2
There is --validatedeployrequestid or -q flag for force:mdapi:deploy
-q, --validateddeployrequestid=validateddeployrequestid request ID of the validated deployment to run a Quick Deploy
To run quick deploy of a recently validated package, use -q with the validated ID.
sfdx force:mdapi:deploy -q <validationRequestId> -w -1
...
0
Once tactic that worked for me is this and you can do this while the flows are active:
Do a source retrieve from the org in which you would like to deploy the flows and only retrieve the flow metadata with a source retrieve command
sfdx force:source:retrieve --targetusername SomeSandbox -m Flow
Then you should be able to complete your deployment using ...
0
To deploy to production using the CLI:
Deploy a Class with specific Test Class (ApexClass:MyCless = metadatatype:fileName)
sfdx force:source:deploy -m ApexClass:MyCless -l RunSpecifiedTests -r TestClass -u ConnectedOrg
Deploy Classes with specific Test Classes (comma Separated metadatatype:fileName,metadatatype:fileName)
sfdx force:source:deploy -m ...
0
According to description in documentation :
Note: KAVs, attempting to explicitly specify UiBehavior will result in an exception.
This means that field <behaviour> tag is not allowed in Knowledge Article layout metadata.
There seems to be some limitation and there is also an Idea about this.
You could consider deploying this change as a manual ...
0
We use Solenopsis for deployments at my job. You should be able to create a zip with all the components you want to validate and then leverage deploy-zip [zip_file] --dryrun to check for deployment errors.
0
When this happens you can, using the CLI, get the id of the object in question using sfdx force:data:soql:query -q "Select Id, MemberName From SourceMember Where MemberType = 'CustomApplication'" -t. Then use the Id from that query like below.
sfdx force:data:record:delete -s SourceMember -i 0MZ0x000001eqiJGAQ -t
1
Use namespace__ApexClass as the apexClass format in PermissionSetApexClassAccess for Apex Classes belonging to a managed package or in a namespaced org. (Rather than namespace.ApexClass used in all other managed Apex references.)
The only documentation I can find regarding PermissionSetApexClassAccess says the following which isn't helpful.
apexClass: ...
3
Yes, all tests will be forced to run, since the code base is being altered. In addition, all classes will be recompiled to ensure that nothing is broken as a result of the deployment.
1
Have you tried this inside your YAML file?
task: Ant@1
inputs:
workingDirectory: ''
Options: -verbose -Dsalesforce.url=$(sf.url),Dsalesforce.password=$(sf.password),Dsalesforce.username=$(sf.username)
Check out the following video because it is using Ant Migration Tool with AzureDevOps as well and the YAML had the variable group options mentioned above.
...
0
Modify Metadata Through Metadata API Functions Permission allows users to
update metadata (including Apex) through Metadata API even if they don’t also have the Modify All Data permission. Metadata API is used for deployments using change sets, the Ant Migration Tool, or the Salesforce CLI.
It is a more restricted level of permission than, for example, ...
1
In addition to all of the above, https://marketplace.visualstudio.com/items?itemName=VignaeshRamA.sfdx-package-xml-generator gives you a simple GUI for adding items to your manifest/package.xml.
0
I'm not familiar with financial service cloud package, but it looks like you're using the right type, but maybe not the correct name. You simply just need to pass the FieldAPIName for the picklist.
https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_standardvalueset.htm
https://developer.salesforce.com/docs/atlas.en-us.api_meta....
1
Should be. I use a deployment tool which simplifies this for me, but if you're looking to pull it you might want to check workbench --> Info --> Metadata Types & Components --> ProfileSessionSetting.
What's highlighted in blue is just the profile name.
This'll give you the name to include in your package.xml to pull/deploy.
https://developer....
2
Custom settings act like sObjects and therefore the fields Values you're talking about are just like any other record of any other Object, since on the change sets you're only deploying metadata, there's no records there, so the values of instances of Custom settings will not be populated by any deploy.
2
Something that is related, but not exactly the same as how MavensMate allowed you to deploy Metadata is the VSCode Org Browser.
Open Org Browser
Refresh available metadata types in the org
Default org
Metadata type
Metadata component
Refresh components for metadata type
Retrieve source for metadata component
It is currently in Beta and ...
2
There isn't such a feature in the core bundle, nor does there need to be. VS Code handles multiple orgs without any problems, it's just different. You don't need to select individual files, because you can have as many folders as you need to organize your metadata. You no longer have a single src/classes folder, you can instead have core/classes, marketing/...
1
The sfdx structure is meant to be used in a repo. The folder structure is not uploaded to Salesforce during sfdx deployments, and thus cannot later be retrieved. You can deploy the same code to multiple orgs using sfdx, and can even push/pull from multiple scratch orgs, as the metadata is saved per org in the sfdx configuration files.
2
In my experience, most of destructive changes can go through post destructive. Pre destructive is only needed when you want to make changes inside your deploy and you have some reference that isn't going to allow it.
For instance, if you want to change some custom field type to another type that isn't allow you will need to delete it and all its references ...
0
Please check whether you have given "Modify All Data" permissions .
Modify all data permission gives ability to create and deploy metadata. Check the official docs here
0
It would seem this is not possible. Note Heroku support says to go to StackExchange, so this is now the official answer.
Individual channels have advised me that IBM, Microsoft, or Amazon, may offer a working alternative, but Heroku is not.
1
To simulate the default behavior of production, use:
<sf:deploy testLevel="RunLocalTests" ... />
This will run all tests in your org's namespace, but not those from installed packages. You can read more about it in Deploying Changes to a Salesforce Org.
0
As of today, the setting orgPreferenceSettings.translation does not do anything if other pathAssistantSettings.pathAssistantEnabled setting is present, no idea if this happens with any other setting, I am going to open a support case to inform about this.
{
"orgName": "Org",
"edition": "Developer",
"language": "en_US",
"features": [
...
Top 50 recent answers are included
