Sfdx Source Push

[Francesca Cruiz]

Nowwhen I am trying to push source to my default scratch org, it always pushes code from force-app folder, not from sudipta-app folder. Is there any way I can mention which path to consider while pushing code into scratch org?

Weird state encountered if the metadata is reorganized into multiple folders and not started with fresh scratch orgs. Reorganize and then always test force:source:push with a new scratch org before source is versioned.

sfdx force:source:push is optimized for development workflows and is useful for pushing code and metadata changes from your local project to your org, while sfdx force:source:deploy is more flexible and can be used to deploy changes from a variety of sources, including third-party apps and other orgs.

sfdx force:source:push is typically faster and more efficient than sfdx force:source:deploy, as it only deploys changes that have been made since the last push. sfdx force:source:deploy, on the other hand, deploys the entire set of metadata specified in the deployment package.

Yes, our Dev Hub. According to the Developer Guide the Dev Hub "is a central location for Salesforce DX because it allows you to create, delete, and manage your Salesforce scratch orgs." What does that mean to you? Well it's the central place where all the changes are culminating towards, in other words Production. At least, that is the way I interpret it. Feel free to correct me if I am incorrect :)

Since the Dev Hub is a different kind or org we are not able to push source code to it with the force:soruce:push command they way we did with the scratch org. And if you're like me you're probably thinking "WTH? I was just getting to like this CLI thing!" But fear not there's the force:mdapi:deploy command for just such a case.

We used the force:mdapi:retrieve and force:mdapi:convert when we move our code from the existing org last time so it would make sense that the same namespace, mdapi, would have what we need to deploy to a non-scratch org.

Before we can deploy our source code we will need to convert it to a format that the Metadata Api can use. To accomplish that we will use the force:source:convert command. It has 2 optional parameters: -r for specifying the root directory to convert, and -d to specify the output directory. I'm only going to convert the contacts-vue-app and have it output to a deploy directory at the root of the project, I'm sure in the long run I will want a more organized way to do this but for now it will work.

PS D:\Workspace\Blog\salesforce\dx\wip-org\wipdeveloper-org> sfdx force:source:convert -r contacts-vue-app -d deploySource was successfully converted to metadata api format and written to the location: D:\Workspace\Blog\salesforce\dx\wip-org\wipdeveloper-org\deployPS D:\Workspace\Blog\salesforce\dx\wip-org\wipdeveloper-org>

The deploy request did not complete within the specified wait time [0 minutes].To check the status of your deployment, run "sfdx force:mdapi:deploy --jobid 0Af4600000nvIOBCAZ --targetusername br...@wipdeveloper.com"PS D:\Workspace\Blog\salesforce\dx\wip-org\wipdeveloper-org>

You may have noticed where it says how to check the status of the deployment with the following command sfdx force:mdapi:deploy --jobid 0Af4600000nvIOBCAZ --targetusername br...@wipdeveloper.com. Why not give that a try and see how things are going.

Wasn't that fun? But there has to be an easier way to deploy to the Hub Org so there are fewer manual steps. Have any suggestions? Let me know what you think by leaving a comment below, emailing br...@wipdeveloper.com or following and yelling at me on Twitter/BrettMN.

So the promise of Dreamforce 2016 is slowly but surely being fulfilled. I've still only had limited experience with SalesforceDX so far, but what I have seen of it is definitely exciting, and it's already making life for developers easier. There's plenty of road left to travel, but now is a good time to start getting acquainted with these new tools (the sfdx command line program in particular) so that you know what's available and whether it's something you can start to use in anger.

A lot of the documentation I've seen so far seems to revolve around creating a project from scratch; that's great, but not necessarily realistic. For a lot of us "new" projects are few and far between, but we have more than a few existing code bases to work with.

This is a simple set of steps that should get you going if you've got some existing code and customisations that you want to get out of the old model and into the promised land where version control is the source of truth. The basic gist to grab your existing metadata, convert it to the new format, and chuck it into source control. The steps below assume you've installed the SalesforceDX CLI and hooked it up to your dev hub.

