x1011 / git-directory-deploy Goto Github PK

I just grabbed the latest version of your script and I got this issue.
It guess the script need to be at the same level of dist?

~/Sync/Development/statinamic/demo master* ⇡
❯ ./scripts/deploy.sh 
Deploy directory 'dist' is empty. Aborting. If you're sure you want to deploy an empty tree, use the --allow-empty / -e flag.

~/Sync/Development/statinamic/demo master* ⇡
❯❯ ls dist 
collection.json       docs                  index.html            index.json            statinamic-client.css statinamic-client.js

I'm thinking about changing how the configuration is specified. Rather than having users modify the script or set environment variables, the script would take additional command-line arguments. I would do this for deploy_directory, deploy_branch, and repo. I would eliminate default_username and default_email and just require the user to have git sufficiently configured beforehand.

I'm considering a syntax like this: deploy.sh [<options>] [<directory> [<branch> [<repository>​]]]

pros:

• the script doesn't need to be modified, so it can be shared across projects, installed as a package, and write protected
• no polluting of environment variables, no chance of name collisions
• makes apparent that a relative deploy_directory is relative to the current working directory, eliminating the need to mention this in the readme

cons:

• complicates ad-hoc deployments not using the defaults, as you would now have to either remember to include the arguments every time or create a wrapper script
• having 3 positional arguments, it may be hard to remember which is which
• will probably complicate argument parsing

questions:

• which arguments should be positional or named? (e.g., should we do something like this instead?: deploy.sh [-d <directory>] ...)
• which arguments should still have defaults or be required?

Let me know if you think this is a good or bad idea.

originally reported by @raine in #4.

• test and verify this issue
• display a friendlier error message and tell user to add deploy_directory to .gitignore.

In some situations last commit message does not describe the purpose of a commit properly.
In these situations it would be nice if you provide -m option to change the commit message.

Anyway, thanks for sharing your amazing script. It really makes my life easier!

Nice script!

You have a BSD-3 license which requires copying the license together with the script to the location it is used. But as per your own usage instructions, people are encouraged to only get the script and forget about the license. You could consider adding a --license option that prints the entire text, giving attribution to you and having the copyright notice. Note that you should add a URL to the repo as the location of the original work.

write (unit) tests using something like roundup, Bats, assert.sh, or shelltestrunner.

write tests for

• attempting to deploy without setting up first
  • non-existent deploy_directory (#5)
  • empty deploy_directory (#5)
  • non-existent remote deploy_branch (#5)
  • non-existent local deploy_branch
• non-writable remote repo
• setup should not delete existing files in deploy_directory (i think it does currently if a file also exists in the repo's root)
• don't expose repo URL
  • even when an operation fails (#7)

When deploying to heroku I have the [email protected]..... .git as the deploy url + master branch, should I put it in the "repo" variable and master in the "branch" one within the script file?

Thanks.

I'm getting this error from the command git --work-tree dist rm -r '*', would you recommend --cached or -f?

error: the following files have changes staged in the index
(use --cached to keep the file, or -f to force removal)

My guess is that it is caused by the branch having existed previously?

Btw, thanks for a great script. I use it at journster.com

Just FYI here I described once how to accomplish very similar task using simple series of commands: docpad/docpad#385 (comment)

Sorry if that's not what your script intends to do.

Hello @X1011,

Thanks for this script! I had trouble figuring out what to do after the last setup instruction. Here what I did:

git push origin gh-pages

(Your deploy.sh assumes the gh-pages exists on origin)

git --work-tree dist checkout master

(I could not figure out how to come back to master! git status was crazy messy with a lot of bower_components files)

Oh, and you might mention that people need to wget deploy.sh into their root directory, then chomd u+x it. Doesn't hurt :)

After that, ./deploy.sh worked like a charm! Thanks!

Hello! 👋🏼 I just wanted to thank you for making Git Directory Deploy and to inform you that we have forked and implemented the following changes:

1. Replace Circle CI with GitHub Actions.
2. Set up shellcheck.
3. Integration test of deploy.sh that deploys to a temporary branch.
4. Add support for directories that aren't Git-initialized.
5. Refactored readme.md to make use of link references instead of inline links and wrap all text at 80 characters.

These are the most significant changes I can think of. We will probably make more changes going forward. We will be using Git Directory Deploy to deploy developer.swedbankpay.com by its inclusion in jekyll-plantuml.

If you would like pull-requests for any of the mentioned changes, please let me know. 😃 👍

see it by yourself https://travis-ci.org/putaindecode/putaindecode.fr#L8587

Any idea how to catch this to avoid the token to be compromised ?

i think the readme needs some refactoring now. It doesn't make sense anymore to instruct users to edit the variables in the script itself, especially considering how deeply buried those default values have gotten with the recent changes.

i'm thinking we merge the configuration and options sections, and the run section can be simplified, or maybe even mixed somewhere in with the rest, too.

overall, it should be more like a man page now that the script is more like a full-fledged command-line utility.

i hopefully will be able to tackle this in the next couple of days, but you, of course, are welcome to take a shot, too, @matro (or anyone else who happens to be lurking here).

The following command

GIT_DEPLOY_DIR=deploy \
GIT_DEPLOY_BRANCH=master \
GIT_DEPLOY_REPO=https://<token>@github.com/<org>/<org>.github.io.git \
git-directory-deploy --verbose -m 'New: Deploy'

gives the following error

fatal: Refusing to fetch into current branch refs/heads/master of non-bare repository

Any idea?

I think it depends on the fact that I'm pushing to the master branch (of another repository) while I am on the master locally.

Hi

I've found this very useful trick to automatically deploy the contents of my deploy_folder as my gh-pages content. I've managed to get it working, but only when I add the deploy_folder to master.

If I don't add the deploy_folder to git, then there is no way for travis to access the files in the deploy_folder? Is this interpretation correct? Thus - to have travis run the deploy.cs, I do need to commit the deploy_folder contents, in my view. Please tell me if I am wrong in this?

Regards

I think the normal deploy process can cover all the needed setup steps, once $deploy_branch is created.

I've been kind of just winging it so far. Would it be worth adding a "development" section to the readme

Things like...

• "fork & edit & open a pull request" is 👍 for this project (it isn't always)
• rebase (or merge?) master before opening a PR, if it matters
• to squash or not squash commits?

...might be nice to just lay out for folks. Tons of ways to use Git and Github.