abra recipe release should fail earlier when ssh-agent is not running #576
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
i often forget and then i have to
git push ; git push --tags@fauno since we interactively ask if you want to publish the release, I think this makes the UI change tricky. Should we ask "publish new release?" as the first thing? That might be a bit weird but maybe it's fine?
Otherwise, we could not ask this interactively (breaking change) and rely on passing
--publish/-Pand then immediately attempt to check if SSH works and bail out.I don't have time to dig in just now but is the issue also that the change gets committed and it doesn't get cleaned up when it fails? Because we should also just undo the commit and make sure the change remains unstaged? Then you can run the command again more easily without dropping down to git (confusing for new people also).
Related: toolshed/organising#663
For me its ok, if it fails this late. But it would be nice, if it prints the commands I have to run manually and also a documentation page on how to setup ssh-agent
We could also add a new abra system-checks or something like that to check everything works and if not get hints on how to fix that
well i'm not sure why it requires
ssh-agentat all, but i noticed this because i only start it manually when i need it. you can check early for the presence ofSSH_AUTH_SOCKor run the equivalent ofssh -fNo ControlMaster=autoto check it'll actually work.i agree with @p4u1 on providing instructions!
when it fails... i'm not sure there's an
abracommand to finish the release process. can't remember if i triedabra recipe releaseagain, can check next time i release something.git push ; git push --tagsappears to be what's happening, though i tried it out of intuition. maybe running it twice can detect there are commits and tags not pushed and just skip to that point?I tracked this down:
go-gitis forcing thisSSH_AUTH_SOCKhandling:39261590f7/plumbing/transport/ssh/sshagent/sshagent.go (L34-L49)I believe it does this when you havessh://...configured in your recipe remote! I think we could indeed parse this remote and bail out if we see theSSH_AUTH_SOCKis not set up.I'll see about adding manual commands to resolve in the case of failure, that sounds pretty good.
I like the idea of
abra system-checks, lemme take a look at that 👀Ah, just so we're on the same page: we are actually forcing the
ssh://...remote to be used when pushing changes from the recipe. This is more or less highlighted in the--helpoutput. This is done by wiring up aorigin-sshremote on your recipe git repo when you want to publish. This was to keep things simple in the implementation and avoid handling password input, which I'd like to stick with.i've been using http for pushes too, since http is faster than ssh lately and i don't have to change the remote on
~/.abra/recipes/RECIPE. which also produces errors onabra recipe fetchlater on (forgot to report this, sorry)I wonder why we need the SSH_AUTH_SOCK? When I run git push in my terminal, it works just fine. Is this a limitation of go-git?
All good. The
abra recipe fetcherror is handled in #601. You don't have to manually change the remote on the recipe git repo,abrawill do this for you automatically (it createsorigin-sshand manages it).I would be OK to support
https://...onabra recipe releaseso as not to forcessh://...but then I don't know how to avoid having to enter a username/password each time? Do you do that? It seems like I could pass this into the underylinggo-gitAPI call (source: https://stackoverflow.com/a/48895644). Would you imagine--user/--passflags (maybe entering the--passinteractively is better)? I'm wonder will this just confuse the situation...In the meantime, the handling of failure / ssh setup is improved: #610
@p4u1 it is the default that
go-gituses:39261590f7/plumbing/transport/ssh/common.go (L45)Do you not have
SSH_AUTH_SOCKin your env?env | grep -i sshreturns one for me. I believessh-agentmanages it. My SSH key has a passphrase and I need to type that in to load the key,ssh-add ~/.ssh/myprivatekeydoes prompt me for a password. Thenssh-add -Lshows my key is loaded. This means that it's done once andabracan re-use this to authenticate successfully without having to handle user input (which again, I'd like to avoid).The setup
abraneeds is the following. It doesn't seem complicated to me but I see many people have issues with this.We're getting in a bit of a loop now creating more work for ourselves by trying to create a convenient method for maintainers to make releases. I think the overall approach of trying to create a front-end for Git is not working well for this workflow. Trying to create more ways to interact with Git seems like a bad path forward as it is just simply tricky to deal with on the command-line. However, I'm open to proposals as per usual!
We might need to consider other approachs in toolshed/organising#663
OK #610 solves the immediate issues. Please open up specific issues for whatever request you want to proceed with and we get into the weeds there 🙃 Thanks for all the feedback / reporting back!
To be clear, how you would resolve #576 (comment) in the new
abrais setup yourssh-agentandabra reciipe release -pagain. It knows how to clean up after itself now, so don't need to drop into a work-around with Git.