If you need a specific edition of Salesforce, or to turn on features like multi-currency, you'll need to edit the project-scratch-def.json file first, there's a list of options available in the documentation.

Obviously the above isn't exhaustive, and there are further steps if you want to grab some data for loading into scratch orgs and the like, but the idea here was to get you up and running quickly with the most basic parts. Remember that you can get plenty of help from the sfdx program itself, sfdx help is your friend, and works for different levels of the command hierarchy, e.g. sfdx help gives a list of the top level commands, sfdx help force shows the next level down, and so on, all the way down to specifics for something like sfdx help force:apex:execute.

The Git terminal from SourceTree asks for my username/password and, when I enter it, it works correctly (I'm able to do a push/pull anyway). However, nothing I've tried will allow me to use the push/pull buttons in SourceTree. I've updated my Git username every place I've been able to see something that resembles a username, I've gone to Tools > Options > Authentication > [My Account] and set the password (which is a private access token).

I'm not sure why it stopped working (I haven't changed my VSTS password and all my private access tokens are still valid), but I seem to recall an odd password box that popped up a week or so ago that I believe came from SourceTree. I might have entered the wrong password, but didn't see any problems at that time (I haven't pushed/pulled since then, so wouldn't have seen any problems until today).

A note to Atlassian, there should be a much simpler way to do this than spending hours searching the Internet looking for an answer. If getting the Authentication page to work as expected is not possible, then perhaps just a button that users that are having trouble can press on the Authentication page that would reset all the passwords (basically just delete this file for us).

For some retarded reason the field to type in your email adress is greyed out and it has an email adress in it that doesn't even have an atlassian account. I can not change my email adress whatsoever. I've deleted the account file and restarted it. I've checked the tools bar into the authentication and removed everything there. I've even reinstalled source tree and it still won't let me change the email adress. Holy shit I regret updating to this horrible version. I'm stuck not being able to fetch or pull anything. Even the crash report pop up crashes when I submit this shit.

Removing the passwd file worked for me. This was driving me crazy for the past few weeks. Thanks for the solution! I was actually looking for other options to use instead of Sourcetree until finding this fix. It would really helpful if there were an easier way to force the password prompt.

I updated the SourceTree and the authentications failed. I wiped out the SourceTree (uninstall and the directory deleted) and installed 2.4.7.0 SourceTree. I had the same problem: after asking the password to the local GIT server the session failed because of SSH_ASKPASS. I wiped out the SourceTree again and installed 2.1.2.5 version. It works normally.

I've reinstalled sourcetree and git (without credential manager and with it), generated several github acess tokens and without success.... and your solution helps! So THANK YOU ! I think that it should be in the docs or in the bug tracker :)

I had the same error and I saw this post, but deleting the password file did not work for me. it turned out that my VSO personal access token was expired. I had to renew it. Just FYI for anybody who use visual studio online.

So before a fancy login box came up but my password never worked in it. But then when I detest this. The fancy login box didn't come up but a not so fancy box replaced it. The only difference is that my password worked on this one. So thanks for this :)

Same here, 2021 and still an issue. I'd tried removing my accounts in sourcetree in the options menu and re-authing with the pat token and still no joy. I did this though as cjdennis mentioned instead (so I didn't loose passwords set for my other accounts):

cjdennis Dec 18, 2018

Despite all saved account under Tools > Options > Authentication, this password file is not getting deleted. Only after manual deletion is when SourceTree prompted for login and things worked fine then

And here I am - a git newbie four years on and still tripping over this. Wasted time and got severely demoralised when stuck at such a basic point with such a simple solution (simple when you know how!).

Issue was solved for me as described upper with:

going into path C:\Users\USERNAME\AppData\Local\Atlassian\SourceTree and removing the passwd file.

Starting again source tree, going to clone, and prompted me for password.

Before I had authentication failure, even in tools -> options -> authentication, user was OK authenticated.

This was making confusion, like why was authentication failure, if user is successfully authenticated in settings now we know that there is additional file with authentication parameters.

Thank you.

3a8082e126