rsync icon indicating copy to clipboard operation
rsync copied to clipboard

Parallel rsyncs fail

Open wyozi opened this issue 5 years ago • 3 comments

Running multiple rsyncs in parallel/after each other fails because the .ssh folder already exists. I fixed this in a fork by appending a per-action string to the .ssh folder, but I guess the folder name could also be just randomly generated string?

wyozi avatar Mar 06 '19 23:03 wyozi

thanks for raising this, I hadn't thought about that.

I hacked this together on a shoestring, and so I'm generally worried that the ssh usage isn't up to par here.

I can see three alternative ways of addressing this:

  1. The action always cleans up after itself and deletes the .ssh contents it created.
  2. The action just learns to take whatever .ssh is already in there.
  3. As you implemented, each action writes its own random string .ssh. (That's not something we usually do with ssh keys though, right? – might be hard to reason about / feels odd).

I'm wondering whether, generally, .ssh credentials should persist between actions or not. On the one hand, actions are supposed to be pretty isolated, I guess, so that would favor just cleaning up after itself.

What are your thoughts?

maxheld83 avatar Mar 07 '19 10:03 maxheld83

In my opinion this action is using ssh files as a deployment tool rather than the standardized "hosting keys and authorized_keys" way. For this reason I think the third option would make the most sense here, and preferably the keys would also be cleared up after the action.

I agree with what you said about each action being as isolated as possible, so randomized name definitely makes the most sense to me.

wyozi avatar Mar 08 '19 13:03 wyozi

on closer inspection of the entrypoint.sh and the github actions docs, I'm not 100% sure that this isn't actually a github bug / undocumented behavior, as per below message to github support. I'm going to wait for their response, and then fix this as discussed (if still relevant).

So far, I was under the impression as per the file system docs that (only?) /github/workspace persists across actions (not workflows), but I now have user reports that /github/home also appears to persist across actions (not workflows).

Is this correct?

Could you perhaps clarify this in the documentation?

The current documentation could be understood to mean that only /github/workspace persists, because only it has mentions in the docs:

An action can modify the contents of this directory, which subsequent actions can access.

maxheld83 avatar Mar 14 '19 22:03 maxheld83