Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parallel rsyncs fail #8

Open
wyozi opened this issue Mar 6, 2019 · 3 comments
Open

Parallel rsyncs fail #8

wyozi opened this issue Mar 6, 2019 · 3 comments

Comments

@wyozi
Copy link

wyozi commented Mar 6, 2019

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?

@maxheld83
Copy link
Owner

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?

@wyozi
Copy link
Author

wyozi commented Mar 8, 2019

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.

@maxheld83
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants