Share via

Tworzenie repozytoriów GitHub Enterprise Server

  • Artykuł

Azure DevOps Services

Możesz zintegrować lokalny serwer GitHub Enterprise Server z usługą Azure Pipelines. Serwer lokalny może być uwidoczniony w Internecie lub może nie być.

Jeśli serwer GitHub Enterprise Server jest dostępny z serwerów z uruchomioną usługą Azure Pipelines, wówczas:

  • Możesz skonfigurować klasyczne potoki kompilacji i YAML
  • Można skonfigurować wyzwalacze ciągłej integracji, żądania ściągnięcia i zaplanowane

Jeśli serwer GitHub Enterprise Server nie jest dostępny z serwerów z uruchomioną usługą Azure Pipelines, wykonaj następujące działania:

  • Można skonfigurować tylko klasyczne potoki kompilacji
  • Można uruchamiać tylko kompilacje ręczne lub zaplanowane
  • Nie można skonfigurować potoków YAML
  • Nie można skonfigurować wyzwalaczy ciągłej integracji lub żądania ściągnięcia dla klasycznych potoków kompilacji

Jeśli serwer lokalny jest dostępny z agentów hostowanych przez firmę Microsoft, możesz użyć ich do uruchamiania potoków. W przeciwnym razie należy skonfigurować własnych agentów, którzy mogą uzyskiwać dostęp do serwera lokalnego i pobierać kod.

Osiągalny z usługi Azure Pipelines

Najpierw należy sprawdzić, czy serwer GitHub Enterprise Server jest dostępny z poziomu usługi Azure Pipelines.

  1. W interfejsie użytkownika usługi Azure DevOps przejdź do ustawień projektu i wybierz pozycję Połączenie usługi w obszarze Potoki.
  2. Wybierz pozycję Nowe połączenie z usługą i wybierz pozycję GitHub Enterprise Server jako typ połączenia.
  3. Wprowadź wymagane informacje, aby utworzyć połączenie z serwerem GitHub Enterprise Server.
  4. Wybierz pozycję Weryfikuj w panelu połączenia z usługą.

Jeśli weryfikacja przebiegnie pomyślnie, serwery z uruchomioną usługą Azure Pipelines będą mogły uzyskać dostęp do lokalnego serwera GitHub Enterprise Server. Możesz kontynuować i skonfigurować połączenie. Następnie możesz użyć tego połączenia usługi podczas tworzenia klasycznego potoku kompilacji lub YAML. Można również skonfigurować wyzwalacze ciągłej integracji i żądania ściągnięcia dla potoku. Większość funkcji w usłudze Azure Pipelines, które współpracują z usługą GitHub, również współpracuje z serwerem GitHub Enterprise Server. Zapoznaj się z dokumentacją usługi GitHub , aby poznać te funkcje. Oto kilka różnic:

  • Integracja między usługami GitHub i Azure Pipelines jest łatwiejsza dzięki aplikacji Usługi Azure Pipelines w witrynie GitHub Marketplace. Ta aplikacja umożliwia skonfigurowanie integracji bez konieczności polegania na tokenie OAuth określonego użytkownika. Nie mamy podobnej aplikacji, która współpracuje z serwerem GitHub Enterprise Server. Dlatego należy użyć pat, nazwy użytkownika i hasła lub OAuth, aby skonfigurować połączenie między usługą Azure Pipelines i serwerem GitHub Enterprise.
  • Usługa Azure Pipelines obsługuje wiele funkcji zabezpieczeń usługi GitHub w celu weryfikowania współtworzenia z zewnętrznych rozwidlenia. Na przykład wpisy tajne przechowywane w potoku nie są udostępniane uruchomionego zadania. Te zabezpieczenia nie są dostępne podczas pracy z serwerem GitHub Enterprise.
  • Wyzwalacze komentarzy nie są dostępne na serwerze GitHub Enterprise. W celu wyzwolenia potoku nie można używać komentarzy w repozytorium GitHub Enterprise Server.
  • Testy usługi GitHub nie są dostępne na serwerze GitHub Enterprise. Wszystkie aktualizacje stanu są ze stanami podstawowymi.

