How can I expand / click only a subdirectory of my git repository in Heroku?

Question

I have a project that uses Serve and is versioned using Git. The service creates an output folder with static files that I want to deploy to Heroku.

I don’t want to deploy the Serve project itself, since the Heedu Cedar stack doesn’t like it too much, but most importantly, I want to take advantage of Heroku for static websites.

Is there a way to deploy a subfolder to remote git? Should I create a git repository in the output folder (which doesn't sound right) and push it in Heroku?

Answer 1

There is an even easier way through git-subtree . Assuming you want to push your "output" folder as root in Heroku, you can do:

 git subtree push --prefix output heroku master 

It currently appears that git -subtree is included in git -core, but I don't know if a version of git -core has yet been released.

Answer 2

I had a similar problem. In my case, it was never a problem to blow away everything in the heroku repository and replace it with what is in my subdirectory. If this is your case, you can use the following bash script. Just put it in your Rails application directory.

 #!/bin/bash #change to whichever directory this lives in cd "$( dirname "$0" )" #create new git repository and add everything git init git add . git commit -m"init" git remote add heroku [e-mail]:young-rain-5086.git #pull heroku but then checkback out our current local master and mark everything as merged git pull heroku master git checkout --ours . git add -u git commit -m"merged" #push back to heroku, open web browser, and remove git repository git push heroku master heroku open rm -fr .git #go back to wherever we started. cd - 

I am sure there are many ways to improve this - so feel free to tell me how to do it.

Answer 3

I started by putting John Berryman, but in fact it might be easier if you don't care about the history of heroku git at all.

 cd bin git init git add . git commit -m"deploy" git push [e-mail]:your-project-name.git -f rm -fr .git 

I think official git subtree is the best answer, but I had a problem with a subtree to work with my mac.

Answer 4

After a long and difficult month when I realized

just because Heroku uses the git repository as a deployment mechanism, you should not consider it as a git repository

it could be rsync as well, they went for git, don't get distracted because of this

if you do, you will discover all kinds of grievances. All of the above solutions are somewhere depressing:

• this requires that something is done every time or periodically, or unexpected things happen (pushing submodules, synchronizing subtrees, ...)
• If you use the engine, for example, to modulate your code, the Bundler will eat you alive, it is impossible to describe the amount of disappointment I had with this project during the quest to find a good solution for this
  • you are trying to add the engine as git repo link + bundle deploy - crash, you need to bind update every time
  • you are trying to add an engine like :path + bundle deploy - fail, the development team considers :path option like "you are not using the Bundler with this gem option", so it will not be linked for production
  • also, every engine update wants to update your rails stack -_-
• The only solution I found was to use the engine as a symbolic link /vendor in development and actually copy the files for production

Decision

In this application, there are 4 projects in git root:

• api - depending on the profile, it will work on two different heroku servers - upload and api
• Web site
• web old - an old website still in the process of migration
• common - common components extracted in the engine

All projects have a vendor/common symbolic link looking at the root of the common engine. When compiling the source code for deployment in heroku, we need to remove its symlink and rsync code to physically reside in the vendor folder of each individual host.

• takes a list of host names as arguments
• launches git push in your development repository, and then launches a clean git pull in a separate folder, making sure that no dirty (unmanaged) changes are automatically transferred to the hosts
• deploys hosts in parallel - relaying each heroku git, new rsynced code to the right places, with the push database in the git commit comment,
• in the end, we send ping with curls to tell the owners a hobby to wake up and start magazines to see if all the fault.
• plays well with jenkins: D (automatic code entry for testing servers after successful tests)

Works very well in the wild with minimal (no?) Problems after 6 months

Here's the script https://gist.github.com/bbozo/fafa2bbbf8c7b12d923f

Update 1

@AdamBuczynski, it is never that simple.

1 you will always have a production and test environment, at least, and a bunch of functional clusters in the worst case - suddenly one folder should display n heroku projects as a fairly elementary requirement, and all this should be organized so that the script “knows”, which source do you want to deploy where

2nd you want to share the code between projects - now comes the sync_common part, shennanigans with symbolic links in development, replaced by the actual rsynced code on Heroku, because Heroku requires a specific folder structure, and bundler and rubygems really do things ugly very badly if you want extract common flows into a gem

3rd you will want to connect CI, and it will change a little, how to organize subfolders and git repos, in the end, in the simplest case of use, you will get the above meaning.

In other projects, I need to connect Java assemblies, when you sell software to several clients, you will need to filter the modules that are installed depending on the installation requirements and something else,

I really should consider combining things in a Rakefile or something else and do it like this ...