" - System ciągłej integracji \"wbudowany\" w GitHub\n",
" - Darmowy dla publicznych repozytoriów (z większymi niż w płatnych planach [ograniczeniami dotyczącymi zasobów](https://docs.github.com/en/actions/reference/usage-limits-billing-and-administration#usage-limits))\n",
" "
]
},
{
"cell_type": "markdown",
"id": "2b06cc01",
"metadata": {},
"source": [
"https://youtu.be/cP0I9w2coGU"
]
},
{
"cell_type": "markdown",
"id": "b66dd41f",
"metadata": {},
"source": [
"### Terminologia Github Actions\n",
" - *Workflow* - workflow odpowiada \"Pipeline\" z Jenkinsa.\n",
" - *Job* - workflow składa się z jednego lub kilku \"jobs\". Każdy z nich może być wykonywany równolegle na innej maszynie (patrz \"runner\")\n",
" - *Step* - odpowiednik \"Stage\" z Jenkinsa - służu do grupowania \"Actions\"\n",
" - *Action* - odpowiednik \"Step\" z Jenkinsa - pojedyncze polecenie do wykonania, np. dodanie komentarze do Pull requesta, wykonanie polecenia systemowego itp.\n",
" - *Runner* - odpowiednik Jenkinsowego \"Agent\" - serwer, na którym mogą być wykonywane zadania (\"jobs\")\n",
" - *Github-hosted runner* - serwer utrzymywany przez Github (2-core CPU, 7 GB RAM, 14 GB SSD). Windows, Linux albo macOS\n",
" - *Self-hosted runner* - nasz własny serwer, z zinstalowaną aplikacją [Github actions runner](https://github.com/actions/runner)\n",
" - *Event* - zdażenie, które odapala (\"triggers\") uruchomienie Workflow. Np. wypchnięcie zmiany do repozytorium (\"push\"), utworzenie Pull requesta. [Pełna lista](https://docs.github.com/en/actions/reference/events-that-trigger-workflows)"
]
},
{
"cell_type": "markdown",
"id": "9f1f6d0a",
"metadata": {},
"source": [
"### Definicja workflow\n",
" - Workflow definiuje się w plikach YAM(o rozszerzeniu `*.yml` albo `*.yaml`) umieszczonych w specjalnym folderze `.github/workflows/` wewnątrz repozytorium\n",
" - Pełna składnia jest opisana [tutaj](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions)\n",
" - Podstawowe pola:\n",
" - `name` [opcjonalna] - nazwa, pod którą workflow/step będzie widoczny w UI. Domyślnie ścieżka do pliku yaml\n",
" - `on` - definiuje kiedy workflow ma być odpalony\n",
" - `jobs` - grupuje razem \"zadania\" do wykonania. Każde może być wykonane na innym \"runnerze\". Domyślnie wykonywane są równolegle (ale możemy definiować [zależności między jobami](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds), co powoduje wykonanie ich sekwencyjnie\n",
" - `runs-on` - parametr joba, definujący na jakiej maszynie wirtualnej ma być uruchomiony (np. `ubuntu-latest`)\n",
" - `uses` - umożliwia użycie gotowych akcji zdefiniowanych przez nas, albo przez innych użytkowników, np. `-uses: actions/checkout@v2` spowoduje checkout plików z repozytorium\n",
" - `run` - pozwala uruchomić dowolne ([dostępne/zainstalowane](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#preinstalled-software)) polecenie, np. `python3 train.py`\n",
" - `env` - pozwala zdefiniować zmienne środowiskowe dostępne dla akcji lub skorzystać ze [zmiennych ustawionych przez Github](https://docs.github.com/en/actions/reference/environment-variables#default-environment-variables)"
"Maszyny wirtualne (\"runners\"), na których uruchamiane są \"joby\" mają zainstalowany zbiór narzędzi. Przykładowa lista dla [Ubuntu 20.04](https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md)\n",
"\n",
"Brakujące zależności można zainstalować, korzystając z:\n",
" - akcji\n",
" - poleceń systemowych takich jak `apt install` czy `pip install` uruchomionych poprzez `run`. Patrz [przykład](https://docs.github.com/en/actions/using-github-hosted-runners/customizing-github-hosted-runners#installing-software-on-ubuntu-runners)"
]
},
{
"cell_type": "markdown",
"id": "28b582c4",
"metadata": {},
"source": [
"### Akcje\n",
"Za pomocą polecenia `uses` możemy używać przygotowanych wcześniej akcji. Mogą one pochodzić:\n",
" - z tego samego repozytorium co workflow ([więcej](https://docs.github.com/en/actions/learn-github-actions/finding-and-customizing-actions#referencing-an-action-in-the-same-repository-where-a-workflow-file-uses-the-action))\n",
" - z dowolnego publicznego repozytorium Github (np. [repozytorioum iterative/setup-clm](https://github.com/iterative/setup-cml), patrz przykład poniżej\n",
" - z [Github Marketplace](https://github.com/marketplace?type=actions)"
]
},
{
"cell_type": "markdown",
"id": "805622e8",
"metadata": {},
"source": [
"## CML - Continous Machine Learning\n",
"<img src=\"img/expcontrol/cml.png\">"
]
},
{
"cell_type": "markdown",
"id": "e0b3acbf",
"metadata": {},
"source": [
" - Tworzone przez [iterative.ai](iterative.ai) (tak jak DVC)\n",
" - https://cml.dev/\n",
" - Dokumentacja: https://dvc.org/doc/cml\n",
" - Korzysta z Github Actions lub Gitlab CI (a także [Bitbucket Pipelines](https://github.com/iterative/cml/wiki/CML-with-Bitbucket-Cloud))\n",
" - CML dodaje do Github Actions kilka \"akcji\":\n",
"2. Stwórz publiczne repozytorium. Link do niego wklej do kolumny \"Link Github\" w arkuszu [\"Zapisy na zbiory\"](https://teams.microsoft.com/l/file/F62B5988-A797-418D-B085-52E0AF8BD55E?tenantId=73689ee1-b42f-4e25-a5f6-66d1f29bc092&fileType=xlsx&objectUrl=https%3A%2F%2Fuam.sharepoint.com%2Fsites%2F2021SL06-DIUMUI0LABInynieriauczeniamaszynowego-Grupa11%2FShared%20Documents%2FGeneral%2FZapisy%20na%20zbiory.xlsx&baseUrl=https%3A%2F%2Fuam.sharepoint.com%2Fsites%2F2021SL06-DIUMUI0LABInynieriauczeniamaszynowego-Grupa11&serviceName=teams&threadId=19:d67b0dc2ee0849eba517a2aa8507df9c@thread.tacv2&groupId=8cd6b30e-edd9-48db-85ab-259fc11d0c5b) [1 pkt]\n",
" - ściągnie pliki trenujące. Najlepiej byłoby to zrobić za pomocą DVC, ale tym razem uprośćmy zadanie ze względu na koplikacje, które mogą się pojawić przy konfiguracji uwierzytelniania. Pliki można po prostu dodać do repozytorium albo ściągnąć przez wget jeśli są publicznie dostępne [2 pkt]\n",
" - dokona trenowania i ewaluacji [8 pkt]\n",
" - wyniki opublikuje za pomocą `cml-send-github-check` i/lub `cml-send-comment` [2 pkt]"