Nieosiągalny z usługi Azure Pipelines

W przypadku niepowodzenia weryfikacji połączenia z serwerem GitHub Enterprise Server zgodnie z opisem w powyższej sekcji usługa Azure Pipelines nie może komunikować się z serwerem. Jest to prawdopodobnie spowodowane tym, jak skonfigurowana jest sieć przedsiębiorstwa. Na przykład zapora w sieci może uniemożliwić dotarcie ruchu zewnętrznego do serwerów. W tym przypadku dostępne są dwie opcje:

  • We współpracy z działem IT otwórz ścieżkę sieciową między usługą Azure Pipelines i serwerem GitHub Enterprise Server. Możesz na przykład dodać wyjątki do reguł zapory, aby zezwolić na przepływ ruchu z usługi Azure Pipelines. Zobacz sekcję na adresach IP usługi Azure DevOps, aby zobaczyć, które adresy IP należy zezwolić. Ponadto musisz mieć publiczny wpis DNS dla serwera GitHub Enterprise Server, aby usługa Azure Pipelines mogła rozpoznać nazwę FQDN serwera na adres IP. Po wprowadzeniu wszystkich tych zmian spróbuj utworzyć i zweryfikować połączenie z serwerem GitHub Enterprise Server w usłudze Azure Pipelines.

  • Zamiast używać połączenia z usługą GitHub Enterprise Server, możesz użyć innego połączenia Git . Pamiętaj, aby usunąć zaznaczenie opcji Spróbuj uzyskać dostęp do tego serwera Git z usługi Azure Pipelines. Za pomocą tego typu połączenia można skonfigurować tylko klasyczny potok kompilacji. Wyzwalacze ciągłej integracji i żądania ściągnięcia nie będą działać w tej konfiguracji. Można uruchamiać tylko ręczne lub zaplanowane uruchomienia potoków.

Osiągalne z agentów hostowanych przez firmę Microsoft

Kolejną decyzją, którą prawdopodobnie musisz podjąć, jest użycie agentów hostowanych przez firmę Microsoft lub własnych agentów do uruchamiania potoków. Często sprowadza się to do tego, czy agenci hostowani przez firmę Microsoft mogą dotrzeć do serwera. Aby sprawdzić, czy mogą, utwórz prosty potok, aby używać agentów hostowanych przez firmę Microsoft i upewnij się, że dodano krok w celu wyewidencjonowania kodu źródłowego z serwera. Jeśli to przejdzie, możesz kontynuować korzystanie z agentów hostowanych przez firmę Microsoft.

Nieosiągalne z agentów hostowanych przez firmę Microsoft

Jeśli prosty potok testu wymieniony w powyższej sekcji zakończy się niepowodzeniem z powodu błędu TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting, serwer GitHub Enterprise Server nie jest osiągalny z agentów hostowanych przez firmę Microsoft. Jest to prawdopodobnie spowodowane blokowaniem ruchu przez zaporę z tych serwerów. W tym przypadku dostępne są dwie opcje:

  • Skontaktuj się z działem IT, aby otworzyć ścieżkę sieciową między agentami hostowanymi przez firmę Microsoft i serwerem GitHub Enterprise Server. Zobacz sekcję dotyczącą sieci w agentach hostowanych przez firmę Microsoft.

  • Przejdź do korzystania z własnych agentów lub agentów zestawu skalowania. Tych agentów można skonfigurować w sieci i w związku z tym będzie miał dostęp do serwera GitHub Enterprise Server. Ci agenci wymagają tylko połączeń wychodzących z usługą Azure Pipelines. Nie ma potrzeby otwierania zapory dla połączeń przychodzących. Upewnij się, że nazwa serwera określonego podczas tworzenia połączenia z serwerem GitHub Enterprise Server jest rozpoznawalna z poziomu własnych agentów.

Adresy IP usługi Azure DevOps

