toolshed/abra
4
2
Fork 18
Code Issues 20 Pull Requests 2 Packages Releases 40 Activity

abra recipe release should fail earlier when ssh-agent is not running #576

New Issue
Closed
opened 2025-06-13 14:13:40 +00:00 by fauno · 10 comments
fauno commented 2025-06-13 14:13:40 +00:00
Member
Copy Link

i often forget and then i have to git push ; git push --tags

>_ abra recipe release nocodb                                                                                               
WARN discovered 1.1.5+0.263.6 as currently synced recipe label                                                                          
INFO nocodb currently has these unstaged changes 👇                                                                                     
diff --git a/compose.yml b/compose.yml                                                                                                  
index 95074c7..e5b887f 100644                                                                                                           
--- a/compose.yml                                                                                                                       
+++ b/compose.yml                                                                                                                       
@@ -28,7 +28,7 @@ services:
         #- "traefik.http.routers.${STACK_NAME}.middlewares=${STACK_NAME}-redirect"
         #- "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLForceHost=true"
         #- "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLHost=${DOMAIN}"
-        - "coop-cloud.${STACK_NAME}.version=1.1.4+0.263.4"
+        - "coop-cloud.${STACK_NAME}.version=1.1.5+0.263.6"
  
   db:
     image: postgres:13.2-alpine
WARN previous git tags detected, assuming this is a new semver release
? current: 1.1.4+0.263.4, new: 1.1.5+0.263.6, correct? Yes
? Release Note (leave empty for no release note) 
? publish new release? Yes
FATA failed to publish new release: error creating SSH agent: "SSH agent requested but SSH_AUTH_SOCK not-specified"
i often forget and then i have to `git push ; git push --tags` ``` >_ abra recipe release nocodb WARN discovered 1.1.5+0.263.6 as currently synced recipe label INFO nocodb currently has these unstaged changes 👇 diff --git a/compose.yml b/compose.yml index 95074c7..e5b887f 100644 --- a/compose.yml +++ b/compose.yml @@ -28,7 +28,7 @@ services: #- "traefik.http.routers.${STACK_NAME}.middlewares=${STACK_NAME}-redirect" #- "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLForceHost=true" #- "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLHost=${DOMAIN}" - - "coop-cloud.${STACK_NAME}.version=1.1.4+0.263.4" + - "coop-cloud.${STACK_NAME}.version=1.1.5+0.263.6" db: image: postgres:13.2-alpine WARN previous git tags detected, assuming this is a new semver release ? current: 1.1.4+0.263.4, new: 1.1.5+0.263.6, correct? Yes ? Release Note (leave empty for no release note) ? publish new release? Yes FATA failed to publish new release: error creating SSH agent: "SSH agent requested but SSH_AUTH_SOCK not-specified" ```
decentral1se added the
enhancement
 label 2025-06-14 22:47:31 +00:00
decentral1se added this to the Abra "next" project 2025-08-19 16:39:59 +00:00
decentral1se commented 2025-08-19 16:42:30 +00:00
Owner
Copy Link

@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/-P and 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

@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/-P` and 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: https://git.coopcloud.tech/toolshed/organising/issues/663
p4u1 commented 2025-08-19 18:01:27 +00:00
Member
Copy Link

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

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
👀 1
fauno commented 2025-08-20 13:08:01 +00:00
Author
Member
Copy Link

well i'm not sure why it requires ssh-agent at all, but i noticed this because i only start it manually when i need it. you can check early for the presence of SSH_AUTH_SOCK or run the equivalent of ssh -fNo ControlMaster=auto to check it'll actually work.

i agree with @p4u1 on providing instructions!

when it fails... i'm not sure there's an abra command to finish the release process. can't remember if i tried abra recipe release again, can check next time i release something. git push ; git push --tags appears 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?

well i'm not sure why it requires `ssh-agent` at all, but i noticed this because i only start it manually when i need it. you can check early for the presence of `SSH_AUTH_SOCK` or run the equivalent of `ssh -fNo ControlMaster=auto` to check it'll actually work. i agree with @p4u1 on providing instructions! when it fails... i'm not sure there's an `abra` command to finish the release process. can't remember if i tried `abra recipe release` again, can check next time i release something. `git push ; git push --tags` appears 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?
decentral1se self-assigned this 2025-08-24 06:52:45 +00:00
decentral1se added the
red abya yala
 label 2025-08-24 07:27:01 +00:00
decentral1se moved this to In Progress in Abra "next" on 2025-08-24 07:29:04 +00:00
decentral1se commented 2025-08-24 07:56:36 +00:00
Owner
Copy Link

FATA failed to publish new release: error creating SSH agent: "SSH agent requested but SSH_AUTH_SOCK not-specified"

I tracked this down: go-git is forcing this SSH_AUTH_SOCK handling: 39261590f7/plumbing/transport/ssh/sshagent/sshagent.go (L34-L49) I believe it does this when you have ssh://... configured in your recipe remote! I think we could indeed parse this remote and bail out if we see the SSH_AUTH_SOCK is 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 👀

> FATA failed to publish new release: error creating SSH agent: "SSH agent requested but SSH_AUTH_SOCK not-specified" I tracked this down: `go-git` is forcing this `SSH_AUTH_SOCK` handling: https://github.com/go-git/go-git/blob/39261590f7f396873e83e7fc8ca8453f71225f10/plumbing/transport/ssh/sshagent/sshagent.go#L34-L49 I believe it does this when you have `ssh://...` configured in your recipe remote! I think we could indeed parse this remote and bail out if we see the `SSH_AUTH_SOCK` is 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 👀
🎉 1
decentral1se commented 2025-08-24 08:08:38 +00:00
Owner
Copy Link

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 --help output. This is done by wiring up a origin-ssh remote 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.

