Oprogramowanie niestandardowe z repozytoriów źródłowych

Receptury OpenFactory mogą wskazywać repozytorium Git jako wejście custom package na obsługiwanych builderach obrazów. To ścieżka wrażliwa na łańcuch dostaw: repozytorium, rozwiązana rewizja, instrukcje pakowania, zależności buildu i wyprodukowany pakiet wymagają przeglądu.

Obsługa zależy od celu. Buildy source package są odrzucane na niektórych builderach, w tym na obecnych ścieżkach Raspberry Pi i Proxmox. Potwierdź dostępność w znormalizowanej recepturze i planie buildu, zanim obiecujesz, że pakiet zostanie wyprodukowany.

Kształt receptury

Wpisy custom package znajdują się pod os.custom_packages:

{
  "os": {
    "custom_packages": [
      {
        "name": "my-agent",
        "git_url": "https://github.com/example/my-agent.git",
        "branch": "release-1.x"
      }
    ]
  }
}

Schemat akceptuje nazwę gałęzi, a nie niezmienne pole commit. Przy kontrolowanym wydaniu zapisz dokładny commit rozwiązany przez build i włącz go do zachowanej provenance. Sama ruchoma gałąź nie jest reprodukowalnym wejściem.

Przygotuj repozytorium

Obecna ścieżka pakietu oczekuje natywnych metadanych pakowania dopasowanych do celu. Typowe przykłady to katalog Debian debian/ lub spec RPM. Dokładne zachowanie buildera i obsługiwane wersje celu mogą się zmieniać, więc zweryfikuj minimalny pakiet w wdrożonym środowisku zamiast polegać na statycznej tabeli zgodności.

Przy pakowaniu Debian sprawdź co najmniej:

• debian/control pod kątem tożsamości source/binary i zależności;
• debian/changelog pod kątem wersji pakietu;
• debian/rules i inne wykonywalne skrypty maintainera;
• manifesty instalacji i jednostki systemd; oraz
• licencjonowanie i dołączony materiał stron trzecich.

Przy pakowaniu RPM sprawdź źródła w spec, wymagania buildu, scriptlety, listę plików i metadane licencji.

Nigdy nie zakładaj, że własność repozytorium czyni jego skrypty buildu bezpiecznymi. Buildy pakietów wykonują niezaufane źródło i logikę pakowania w granicy izolacji infrastruktury buildu.

Inne sterowanie pakietami

Pakiety natywne

Użyj os.packages dla pakietów już dostarczanych przez wybraną dystrybucję lub jawnie skonfigurowane repozytorium:

{
  "os": {
    "packages": ["curl", "jq"]
  }
}

Nadpisania pakietów

os.package_overrides może deklarować intencję add, remove lub replace:

{
  "os": {
    "package_overrides": [
      {"name": "nano", "action": "replace", "replacement": "neovim"},
      {"name": "telnet", "action": "remove"}
    ]
  }
}

Nadpisanie nie dowodzi, że rozwiązywanie zależności je uwzględniło. Zweryfikuj końcowy inwentarz pakietów oraz asercje absence/presence.

Dodatkowe repozytoria

os.extra_repos to zaawansowane wejście. Nie dodawaj niepodpisanego repozytorium HTTP jak w starszych przykładach. Zatwierdzona integracja repozytorium wymaga transportu HTTPS, przypiętego klucza podpisu, egzekwowania podpisów, metadanych release dopasowanych do menedżera pakietów oraz udokumentowanej własności i polityki aktualizacji. Jeśli bieżący builder nie może odzwierciedlić tych kontroli zaufania, nie używaj repozytorium.

Dowody akceptacji

Dla każdego custom package zachowaj:

• URL repozytorium i rozwiązany commit;
• przegląd źródła i zadeklarowanej licencji;
• środowisko buildu i snapshot zależności;
• logi buildu oraz wynikową nazwę/wersję/architekturę pakietu;
• digest pakietu i dowód podpisu repozytorium, gdy ma to zastosowanie;
• końcowy inwentarz obrazu z zainstalowanym pakietem;
• smoke testy usługi lub pliku wykonywalnego; oraz
• zachowanie przy usuwaniu i aktualizacji.

Udany etap source package nie wystarczy. Build obrazu może później nie skonsumować pakietu, a zainstalowany pakiet nadal może być bezużyteczny.

Rozwiązywanie problemów

• Odrzucone metadane pakowania: zweryfikuj pakiet natywny lokalnie na tej samej wersji dystrybucji i architekturze.
• Brak zależności buildu: używaj zależności z zatwierdzonych repozytoriów dla tego celu; nie pobieraj po cichu dowolnych binariów w skrypcie maintainera.
• Pakietu brak w obrazie: porównaj wyprodukowaną nazwę pakietu binarnego z znormalizowanym żądaniem instalacji i końcowym inwentarzem.
• Wersja się nie zmieniła: zaktualizuj natywne metadane wersji i potwierdź, że rozwiązano nowy commit źródłowy.
• Usługa nie działa: sprawdź jednostkę, zależności runtime, uprawnienia i logi gościa; dodaj asercję na poziomie zachowania przed ponownym buildem.