2017-01-10 69 views
5

Mam gałąź feature i gałąź (dla początkowej regresji). Chciałbym mieć kopię roboczą dostępną dla mojego oddziału testing dla środowiska testowego. Jednak potrzebuję skompresować część kodu źródłowego (nie do binarnego, po prostu optymalizować) za pomocą skryptu. Mogę wprowadzić ten skrypt za pomocą haka Git po otrzymaniu.Jak poprawnie używać skryptów CI z hakami Git do kompresji źródła

Próbuję zaprojektować mój skrypt bash (dla CI), aby był dość solidny i chciał uniknąć automatyzacji powodując konflikty Git. Zastanawiam się nad posiadaniem repozytorium głównego (origin) i repozytorium środowiska testowego (ci_test), aby zezwolić CI na zatwierdzenie.

Zastanawiam się nad popychaniem do ci_test/testing podczas promowania źródła. CI powinien kompresować, dodawać, zatwierdzać, pobierać od origin/testing, scalać w razie potrzeby (przyjmując ich pełne konflikty iff), a następnie naciskać na origin/testing.

Problem z powyższym modelem jest taki, że Git uskarża się, gdy próbuję przesłać do ci_test/testing, ponieważ ma kopię roboczą (ma to sens, ponieważ może nie być zsynchronizowana). Czy istnieje odpowiedni (zautomatyzowany) sposób korzystania ze skryptów Continuous Integration z Git, aby nadal były śledzone?

Odpowiedz

2

Problem do mojego modelu powyżej jest to, że Git narzeka kiedy próbują wcisnąć do ci_test/testing ponieważ ma kopię roboczą (ma sens, ponieważ nie mogą być synchronizowane).

można:

  • upewnić się ci_test jest nagi repo, z post-receive hook które:

  • lub, jeśli jesteś jedynym, który naciska na to repozytorium zdalnego ci_testing, skonfiguruj zdalny Git tak, aby akceptował wypychania do repozytorium typu "non-bare".
    Jest to możliwe since Git 2.3+ z:

    git config receive.denyCurrentBranch updateInstead 
    

I with Git 2.4+, można skonfigurować zdalne ci_testing z „push-to-checkout” haczyk, który może być zainstalowany na serwerze, aby dostosować dokładnie co się dzieje, gdy użytkownik naciska do wyrejestrowanego oddziału.

+0

[Push-to-checkout] (https://git-scm.com/docs/githooks#_push_to_checkout) wygląda obiecująco. Nie wiedziałem o istnieniu tego haka. Powodem, dla którego chciałem, aby ci_test miał kopię roboczą, jest to, że haczyk modyfikuje źródło i chcę dokonać zmian (nie wyobrażam sobie, że mogę to zrobić bez kopii roboczej). Używam również kopii roboczej jako katalogu, który jest używany do czytania wersji testowej aplikacji. – BLaZuRE

+0

@BLaZuRE tak, w twoim przypadku wypychanie do wypłaty wydaje się być dobrym rozwiązaniem. – VonC