pkg/recipe/git.go Lines 315 to 332 in 42dde0930d
// Push pushes the latest changes to a SSH URL remote. You need to have your
// local SSH configuration for git.coopcloud.tech working for this to work
func (r Recipe) Push(dryRun bool) error {
repo, err := git.PlainOpen(r.Dir)
if err != nil {
return err
}
if err := gitPkg.CreateRemote(repo, "origin-ssh", r.SSHURL, dryRun); err != nil {
return err
}
if err := gitPkg.Push(r.Dir, "origin-ssh", true, dryRun); err != nil {
return err
}
return nil
}

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 `--help` output. This is done by wiring up a `origin-ssh` remote 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. https://git.coopcloud.tech/toolshed/abra/src/commit/42dde0930dcfba9f4980ec570ff0d7be3caee2c7/pkg/recipe/git.go#L315-L332
decentral1se referenced this issue from a commit 2025-08-24 08:41:12 +00:00
fix: mention ssh-agent
fauno commented 2025-08-24 10:58:22 +00:00
Author
Member
Copy Link

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 on abra recipe fetch later on (forgot to report this, sorry)

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 on `abra recipe fetch` later on (forgot to report this, sorry)
p4u1 commented 2025-08-24 11:12:39 +00:00
Member
Copy Link

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?

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?
decentral1se commented 2025-08-24 11:20:20 +00:00
Owner
Copy Link

All good. The abra recipe fetch error is handled in #601. You don't have to manually change the remote on the recipe git repo, abra will do this for you automatically (it creates origin-ssh and manages it).

I would be OK to support https://... on abra recipe release so as not to force ssh://... 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 underyling go-git API call (source: https://stackoverflow.com/a/48895644). Would you imagine --user/--pass flags (maybe entering the --pass interactively is better)? I'm wonder will this just confuse the situation...

In the meantime, the handling of failure / ssh setup is improved: #610

All good. The `abra recipe fetch` error is handled in https://git.coopcloud.tech/toolshed/abra/pulls/601. You don't have to manually change the remote on the recipe git repo, `abra` will do this for you automatically (it creates `origin-ssh` and manages it). I would be OK to support `https://...` on `abra recipe release` so as not to force `ssh://...` 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 underyling `go-git` API call (source: https://stackoverflow.com/a/48895644). Would you imagine `--user`/`--pass` flags (maybe entering the `--pass` interactively is better)? I'm wonder will this just confuse the situation... In the meantime, the handling of failure / ssh setup is improved: https://git.coopcloud.tech/toolshed/abra/pulls/610
decentral1se commented 2025-08-24 11:34:49 +00:00
Owner
Copy Link

@p4u1 it is the default that go-git uses: 39261590f7/plumbing/transport/ssh/common.go (L45)

Do you not have SSH_AUTH_SOCK in your env? env | grep -i ssh returns one for me. I believe ssh-agent manages it. My SSH key has a passphrase and I need to type that in to load the key, ssh-add ~/.ssh/myprivatekey does prompt me for a password. Then ssh-add -L shows my key is loaded. This means that it's done once and abra can re-use this to authenticate successfully without having to handle user input (which again, I'd like to avoid).

The setup abra needs is the following. It doesn't seem complicated to me but I see many people have issues with this.

eval `ssh-agent`
ssh-add ~/.ssh/myprivatekey

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

@p4u1 it is the default that `go-git` uses: https://github.com/go-git/go-git/blob/39261590f7f396873e83e7fc8ca8453f71225f10/plumbing/transport/ssh/common.go#L45 Do you not have `SSH_AUTH_SOCK` in your env? `env | grep -i ssh` returns one for me. I believe `ssh-agent` manages it. My SSH key has a passphrase and I need to type that in to load the key, `ssh-add ~/.ssh/myprivatekey` does prompt me for a password. Then `ssh-add -L` shows my key is loaded. This means that it's done once and `abra` can re-use this to authenticate successfully without having to handle user input (which again, I'd like to avoid). The setup `abra` needs is the following. It doesn't seem complicated to me but I see many people have issues with this. ``` eval `ssh-agent` ssh-add ~/.ssh/myprivatekey ``` 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 https://git.coopcloud.tech/toolshed/organising/issues/663
decentral1se commented 2025-08-24 12:06:11 +00:00
Owner
Copy Link

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 abra is setup your ssh-agent and abra reciipe release -p again. It knows how to clean up after itself now, so don't need to drop into a work-around with Git.

OK https://git.coopcloud.tech/toolshed/abra/pulls/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 https://git.coopcloud.tech/toolshed/abra/issues/576#issue-4702 in the new `abra` is setup your `ssh-agent` and `abra reciipe release -p` again. It knows how to clean up after itself now, so don't need to drop into a work-around with Git.
decentral1se moved this to Done in Abra "next" on 2025-08-24 12:08:05 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is not working
build
go build related issues
ci/cd
Building things with CI/CD
contributing
Dealing with contributing
critical fix
https://docs.coopcloud.tech/federation/resolutions/passed/010/
design
UI/UX
documentation
Documenting all the things
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
meta
relating to the project or repo itself
question
More information is needed
red abya yala
Work funded by Calyx institute for Red Abya Yala
release
Release management
release-candidate
Related to the new release candidate
security
Security related
test
Unit/integration testing
wontfix
This won't be fixed
No Label
enhancement
red abya yala
Milestone
No items
No Milestone
Projects
Clear projects
No project Abra "next"
Assignees
Clear assignees
3wordchant abra-bot ammaratef45 Apfelwurm carla cas coopcloud decentral1se fauno jmakdah2 kawaiipunk knoflook lambdabundesverband moritz p4u1 ripclap simon sixsmith trav val yksflip
No Assignees decentral1se
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/abra#576
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?