Aby umożliwić zespołom, które współtworzą źródła inne niż podstawowe, pełne prawo własności do procesu weryfikacji w projektach Trade Federation, utworzyliśmy te projekty z otwartymi prawami do +2 dla wszystkich zespołów. Zwalnia to główny zespół Trade Federation z obowiązku weryfikacji kodu niezwiązanego z główną strukturą, a jednocześnie umożliwia innym zespołom szybsze przeprowadzanie weryfikacji.
Non-core src to kod, który nie jest wymagany przez platformę tradefederation do działania (np. testy niestandardowe, konfiguracje, określone narzędzia testowe).
WAŻNE: źródło inne niż podstawowe nie powinno rozszerzać podstawowych klas Trade Federation. Ma to wpływ na przyszłe refaktoryzacje i czyszczenie kodu. Jeśli nie masz pewności, czy Twój kod powinien znajdować się w podstawowej czy dodatkowej części projektu, skontaktuj się z zespołem android-tradefed@, aby uzyskać wyjaśnienie. Główny zespół Trade Federation chętnie udzieli Ci porad i przyjmie prośby o dodanie funkcji.
Przykładową klasą podstawową Trade Federation może być dowolna klasa w pakiecie
com.google.android.tradefed.build, np.:com.google.android.tradefed.build.LaunchControlProviderJeśli nie wiesz, co jest uważane za klasę podstawową, skontaktuj się z nami pod adresem android-tradefed@.
[TOC]
Ścieżki projektów Contrib
Dla kogo są przeznaczone projekty kontrybucji?
Jeśli pracujesz obecnie nad projektami Trade Federation, pisząc testy, narzędzia testowe lub konfiguracje, te projekty zostały utworzone dla Ciebie.
Weryfikacja kodu w projektach zewnętrznych
Celem projektów dodatkowych jest umożliwienie Ci tworzenia kodu w Tradefed bez konieczności sprawdzania go przez zespół podstawowy (android-tradefed@). Oczekujemy więc, że Twój zespół lub ktokolwiek znający Twój kontekst przeprowadzi weryfikację kodu w przypadku Twoich zmian.
Jeśli masz problem lub potrzebujesz wskazówek w konkretnym przypadku, zawsze możesz skontaktować się z zespołem android-tradefed@. Nie polegaj jednak na nim domyślnie w przypadku weryfikacji kodu w contrib. Zespół Tradefed nie ma docelowego poziomu usług w przypadku weryfikacji kodu w projekcie contrib.
Gdzie mogę zacząć pracę nad tymi projektami?
Zostały one dodane do tych plików manifestu gałęzi i są już częścią głównej platformy płatności, więc jeśli nie widzisz projektów w swoim środowisku, wystarczy zsynchronizować repozytorium, aby móc wnieść swój wkład.
- główne
- tradefed
- oc-dev
- oc-dev-plus-aosp
- nyc-mr2-dev-plus-aosp
- main-daydream-dev
- main-without-vendor
- wear-main
Programowanie i testowanie
Projekty w contrib powinny mieć taką samą jakość jak inne projekty w repozytoriach Androida:
- Przestrzegaj wytycznych dotyczących formatowania w Androidzie.
- Kod jest testowany i przesyłany wraz z testami
- Przemyślana i logiczna konstrukcja
Jak testować lokalnie w przypadku projektu contrib?
AOSP
W AOSP testy jednostkowe komponentów znajdują się w folderze platform/tools/tradefederation/contrib/tests/src/, a testy jednostkowe należy dodać do com.android.tradefed.prodtests.UnitTests, aby były uwzględniane w skryptach testów przed przesłaniem i testów lokalnych.
Skrypty lokalne AOSP po uruchomieniu polecenia lunch:
tools/tradefederation/core/tests/run_tradefed_aosp_presubmit.sh
Tworzenie aktualizacji reguł w projektach dla współtwórców
Reguły kompilacji (pliki makefile) znajdują się w osobnym folderze build/ i są zablokowane przez plik OWNERS, który uniemożliwia ich modyfikowanie bez dodatkowej weryfikacji przez zespół główny. To jedyne ograniczenie projektu contrib.
Jest nam to potrzebne, aby mieć pewność, że do ogólnych projektów Tradefed nie są dodawane nieoczekiwane zależności bez wiedzy lub zgody zespołu głównego.
Jeśli naprawdę potrzebujesz dodania nowych zależności, skontaktuj się z android-tradefed@, aby przeanalizować Twoje przypadki użycia i udzielić Ci porady.