Support deploy via SFTP

[damithc]

It would be good to allow deploying via FTP. For example, Hexo support many ways to deploy https://hexo.io/docs/deployment

[Xenonym]

My instinct for this would be to support SFTP over FTP. I feel uncomfortable encouraging the use of insecure FTP in 2019 😅

[damithc]

My instinct for this would be to support SFTP over FTP. I feel uncomfortable encouraging the use of insecure FTP in 2019

Sure, that's better 👍

[damithc]

This feature could be quite useful for SoC users as all SoC modules have a Unix account that can be used to publish the module website. Similarly, all SoC faculty members (and students) can use their Unix account to publish their personal website.

[Xenonym]

Currently, only deployment settings for GitHub Pages are stored in site.json:

"deploy": {
  "message": "Site Update.",
  "repo": "https://github.com/myorg/myrepo.git",
  "branch": "gh-pages"
}

However, if we were to implement SFTP deployment, we would also have to store SFTP related settings (eg. username, password, hostname) in site.json. I propose changing the format of deploy to hold both sets of settings:

"deploy": {
  "gh-pages": {
    "message": "Site Update.",
    "repo": "https://github.com/myorg/myrepo.git",
    "branch": "gh-pages"
  },
  "sftp": {
    "host": "sftp.example.com",
    "username": "testUsername",
    "password": "testPass"
  }
}

Also, I propose that markbind deploy should deploy to both GitHub Pages and SFTP, if both are configured. Would like to seek feedback on whether this new behaviour would be good!

[acjh]

1. We should support password in environment variables.

2. Also, I propose that markbind deploy should deploy to both GitHub Pages and SFTP, if both are configured. Would like to seek feedback on whether this new behaviour would be good!

   • It can be configurable by a command line option that accepts a list or the string all.
   • It can default to the value specified by the key "default" ("defaultTargets"?) in "deploy".
   • Should it skip subsequent deployment targets if an earlier one failed?

[damithc]

1. We should support password in environment variables.

Also, as a CLI argument? As most MarkBind projects are github projects and site.josn is usually version controlled, it may be dangerous to have the password in that file.

Also, I propose that markbind deploy should deploy to both GitHub Pages and SFTP, if both are configured. Would like to seek feedback on whether this new behaviour would be good!

More flexible to support any number of user-defined deploy targets?

"deploy": [
    {
    "name": "github"
    "type": "gh-pages"
    "message": "Site Update.",
    "repo": "https://github.com/myorg/myrepo.git",
    "branch": "gh-pages"
  },
   {
    "name": "homepage"
    "type": "sftp",
    "host": "sftp.example.com",
    "username": "testUsername",
    "password": "testPass"
  }
]

markbind deploy //deploys all targets markbind deploy github markbind deploy github homepage

[acjh]

1. We should support password in environment variables.

Also, as a CLI argument?

Good point. We should read from CLI argument (user can use env vars) rather than an env var directly. (We still need a way to identify passwords for multiple deployment targets.)

3. More flexible to support any number of user-defined deploy targets?

Agreed. Let's keep "deploy" as an object; the list can be specified by the key "targets" in it.

[Xenonym]

Thanks for the comments! This is what I think the deploy key should look like after your comments. Unfortunately, the CLI library we use doesn't support "flags for flags" (which excludes syntax like deploy target1 -p pass1 target2 -p pass2) Maybe we could allow users to specify the environment variable name (eg. passwordEnvVar) in the config as well?

"deploy": {
  "targets": [
    {
      "name": "github",
      "type": "gh-pages",
      "message": "Site Update.",
      "repo": "https://github.com/myorg/myrepo.git",
      "branch": "gh-pages"
	  "travisTokenVar": "GITHUB_TOKEN"
    },
    {
      "name": "homepage",
      "type": "sftp",
      "host": "sftp.example.com",
      "username": "testUsername",
      "passwordEnvVar": "PASS_VAR"
    }
  ]
}

markbind deploy will deploy to all targets, otherwise markbind deploy [...targetList] will deploy to all named targets. This would mean removing the -t/--travis flag since it now needs to be applied on a per target basis; a similar suggestion to specify the Travis token in the config can be done like above.

I am thinking that that markbind deploy should try all targets and continue with the next target if the current one fails. Then, a user can retry failed deploys can simply do markbind deploy failedTarget to only redeploy on failed targets.

[yamgent]

(which excludes syntax like deploy target1 -p pass1 target2 -p pass2)

We don't usually specify our password in the command line's prompt (because they will be saved and accessible from the history command).

Password should be asked separately by MarkBind (it is like how sudo and npm adduser asks for the password as well):

~/site$ markbind deploy target1 target2
Password for target1:
Deploy to target1 successful!
Password for target2:
Wrong password, try again.
Password for target2:
...

For the CI environment, we can implement the passwordEnvVar idea as you suggested.

So in other words, we should support both ways of accepting passwords (through manual typing by the user + environment variables).

[acjh]

Environment variables can be used like this:

deploy target1 -p $PASS_VAR

[Xenonym]

Environment variables can be used like this:

deploy target1 -p $PASS_VAR

@acjh this won't work if there are multiple deploy targets though:

Unfortunately, the CLI library we use doesn't support "flags for flags" (which excludes syntax like deploy target1 -p pass1 target2 -p pass2)