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

Use the CLI without git #30

Closed
solomon23 opened this issue Aug 29, 2019 · 7 comments
Closed

Use the CLI without git #30

solomon23 opened this issue Aug 29, 2019 · 7 comments

Comments

@solomon23
Copy link

It would be nice to use the CLI without git. Right now I get the error
You are not in a git root directory: this command will only deploys the current directory.

Can't it just tar up the current folder and upload it to my server without git ?

@githubsaturn
Copy link
Collaborator

It's already supported. You can do the compression part yourself and customize it in any way that you'd like, then just send the tar file to the server. See this for example: https://caprover.com/docs/recipe-deploy-create-react-app.html

@solomon23
Copy link
Author

I'd like to put in a feature request that if deploy doesn't detect it's in a git folder it just behaves that way. I never use tar so i have to look up the commands and then delete the temp file - seems like the CLI could just take care of all that.

On a side note - I really love this project

@githubsaturn
Copy link
Collaborator

githubsaturn commented Aug 29, 2019

On a side note - I really love this project

Thanks!

I'd like to put in a feature request that if deploy doesn't detect it's in a git folder it just behaves that way. I never use tar so i have to look up the commands and then delete the temp file - seems like the CLI could just take care of all that.

Short answer: no, this portion of the pipeline doesn't belong to CapRover CLI. More details:

CapRover's design philosophy is to address the 99% of cases in the simplest way possible, majority of the remaining 1% edge cases are still doable, they just need some minor manual customization. If the "tar"-ing becomes a CapRover native feature, we'll start by including a simple plain tar-ing functionality which is okay, but.... little by little we'll get to stage where we are duplicating all tar options on CapRover CLI. A user would like to have the option to a exclude a directory, the other want to exclude a certain file extension, the next one wants the tar process to follow the symlinks, the other one is to exclude the symlinks... this list will never end.

@solomon23
Copy link
Author

It seems like tar'ing is a feature of CapRover since it takes in a tar as one of the methods. But i get the point that creating a tar isn't it's job. Really as the end user my expectations is I can just run the command and it'll upload the folder i'm in to the server - whether it tars the folder or not really isn't my concern.

Likely what I'll do is make a wrapper around it that just does that, just through i'd throw it out there in case i'm part of the 99%.

@solomon23
Copy link
Author

Here I'll give my experience with the app today and maybe it can be helpful as a new user coming to it.

Today I find a cool little rails project with a Deploy to Heroku button. I don't know rails or ruby that well but the project is only a few lines and I want to make a small change to it and run it in production ( it's a hook for slack and git ).

So I go "ah ha! Who needs heroku. I got my CapRover". So i pull down the project and copy it into a folder. I make a few changes and now want to test it.

First problem. I'm not sure how to make a captain file for rails. I poke around a bit and find an old one you posted to someone in a git comment. It's schema 1 so I have to change some things around. Whatever i'm good. I start to think "They should make this easier if deploying a rails app is essentially always the same". So then I remember your sample folder. Bring down the tar. Untar it. Open the cap'n file in there. And see you already have a better way. Copy that.

Now i need to deploy it. I install the caprover cli.

Second problem: I'm dumb and run serversetup instead of login and it takes me through stuff. After asking for the endpoint and login it still asks me for ssl and root domain. Maybe if it tried to hit my server first it would see i already set it up and didn't need to do that again. But that's my fault. I'm in now and good.

Third problem: I run caprover deploy. It tells me it needs git. Doesn't tell me that option -t exists. Hmm I don't have it in git and don't really want it to be. So I look up the tar commands and tar the folder. Then manually go the website after every change. Sucks but I finally get it working.

So in the end I got it setup and I'm happy. In the spirit of helping make the project better I thought I'd share my pain points. Specifically

  1. It would be super useful to have a -f option and point to a folder i wanted to deploy
  2. It would be nice if the caprover deploy command didn't just bail if you're not in git and let you know there are other options
  3. Maybe running serversetup again against an existing server shouldn't try to setup ssl again

I did look through your issues and it seems like : #17 would be solved with a folder approach as well

@githubsaturn
Copy link
Collaborator

githubsaturn commented Aug 30, 2019

First problem. I'm not sure how to make a captain file for rails. I poke around a bit and find an old one you posted to someone in a git comment. It's schema 1 so I have to change some things around. Whatever i'm good. I start to think "They should make this easier if deploying a rails app is essentially always the same". So then I remember your sample folder. Bring down the tar. Untar it. Open the cap'n file in there. And see you already have a better way. Copy that.

captain-definition is essentially a pointer to a Dockerfile, if you have a Dockerfile you can even completely omit the captain-definition file. Not only for Ruby-on-Rack, for virtually all languages and framework, there is a Dockerfile.

Maybe if it tried to hit my server first it would see i already set it up and didn't need to do that again. But that's my fault. I'm in now and good.

Yes, agreed, this is definitely a UX improvement opportunity. Can you please create a separate issue?

Third problem: I run caprover deploy. It tells me it needs git. Doesn't tell me that option -t exists. Hmm I don't have it in git and don't really want it to be. So I look up the tar commands and tar the folder. Then manually go the website after every change. Sucks but I finally get it working.

First, you don't have to push the git repository, you can simply run git init && git add -A && git commit -m "Inited" and you have a git repo. If you don't want that, yes, you can go with the tar approach.
Second, yes, there is an opportunity for UX improvement to let the user know about -t option.

It would be super useful to have a -f option and point to a folder i wanted to deploy

This I am not too sure about. I am more inclined towards providing an simple example in the error message with tar. As I said, directory exclusion, symlinks follow, and etc are among common usages of tar

Last but not least, thanks for bringing these up and making suggestions! This is how CapRover has been shaped so far!

@solomon23
Copy link
Author

Appreciate the response. I'll just finish this out by saying setting up a git repo is easy but there are often times I don't want to do it. In this case I knew I was going to make a lot of changes since I wasn't testing locally. I was making changes, uploading them, and then testing them on CapRover.

One scenario I was thinking of using Cap'n was doing a webpack build and then just deploying the build folder. This is another scenario where it would be nice to point captain at my build folder and tell it to deploy it. Again I know that you can adding tar tooling into the webpack flow - just seems like such a common thing and such a nice convenience.

For me the convenience of uploading any folder far outweighs the potential problem of expanding the tarring options. My guess is other users would like it as well. In any event, it would be something I would be willing to write. I keep thinking I'd like to jump into this project somewhere.

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