Usługa Azure Pipelines wysyła żądania do usługi GitHub Enterprise Server do:

  • Wykonywanie zapytań o listę repozytoriów podczas tworzenia potoku (potoki klasyczne i YAML)
  • Wyszukiwanie istniejących plików YAML podczas tworzenia potoku (potoki YAML)
  • Ewidencjonuj pliki YAML (potoki YAML)
  • Rejestrowanie elementu webhook podczas tworzenia potoku (potoki klasyczne i YAML)
  • Prezentowanie edytora plików YAML (potoki YAML)
  • Rozwiązywanie problemów z szablonami i rozwijanie plików YAML przed wykonaniem (potoki YAML)
  • Sprawdź, czy istnieją jakiekolwiek zmiany od ostatniego zaplanowanego uruchomienia (potoki klasyczne i YAML)
  • Pobierz szczegóły dotyczące najnowszego zatwierdzenia i wyświetl je w interfejsie użytkownika (potoki klasyczne i YAML)

Możesz zauważyć, że potoki YAML zasadniczo wymagają komunikacji między usługą Azure Pipelines i serwerem GitHub Enterprise Server. W związku z tym nie można skonfigurować potoku YAML, jeśli serwer GitHub Enterprise Server nie jest widoczny w usłudze Azure Pipelines.

Jeśli używasz innego połączenia Git do konfigurowania klasycznego potoku, wyłącz komunikację między usługą Azure Pipelines i serwerem GitHub Enterprise Server i użyjesz własnych agentów do utworzenia kodu, uzyskasz obniżoną wydajność:

  • Podczas tworzenia potoku trzeba będzie ręcznie wpisać nazwę repozytorium
  • Nie można używać wyzwalaczy ciągłej integracji lub żądania ściągnięcia, ponieważ usługa Azure Pipelines nie może zarejestrować elementu webhook na serwerze GitHub Enterprise Server
  • Nie można używać zaplanowanych wyzwalaczy z opcją kompilowania tylko wtedy, gdy występują zmiany
  • Nie można wyświetlić informacji o najnowszym zatwierdzeniu w interfejsie użytkownika

Jeśli chcesz skonfigurować potoki YAML lub chcesz ulepszyć środowisko pracy z potokami klasycznymi, należy włączyć komunikację z usługi Azure Pipelines do usługi GitHub Enterprise Server.

Aby zezwolić na ruch z usługi Azure DevOps w celu dotarcia do serwera GitHub Enterprise Server, dodaj adresy IP lub tagi usług określone w sekcji Połączenia przychodzące do listy dozwolonych zapory. Jeśli używasz usługi ExpressRoute, dołącz również zakresy adresów IP usługi ExpressRoute do listy dozwolonych zapory.

Ograniczenia

  • Aby uzyskać najlepszą wydajność, zalecamy maksymalnie 50 potoków w jednym repozytorium. Aby uzyskać akceptowalną wydajność, zalecamy maksymalnie 100 potoków w jednym repozytorium. Czas wymagany do przetworzenia wypychania do repozytorium zwiększa się wraz z liczbą potoków w tym repozytorium. Za każdym razem, gdy istnieje wypychanie do repozytorium, usługa Azure Pipelines musi załadować wszystkie potoki YAML w tym repozytorium, aby dowiedzieć się, czy którykolwiek z nich musi zostać uruchomiony, a załadowanie każdego potoku wiąże się z karą za wydajność. Oprócz problemów z wydajnością zbyt wiele potoków w jednym repozytorium może prowadzić do ograniczenia przepustowości po stronie usługi GitHub, ponieważ usługa Azure Pipelines może wysyłać zbyt wiele żądań w krótkim czasie.
  • Użycie rozszerzeń i dołączania szablonów w potoku ma wpływ na szybkość, z jaką usługa Azure Pipelines wysyła żądania interfejsu API usługi GitHub i może prowadzić do ograniczania przepustowości po stronie usługi GitHub. Przed uruchomieniem potoku usługa Azure Pipelines musi wygenerować kompletny kod YAML, więc musi pobrać wszystkie pliki szablonu.
  • Usługa Azure Pipelines ładuje maksymalnie 2000 gałęzi z repozytorium do list rozwijanych w portalu usługi Azure Devops, na przykład w domyślnej gałęzi ręcznej i zaplanowanej kompilacji lub podczas wybierania gałęzi podczas ręcznego uruchamiania potoku. Jeśli na liście nie widzisz żądanej gałęzi, wpisz żądaną nazwę gałęzi ręcznie.

