Domanda Come posso distribuire / spingere solo una sottodirectory del mio repository git su Heroku?


Ho un progetto che usa Servire ed è controllato tramite Git. Servire crea un output cartella con file statici che voglio distribuire su Heroku.

Non voglio distribuire il progetto Serve da solo, dato che lo stack Heroku Cedar non sembra troppo affezionato, ma soprattutto voglio approfittare dell'ottimo supporto di Heroku per i siti web statici.

C'è un modo per distribuire una sottocartella su un git remoto? Dovrei creare un repo Git nel output cartella (che suona male) e spingerlo su Heroku?


91
2017-09-24 13:39


origine


risposte:


C'è un modo ancora più semplice tramite Git-sotto-albero. Supponendo di voler spingere la cartella 'output' come root per Heroku, puoi fare:

git subtree push --prefix output heroku master

Al momento sembra che git-subtree sia incluso in git-core, ma non so se questa versione di git-core sia stata ancora rilasciata.


160
2018-05-18 07:41



Ho avuto un problema simile. Nel mio caso non è mai stato un problema spazzare via tutto nel repository di heroku e sostituirlo con qualunque cosa si trovi nella mia sottodirectory. Se questo è il tuo caso puoi usare il seguente script di bash. Basta inserirlo nella directory dell'app Rails.

#!/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 git@heroku.com: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 -

Sono sicuro che ci sono molti modi per migliorare questo, quindi sentitevi liberi di dirmi come!


8
2017-10-10 18:11



Ho iniziato con quello che ha detto John Berryman, ma in realtà può essere più semplice se non ti interessa affatto la storia del guru di heroku.

cd bin
git init
git add .
git commit -m"deploy"
git push git@heroku.com:your-project-name.git -f
rm -fr .git

Immagino ufficiale git subtree è la migliore risposta, ma ho avuto problemi nel far sì che la sottostruttura lavorasse sul mio mac.


7
2017-12-12 22:50



Dopo un lungo e difficile mese di provare cose diverse e di essere morso ogni volta che ho realizzato,

solo perché Heroku utilizza un repository git come meccanismo di distribuzione, non dovresti trattarlo come un repository git

avrebbe potuto essere rsync altrettanto bene, sono andati in giro, non essere distratti a causa di questo

se lo fai, ti apri a tutti i tipi di ferite. Tutte le soluzioni di cui sopra falliscono miseramente da qualche parte:

  1. richiede qualcosa da fare ogni volta, o periodicamente, o cose inaspettate accadono (spingendo i sottomoduli, la sincronizzazione dei sottoalberi, ...)
  2. se usi un motore per esempio per modulare il tuo codice, Bundler ti mangerà vivo, è impossibile descrivere la quantità di frustrazione che ho avuto con quel progetto durante la ricerca per trovare una buona soluzione per questo
    • si prova ad aggiungere il motore come link git repo + bundle deploy - fallire, è necessario aggiornare il pacchetto ogni volta
    • si tenta di aggiungere il motore come a :path + bundle deploy - fallire, considera il team di sviluppo :path opzione come "non stai utilizzando Bundler con questa opzione gemma", quindi non verrà associata alla produzione
    • inoltre, ogni aggiornamento del motore desidera aggiornare lo stack delle tue binari -_-
  3. l'unica soluzione che ho trovato è di usare il motore come /vendor collegamento simbolico in fase di sviluppo, e in effetti copia i file per la produzione

La soluzione

L'app in questione ha 4 progetti in git root:

  1. api - a seconda del profilo verrà eseguito su 2 diversi heroku host - upload e api
  2. web - il sito web
  3. web-old - il vecchio sito web, ancora in fase di migrazione
  4. comune - i componenti comuni estratti in un motore

Tutti i progetti hanno un vendor/common symlink guardando la radice del common motore. Quando si compila il codice sorgente per la distribuzione in heroku, è necessario rimuovere il link simbolico e rsync del codice per trovarsi fisicamente nella cartella del fornitore di ciascun host separato.

  1. accetta un elenco di nomi host come argomenti
  2. esegue un push git nel repository di sviluppo e quindi esegue un clean git pull in una cartella separata, assicurandosi che nessuna modifica (uncommited) sporca venga inviata automaticamente agli host
  3. distribuisce gli host in parallelo - ogni volta che viene rimosso il repository git di heroku, il nuovo codice viene ridefinito nei punti giusti, commesso con le informazioni di base del push nel commento di git commit,
  4. alla fine, mandiamo un ping con il ricciolo per dire ai padroni di casa di svegliarsi e tagliare i tronchi per vedere se tutto è andato vino
  5. gioca bene anche con jenkins: D (push automatico del codice per testare i server dopo test riusciti)

Funziona molto bene in natura con problemi minimi (no?) 6 mesi

Ecco la sceneggiatura https://gist.github.com/bbozo/fafa2bbbf8c7b12d923f

Aggiornamento 1

@AdamBuczynski, non è mai così semplice.

In primo luogo avrete sempre un ambiente di produzione e di test almeno - e un gruppo di cluster specifici per le funzioni in peggio - improvvisamente 1 cartella deve mappare su n progetti Heroku come un requisito piuttosto basilare e tutto deve essere organizzato in qualche modo in modo che lo script "sa" quale fonte si desidera distribuire dove,

2 ° vorrete condividere il codice tra i progetti - ora arriva il sync_common parte, i shennanigans con lo symlink in fase di sviluppo vengono sostituiti da un vero codice rsynced su Heroku perché Heroku richiede una certa struttura di cartelle e bundler e rubygems rendono davvero davvero le cose brutte se si desidera estrarre i thread comuni in una gemma

In terzo luogo vorrete collegare CI e cambierà un po 'come devono essere organizzate le sottocartelle e il repository git, alla fine nel caso d'uso più semplice possibile si finisce con il summenzionato Gist.

In altri progetti ho bisogno di collegare i build Java, quando si vendono software a più client è necessario filtrare i moduli che vengono installati a seconda dei requisiti di installazione e quant'altro,

Dovrei davvero considerare l'esplorazione di raggruppare le cose in un RakeFile o qualcosa del genere e fare tutto in questo modo ...


2
2018-01-26 09:34