apm
apm copied to clipboard
atom
Apm username/password for github
Maybe you'll find also some details in the following discussion: https://discuss.atom.io/t/apm-username-password-for-github/15153
I just released my very first plugin. Everything worked quite well but when running "apm publish minor" the process hung forever at "Pushing v0.1.0 tag". No blinking cursor, no hint what's going on, no nothing. After some trial and error and starting apm over and over I found out that apm just expects my github username and password. Sounds logical, but without any hint in the console one can only guess whats going on. Doubt (at least after starting the discussion ;-) ) this is the intended behaviour.
current atom @Windows 7
So doing a git push from that repository prompts for your username/password?
Well ... I can definitely answer this not before Monday, because I have currently no access to this PC, but yes ... I think so. While developing my new atom package I followed the instructions and so I installed the Github Windows client. Therefore I've never touched the git cmdline in this repository yet. I've a few other git repositories and everytime when I do a git push I am asked to enter the Github credentials. So I guess this is the same here.
Ok, tried it today. You are right git push was prompting for username and password. See it here ...
at pushing 0.4.1 tag nothing happened, so I typed username and password and the process continued
I can confirm this behavior - if you do apm publish minor w/o doing git push first, apm asks for Git credentials and hangs (tried multiple times). Package is published only partially to atom.io (repo and bug links present, BUT no readme is shown and no license link). After pushing using git, apm proceeds as expected.
This just happened for me too.
I ran apm publish patch, it edited package.json, committed, created the tag, and then:
- it asked for username/password
- pushed the tag (the tag was successfully pushed to the server)
- ...and then just hangs.
I had to reset the commit, force push, delete the local tag and delete the tag on the server. I even ran apm publish patch twice, and it created 2 tags, but each time hung after the pushing the tag to the server.
When Git asked me for credentials from somewhere else (e.g. pushing) and remembered the credentials (using credential.helper cache), apm publish patch worked fine.
If you don't know your way around Git, this can mean you can't publish your package at all, or you can have weird half-published versions.
To "unpublish" the failed version, you have to run (be very careful):
git reset HEAD~1 # Go back one commit
git checkout package.json # Revert the version number
git push -f # Force push, so that the commit is removed from the server
git tag -d v0.0.0 # Delete the tag (local)
git push :refs/tags/v0.0.0 # Delete the tag (server)
Edit If it makes a difference, I'm only a collaborator on the package I was publishing, I'm not an owner in the repo.
Edit 2
DO NOT run the above commands, if you didn't commit before running apm publish. Otherwise, you'll probably lose your changes. (It's always a good idea to do a separate commit for updating version numbers)
I'm also having issues with this…
Is it the expected behaviour that we need to always enter a [GitHub] password to push the tag to the GitHub repo before publish will fully complete? Shouldn't it use Keychain credentials given that I already have both an Atom API token setup as well as GitHub credentials?
if you do apm publish minor w/o doing git push first, apm asks for Git credentials
Would it make any difference that I'm using Tower to push first rather than git push on the command line? Note too, that I have [git push] --follow-tags set to true in my global git config.
Also, I think apm publish should undo all of it's changes upon failure (so remove the tags, revert the version bump and corresponding commit if it failed any of the expected steps…)
OS X 10.11 Tower 2.3.1 Atom 1.0.19 apm 1.0.5 npm 2.13.3 node 0.10.40 python 2.7.10
Damn; just happened again…
Preparing and tagging a new version ✓
Pushing v0.2.1 tag Password for 'https://[email protected]':
✓
Publishing [email protected] ✗
Creating new version failed: Git tag not found
Yet the tag is there on the GitHub repo. This process is too flimsy…
Is it the expected behaviour that we need to always enter a [GitHub] password to push the tag to the GitHub repo before publish will fully complete? Shouldn't it use Keychain credentials given that I already have both an Atom API token setup as well as GitHub credentials?
@danielbayley Have you tried apm login? It should let you "Enter your Atom.io API token and save it to the keychain". Then you shouldn't have to enter your password each time.
Have you tried apm login? It should let you "Enter your Atom.io API token and save it to the keychain". Then you shouldn't have to enter your password each time.
I have. I even set the ATOM_ACCESS_TOKEN environment variable to it. But I still get prompted for the (GitHub, not Atom API token) password each time.
@danielbayley when just pushing things (eg git push) does Git also prompt for your password?
@danielbayley What do you get if you run git remote -v?
I just had this problem too and when checking the remote push URL, I was using https://[email protected]/username/repo.git. Once I changed it to SSH [email protected]:username/repo.git it didn't ask for a password anymore.
Well since I was using Tower to push, everything went through fine. However when I tried to push on the command line (having setup the remote as https) I ran into the same problem as you mention. However I solved it in a different way; after reading this. So now it just uses Keychain. :+1:
However the basic issue still remains that if anything goes wrong during apm publish you can be left with a bit of a mess to clean up…
However the basic issue still remains that if anything goes wrong during apm publish you can be left with a bit of a mess to clean up…
I feel it would be best to split this enhancement out into its own Issue rather than conflating it with this one.
I feel it would be best to split this enhancement out into its own Issue rather than conflating it with this one.
True, although maybe #221 covers it?
I think I've just been facing a similar problem.
Updating my git remote as follows worked:
git remote set-url origin https://<username>:<password>@github.com/<username>/<repo_name>.git
Also, linking in a related thread: https://github.com/atom/atom/issues/8984
Going to leave a comment to help people who faced a similar problem as me. I was using the ssh version for my origin, but had similar errors. I had to change the repository field in my package.json file to the ssh version from the https version. This allowed me to publish without getting the github password prompt.
This is related to #135 It work when I used Personal access tokens https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/
Following the trick @dsandstrom works but the repository link when viewing the package in Atom is messed up by this:
It leads to a non-existing url, e.g: https://github.com///[email protected]/Siilwyn/css-declaration-sorter-atom.
Does anybody know if it is possible to overwrite what is being shown?
I have a related problem with this, mainly because of my use of multiple accounts. Normally I use tokens to handle uploading to manage those but when it pulls the URL from the package.json file, it uses the URL without the token which then asks for the user name and password. However since I have those multiple accounts, I can't really use either the SSH (which SSH key to use) or the tokens (because it strips them off).
Using the origin fallback in publish.js works fine in those cases because I can use what is in .git/config. Would it be reasonable to add a optional parameter to apm to use the origin (the fallback) for those who know what they are doing?