Często zadawane pytania

Problemy związane z integracją z usługą GitHub Enterprise należą do następujących kategorii:

  • Wyzwalacze zakończone niepowodzeniem: mój potok nie jest wyzwalany podczas wypychania aktualizacji do repozytorium.
  • Wyewidencjonowanie zakończone niepowodzeniem: mój potok jest wyzwalany, ale kończy się niepowodzeniem w kroku wyewidencjonowania.
  • Nieprawidłowa wersja: Mój potok jest uruchamiany, ale używa nieoczekiwanej wersji źródła/YAML.

Wyzwalacze zakończone niepowodzeniem

Właśnie utworzono nowy potok YAML z wyzwalaczami ciągłej integracji/żądania ściągnięcia, ale potok nie jest wyzwalany.

Wykonaj poszczególne z tych kroków, aby rozwiązać problemy z wyzwalaczami zakończonymi niepowodzeniem:

  • Elementy webhook służą do przekazywania aktualizacji z usługi GitHub Enterprise do usługi Azure Pipelines. W usłudze GitHub Enterprise przejdź do ustawień repozytorium, a następnie do pozycji Elementy webhook. Sprawdź, czy elementy webhook istnieją. Zazwyczaj powinny być widoczne dwa elementy webhook — wypychanie, pull_request. Jeśli tego nie zrobisz, musisz ponownie utworzyć połączenie z usługą i zaktualizować potok, aby używał nowego połączenia z usługą.

  • Wybierz poszczególne elementy webhook w usłudze GitHub Enterprise i sprawdź, czy ładunek odpowiadający zatwierdzeniu użytkownika istnieje i został pomyślnie wysłany do usługi Azure DevOps. W tym miejscu może zostać wyświetlony błąd, jeśli nie można przekazać zdarzenia do usługi Azure DevOps.

  • Gdy usługa Azure Pipelines odbiera powiadomienie z usługi GitHub, próbuje skontaktować się z usługą GitHub i pobrać więcej informacji o repozytorium i pliku YAML. Jeśli serwer GitHub Enterprise Server znajduje się za zaporą, ten ruch może nie dotrzeć do serwera. Zobacz Adresy IP usługi Azure DevOps i sprawdź, czy udzielono wyjątków do wszystkich wymaganych adresów IP. Te adresy IP mogły ulec zmianie, ponieważ pierwotnie skonfigurowano reguły wyjątków.

  • Czy potok jest wstrzymany lub wyłączony? Otwórz edytor potoku, a następnie wybierz pozycję Ustawienia, aby sprawdzić. Jeśli potok jest wstrzymany lub wyłączony, wyzwalacze nie działają.

  • Czy plik YAML został zaktualizowany w odpowiedniej gałęzi? Jeśli wypchniesz aktualizację do gałęzi, plik YAML w tej samej gałęzi zarządza zachowaniem ciągłej integracji. Jeśli wypchniesz aktualizację do gałęzi źródłowej, plik YAML wynikający z scalenia gałęzi źródłowej z gałęzią docelową zarządza zachowaniem żądania ściągnięcia. Upewnij się, że plik YAML w odpowiedniej gałęzi ma wymaganą konfigurację ciągłej integracji lub żądania ściągnięcia.

  • Czy wyzwalacz został poprawnie skonfigurowany? Podczas definiowania wyzwalacza YAML można określić zarówno klauzule dołączania, jak i wykluczania dla gałęzi, tagów i ścieżek. Upewnij się, że klauzula include jest zgodna ze szczegółami zatwierdzenia i że klauzula wykluczania nie wyklucza ich. Sprawdź składnię wyzwalaczy i upewnij się, że jest ona dokładna.

  • Czy użyto zmiennych podczas definiowania wyzwalacza lub ścieżek? To nie jest obsługiwane.

  • Czy używasz szablonów dla pliku YAML? Jeśli tak, upewnij się, że wyzwalacze są zdefiniowane w głównym pliku YAML. Wyzwalacze zdefiniowane wewnątrz plików szablonów nie są obsługiwane.

  • Czy wykluczyno gałęzie lub ścieżki, do których wypchnięliśmy zmiany? Przetestuj, wypychając zmianę do dołączonej ścieżki w dołączonej gałęzi. Należy pamiętać, że w wyzwalaczach uwzględniana jest wielkość liter. Podczas określania ścieżek w wyzwalaczach upewnij się, że używasz tego samego przypadku co foldery rzeczywiste.

  • Czy po prostu wypchnięliśmy nową gałąź? Jeśli tak, nowa gałąź może nie uruchomić nowego przebiegu. Zobacz sekcję "Zachowanie wyzwalaczy podczas tworzenia nowych gałęzi".

Moje wyzwalacze ciągłej integracji lub żądania ściągnięcia działają prawidłowo. Ale przestali teraz pracować.

Najpierw wykonaj kroki rozwiązywania problemów w poprzednim pytaniu, a następnie wykonaj następujące dodatkowe kroki:

  • Czy masz konflikty scalania w żądaniu ściągnięcia? W przypadku żądania ściągnięcia, które nie wyzwoliło potoku, otwórz go i sprawdź, czy ma konflikt scalania. Rozwiąż konflikt scalania.

  • Czy występuje opóźnienie przetwarzania zdarzeń wypychania lub żądania ściągnięcia? Zwykle można sprawdzić opóźnienie, sprawdzając, czy problem jest specyficzny dla pojedynczego potoku lub jest wspólny dla wszystkich potoków lub repozytoriów w projekcie. Jeśli wypychanie lub aktualizacja żądania ściągnięcia do dowolnego repozytorium wykazuje ten objaw, mogą wystąpić opóźnienia w przetwarzaniu zdarzeń aktualizacji. Oto kilka powodów, dla których może wystąpić opóźnienie:

    • Na naszej stronie stanu występuje awaria usługi. Jeśli na stronie stanu jest wyświetlany problem, nasz zespół musi już rozpocząć pracę nad nim. Sprawdź stronę często pod kątem aktualizacji problemu.
    • Repozytorium zawiera zbyt wiele potoków YAML. Aby uzyskać najlepszą wydajność, zalecamy maksymalnie 50 potoków w jednym repozytorium. Aby uzyskać akceptowalną wydajność, zalecamy maksymalnie 100 potoków w jednym repozytorium. Tym więcej potoków jest, tym wolniej przetwarzasz wypychanie do tego repozytorium. Za każdym razem, gdy istnieje wypychanie do repozytorium, usługa Azure Pipelines musi załadować wszystkie potoki YAML w tym repozytorium, aby ustalić, czy którykolwiek z nich musi zostać uruchomiony, a każdy nowy potok ponosi karę za wydajność.
    • Wystąpienie usługi GitHub Enterprise Server może być nieprowizowane, spowalniając przetwarzanie żądań z usługi Azure Pipelines. Przeczytaj więcej na temat zagadnień dotyczących sprzętu dla serwera GitHub Enterprise Server.

Nieudane wyewidencjonowanie

Czy używasz agentów hostowanych przez firmę Microsoft? Jeśli tak, ci agenci mogą nie być w stanie nawiązać połączenia z serwerem GitHub Enterprise Server. Aby uzyskać więcej informacji, zobacz Nieosiągalny dostęp od agentów hostowanych przez firmę Microsoft.

Nieprawidłowa wersja

W potoku jest używana nieprawidłowa wersja pliku YAML. Dlaczego?

  • W przypadku wyzwalaczy ciągłej integracji plik YAML, który znajduje się w wypychanej gałęzi, jest oceniany, aby sprawdzić, czy powinna zostać uruchomiona kompilacja ciągłej integracji.
  • W przypadku wyzwalaczy żądania ściągnięcia plik YAML wynikający z scalenia gałęzi źródłowych i docelowych żądania ściągnięcia jest oceniany, aby sprawdzić, czy powinna zostać uruchomiona kompilacja żądania ściągnięcia.