GitHub Actions Test Praktyczny
### Które stwierdzenie jest poprawne w odniesieniu do przekazywania uprawnień do wielokrotnego użycia w workflowach?
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#access-and-permissions
1. [x] Uprawnienia `GITHUB_TOKEN` przekazywane z workflow wywołującego mogą być obniżone tylko przez workflow wywoływany.
1. [ ] Uprawnienia `GITHUB_TOKEN` przekazywane z workflow wywołującego mogą być podniesione tylko przez workflow wywoływany.
1. [ ] Uprawnienia `GITHUB_TOKEN` przekazywane z workflow wywołującego mogą być zarówno obniżone, jak i podniesione przez workflow wywoływany.
1. [ ] Uprawnienia `GITHUB_TOKEN` przekazywane z workflow wywołującego nie mogą być ani obniżone, ani podniesione przez workflow wywoływany.
### Jakie są różne poziomy uprawnień, które można przypisać do `GITHUB_TOKEN` w bloku `permissions`?
> https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
1. [x] none, write, read
1. [ ] read, write, delete
1. [ ] read, write
### Możesz użyć `permissions`, aby zmodyfikować uprawnienia `GITHUB_TOKEN` na: (Wybierz dwa.)
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token
- [x] Poziom workflow
- [x] Poziom zadania (job)
- [ ] Poziom kroku (step)
### Czy GitHub Actions są darmowe dla publicznych repozytoriów?
1. [x] Tak
1. [ ] Nie
### Które z poniższych nie jest prawidłowym zdarzeniem, które może wyzwolić workflow?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows
1. [x] Klonowanie repozytorium
1. [ ] Wprowadzenie zmiany w pliku w gałęzi master
1. [ ] Utworzenie gałęzi
1. [ ] Dodanie etykiety do pull requesta
### Które stwierdzenia dotyczące workflowów są prawdziwe? (Zaznacz trzy.)
> https://docs.github.com/en/actions/using-workflows/about-workflows
- [x] Workflowy mogą uruchamiać jedno lub wiele zadań jednocześnie
- [x] Workflowy mogą być uruchamiane ręcznie, przez zdarzenie lub według harmonogramu
- [x] Workflowy muszą być zdefiniowane w katalogu `.github/workflows`
- [ ] Workflowy mogą być uruchamiane tylko według harmonogramu
- [ ] Workflow może uruchamiać tylko jedno zadanie na raz
- [ ] Workflowy są pisane w dowolnym z formatów `.yaml`, `.json` lub `.toml`
- [ ] Workflowy mogą być udostępniane w GitHub Marketplace
> Akcje (nie workflowy) mogą być udostępniane w GitHub Marketplace
### Które komponenty są wymagane dla workflow? (Wybierz dwa.)
> https://docs.github.com/en/actions/using-workflows/about-workflows#workflow-basics
- [x] Jedno lub więcej zdarzeń, które uruchomią workflow
- [x] Jedno lub więcej zadań (jobs)
- [ ] Nazwa workflow
- [ ] Określone gałęzie, na których workflow będzie działać
### Które zdarzenie jest wywoływane przez akcję webhooka spoza repozytorium?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
1. [x] repository_dispatch
1. [ ] webhook_dispatch
1. [ ] workflow_dispatch
1. [ ] remote_dispatch
1. [ ] api_dispatch
### Workflows są definiowane w jakim formacie
1. [x] yaml
1. [ ] toml
1. [ ] json
1. [ ] xml
### Gdzie powinieneś przechowywać poufne dane, takie jak hasła lub certyfikaty, które będą używane w workflowach
1. [x] secrets
1. [ ] zmienne konfiguracyjne
1. [ ] vault
1. [ ] zmienne środowiskowe
### W przepływie pracy z wieloma zadaniami domyślne zachowanie to:
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] Wszystkie zadania są wykonywane równolegle
1. [ ] Zadania są wykonywane w kolejności
### Jeśli zadanie B wymaga ukończenia zadania A, musisz:
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] użyć słowa kluczowego `needs` w zadaniu B, aby utworzyć tę zależność
1. [ ] użyć słowa kluczowego `needs` w zadaniu A, aby utworzyć tę zależność
1. [ ] użyć słowa kluczowego `requires` w zadaniu B, aby utworzyć tę zależność
1. [ ] użyć słowa kluczowego `requires` w zadaniu A, aby utworzyć tę zależność
### W przepływie pracy z wieloma zadaniami, jeśli zadanie A zakończy się niepowodzeniem, to:
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] zadania zależne od zadania A są pomijane
1. [ ] zadania zależne od zadania A kończą się niepowodzeniem
1. [ ] przepływ pracy natychmiast anuluje wszystkie pozostałe zadania
### Ten kod uruchomi 6 różnych zadań równolegle, wykorzystując strategię macierzy. Czy można użyć strategii macierzy do równoległego wykonywania całych przepływów pracy?
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-a-matrix-strategy-with-a-reusable-workflow
1. [ ] Nie
1. [x] Tak
### Która definicja zadania macierzy jest składniowo poprawna?
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [x]
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
1. [ ]
```yaml
jobs:
example_matrix:
matrix:
strategy:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
1. [ ]
```yaml
jobs:
example_matrix:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
1. [ ]
```yaml
jobs:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
### Jak uzyskać dostęp do zmiennych macierzy w zadaniu strategii macierzowej?
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [ ] Korzystając z kontekstu `vars`
1. [x] Korzystając z kontekstu `matrix`
1. [ ] Korzystając z kontekstu `job`
1. [ ] Korzystając z kontekstu `jobs`
### Jak skonfigurować workflow, aby uruchamiał się tylko przy pull requestach kierowanych na gałąź `prod`, korzystając z zdarzeń `pull_request` i `pull_request_target`?
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-filters-to-target-specific-branches-for-pull-request-events
1. [x] Użycie filtra `branches`
1. [ ] Użycie filtra `branch`
1. [ ] Utworzenie workflow tylko na gałęzi `prod`
1. [ ] Użycie wzorców glob
### Ten workflow zostanie uruchomiony dla wszystkich pull requestów, gdzie:
```yaml
on:
pull_request:
branches:
- 'release/**'
- '!release/**-alpha'
```
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#example-including-and-excluding-branches
1. [x] nazwa docelowej gałęzi zaczyna się od `release`, ale nie kończy się na `-alpha`
1. [ ] nazwa docelowej gałęzi zaczyna się od `release`
1. [ ] nazwa źródłowej gałęzi zaczyna się od `release`, ale nie kończy się na `-alpha`
1. [ ] nazwa źródłowej gałęzi zaczyna się od `release`
### Uzupełnij puste miejsce: Podczas korzystania z filtrów wyzwalaczy zdarzeń `push` możesz używać wzorców <____>, aby celować w wiele gałęzi
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-filters-to-target-specific-branches-or-tags-for-push-events
1. [x] glob
1. [ ] regex
1. [ ] scheme
1. [ ] action
### Które zdarzenie pozwala na ręczne uruchomienie przepływu pracy z interfejsu użytkownika GitHub?
> https://docs.github.com/en/actions/using-workflows/manually-running-a-workflow
1. [x] workflow_dispatch
1. [ ] manual_dispatch
1. [ ] workflow_trigger
1. [ ] manual_trigger
### Jakie są możliwe typy zmiennej wejściowej dla ręcznie uruchamianego workflow? (Wybierz pięć.)
> https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputsinput_idtype
- [x] choice
- [x] boolean
- [x] string
- [x] number
- [x] environment
- [ ] dropdown
- [ ] select
### Przepływ pracy, który ma tylko wyzwalacz zdarzenia `workflow_dispatch`, może być uruchomiony za pomocą REST API GitHuba
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputs
1. [x] Prawda
1. [ ] Fałsz
### Aby tymczasowo zatrzymać działanie przepływu pracy bez modyfikowania kodu źródłowego, powinieneś:
> https://docs.github.com/en/actions/using-workflows/disabling-and-enabling-a-workflow
1. [x] Użyć opcji `Disable workflow` w GitHub Actions
1. [ ] Usunąć sekrety wymagane dla tego przepływu pracy
1. [ ] Usunąć środowisko wymagane dla tego przepływu pracy
1. [ ] Uniemożliwić nowe commit-y w głównej gałęzi
### Do czego służą `typy aktywności` wydarzenia?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows
1. [x] Ograniczanie uruchamiania workflow do określonych typów aktywności za pomocą filtra `types`
1. [ ] Sprawdzanie, czy aktywność pochodzi od użytkownika czy bota
1. [ ] Reagowanie na nową aktywność w repozytorium (np. nowy współtwórca)
### Chcesz utworzyć wielokrotnego użycia przepływ pracy `CI`, który wykonuje niektóre kontrole jakości, linting i testy podczas zmian w kodzie. Jakie zdarzenie wyzwalające powinno zostać zdefiniowane w przepływie pracy `CI`, aby umożliwić jego ponowne użycie w innych przepływach pracy?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
1. [x] workflow_call
1. [ ] workflow_trigger
> Nie istnieje takie zdarzenie wyzwalające
1. [ ] workflow_dispatch
> To zdarzenie jest używane do ręcznych wywołań
1. [ ] workflow_run
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run
### Wielokrotnie używany przepływ pracy o nazwie `build` tworzy artefakty w postaci plików zip. Jak przekazać lokalizację pliku zip do wywołującego przepływu pracy, który wywołuje przepływ `build`? (Wybierz trzy.)
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow
- [x] Definiujesz wynik na poziomie przepływu pracy w przepływie `build`
- [x] Definiujesz wynik na poziomie zadania w przepływie `build`
- [x] W przepływie `build` zapisujesz wynik do `$GITHUB_OUTPUT` w jednym z kroków
- [ ] Wszystkie wyniki są automatycznie przekazywane do wywołujących przepływów pracy
### Jakie są prawidłowe przypadki użycia **defaults**? (Wybierz dwa.)
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaults
- [x] Użycie defaults.run na poziomie workflow do ustawienia domyślnej powłoki (np. bash) dla całego workflow
- [x] Użycie defaults.run na poziomie job do ustawienia domyślnego katalogu roboczego dla wszystkich kroków w jednym job
- [ ] Użycie defaults.run na poziomie step do ustawienia domyślnej powłoki (np. bash) dla tego pojedynczego kroku
> defaults.run można ustawić tylko na poziomie workflow lub job
- [ ] Użycie defaults.env na poziomie workflow do ustawienia domyślnych zmiennych środowiskowych dla całego workflow
> Nie istnieje coś takiego jak defaults.env
- [ ] Użycie defaults.env na poziomie job do ustawienia domyślnych zmiennych środowiskowych dla wszystkich kroków w jednym job
> Nie istnieje coś takiego jak defaults.env
### Jak zapewnić, aby przepływ pracy o nazwie `Deploy Prod` zawsze działał najwyżej raz na raz?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
1. [x] Użyj `concurrency` na poziomie przepływu pracy
```yaml
concurrency: ${{ github.workflow }}
```
1. [ ] Użyj `queue` na poziomie przepływu pracy
```yaml
queue: ${{ github.workflow }}
```
1. [ ] Użyj `order` na poziomie przepływu pracy
```yaml
order: ${{ github.workflow }}
```
1. [ ] Użyj `parallel` na poziomie przepływu pracy
```yaml
parallel: ${{ github.workflow }}
```
### Twoje workflow analizy Pull Request używa wielu narzędzi do analizy kodu i zajmuje około 20 minut na pełne ukończenie. Jest uruchamiane na zdarzenie `pull_request` z filtrem `branches` ustawionym na `master`. W związku z tym, jeśli programista wykona kilka commitów w ciągu kilku minut, wiele workflow działa równolegle. Jak można zatrzymać wszystkie poprzednie uruchomienia workflow i uruchomić tylko to z najnowszymi zmianami?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-concurrency-to-cancel-any-in-progress-job-or-run
1. [x] Użyj współbieżności z anulowaniem trwających procesów
```yaml
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
```
1. [ ] Użyj współbieżności
```yaml
concurrency:
group: ${{ github.ref }}
```
> To zgrupuje uruchomienia na tym samym github ref. Nie zatrzyma poprzednich uruchomień
1. [ ] Użyj filtra typów aktywności
```yaml
on:
pull_request:
branches:
- master
types: [latest]
```
> Nie istnieje taki typ aktywności jak `latest` dla zdarzenia pull_request
1. [ ] Użyj flagi cancel-in-progress dla zdarzenia `pull_request`
```yaml
on:
pull_request:
branches:
- master
cancel-in-progress: true
```
### Kiedy uruchomi się job3?
```yaml
jobs:
job1:
job2:
needs: job1
job3:
if: ${{ always() }}
needs: [job1, job2]
```
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-not-requiring-successful-dependent-jobs
1. [x] job3 uruchomi się po zakończeniu job1 i job2, niezależnie od tego, czy zakończyły się sukcesem
1. [ ] Nie możesz używać `if: ${{ always() }}` i `needs` jednocześnie. Workflow zakończy się błędem podczas uruchamiania.
1. [ ] job3 uruchomi się po pomyślnym zakończeniu job1 i job2
1. [ ] job3 uruchomi się po niepowodzeniu zarówno job1, jak i job2
### Jakie warunki `jobs.job_id.if` zapewnią, że zadanie `production-deploy` zostanie uruchomione tylko w repozytorium `my-org/my-repo`? (Wybierz dwa.)
```yaml
jobs:
production-deploy:
if: <CONDITION>
runs-on: ubuntu-latest
steps:
...
```
> https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
- [x] `if: github.repository == 'my-org/my-repo'`
- [x] `if: ${{ github.repository == 'my-org/my-repo' }}`
- [ ] `if: ${{ github.organization == 'my-org' && github.repository == 'my-repo' }}`
> https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
- [ ] `if: ${{ github.org == 'my-org' && github.repository == 'my-repo' }}`
> https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
### Jakie typy runnerów hostowanych przez GitHub są dostępne do użycia? (Wybierz trzy.)
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners
- [x] Windows
- [x] Ubuntu Linux
- [x] macOS
- [ ] Android
### Czy to stwierdzenie jest prawdziwe? `Nie wszystkie kroki uruchamiają akcje, ale wszystkie akcje są uruchamiane jako krok`
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsteps
1. [x] Prawda
1. [ ] Fałsz
> Kroki mogą, ale nie muszą uruchamiać akcji (np. uruchamianie polecenia run)
### Dla każdej akcji opublikowanej w GitHub Marketplace, często możesz używać jej w wielu wersjach. Które podejście jest najbardziej stabilne i bezpieczne?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-versioned-actions
1. [x] Odwołanie się do commit SHA
1. [ ] Odwołanie się do tagu wersji
1. [ ] Odwołanie się do głównej gałęzi
### Aby zapobiec awarii zadania, gdy jeden z kroków zawodzi, można użyć:
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error
1. [x] Flagi `continue-on-error` w kroku, który zawodzi
```yaml
steps:
- uses: my-org/failing-action@v1
continue-on-error: true
```
1. [ ] Flagi `ignore-error` w kroku, który zawodzi
```yaml
steps:
- uses: my-org/failing-action@v1
ignore-error: true
```
1. [ ] Warunku `failure()` w kroku, który zawodzi
```yaml
steps:
- uses: my-org/failing-action@v1
if: failure()
```
1. [ ] Warunku `always()` w kroku, który zawodzi
```yaml
steps:
- uses: my-org/failing-action@v1
if: always()
```
### Zdefiniowałeś zadanie macierzowe `example_matrix`. Jak ograniczyć macierz, aby uruchamiała maksymalnie 2 zadania jednocześnie?
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymax-parallel
1. [x] Ustaw `jobs.example_matrix.strategy.max-parallel` na 2
1. [ ] Ustaw `jobs.example_matrix.strategy.concurrency` na 2
1. [ ] Użyj REST API GitHub, aby sprawdzić, czy liczba zadań jest mniejsza niż 2
1. [ ] To niemożliwe, macierz zawsze uruchamia wszystkie zadania jednocześnie, jeśli są dostępne runnery
### Który z tych sposobów jest prawidłowym ustawieniem parametru wyjściowego `PET` z wartością `DOG` w kroku `step`.
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter
1. [x] `echo "PET=DOG" >> "$GITHUB_OUTPUT"`
1. [ ] `echo "DOG=PET" >> "$GITHUB_OUTPUT"`
1. [ ] `gh set-output "DOG=PET"`
1. [ ] `gh set-output "PET=DOG"`
### Który z poniższych jest sposobem użycia `action_state` w `step_two`?
```yaml
steps:
- name: Set the value
id: step_one
run: |
echo "action_state=yellow" >> "$GITHUB_ENV"
- name: Use the value
id: step_two
run: ?
```
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-of-writing-an-environment-variable-to-github_env
1. [x] `run: echo "$action_state"`
1. [ ] `run: echo "${{ steps.step_one.outputs.action_state }}"`
> Byłoby tak, gdyby `action_state` zostało zapisane do `$GITHUB_OUTPUT`
1. [ ] `run: echo "$steps.step_one.outputs.action_state"`
1. [ ] `run: echo "${{ action_state }}"`
### Czy to stwierdzenie jest prawdziwe? `Workflows can be reused, but a reusable workflow cannot call another reusable workflow.`
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#nesting-reusable-workflows
1. [x] Fałsz
1. [ ] Prawda
> Reusable workflows can be nested, but there are limitations https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations
### W poniższym przykładzie `workflow A` przekazuje wszystkie swoje sekrety do `workflow B`, używając słowa kluczowego inherit. Następnie `workflow B` wywołuje `workflow C`. Które stwierdzenie dotyczące `secrets` jest prawdziwe dla tego przykładu?
```yaml
jobs:
workflowA-calls-workflowB:
uses: octo-org/example-repo/.github/workflows/B.yml@main
secrets: inherit
```
```yaml
jobs:
workflowB-calls-workflowC:
uses: different-org/example-repo/.github/workflows/C.yml@main
```
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#passing-secrets-to-nested-workflows
1. [x] Wszystkie sekrety dostępne dla `workflow A` będą również dostępne dla `workflow B`, ale nie dla `workflow C`
1. [ ] Wszystkie sekrety organizacji `octo-org` i repozytorium `octo-org/example-repo` będą dostępne dla `workflow B`, ale nie dla `workflow C`
> Nie wszystkie sekrety organizacji `octo-org` muszą być dostępne dla `octo-org/example-repo`.
1. [ ] Wszystkie sekrety dostępne dla `workflow A` będą również dostępne dla `workflow B` i `workflow C`
> `Workflow B` musiałby dodać `secrets: inherit`, aby przekazać sekrety do `workflow C`
1. [ ] Tylko sekrety repozytorium i środowiska dostępne dla `workflow A` będą dostępne dla `workflow B`, ale nie dla `workflow C`. Sekrety na poziomie organizacji nie mogą być dziedziczone
### Kiedy powinieneś używać `keszowania`?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching
1. [x] Kiedy chcesz ponownie użyć plików, które nie zmieniają się często między zadaniami lub uruchomieniami przepływów pracy, takich jak zależności budowy z systemu zarządzania pakietami.
1. [ ] Kiedy chcesz ponownie użyć plików, które zmieniają się często między zadaniami lub uruchomieniami przepływów pracy, takich jak zależności budowy z systemu zarządzania pakietami.
1. [ ] Kiedy chcesz zapisać pliki wygenerowane przez zadanie, aby obejrzeć je po zakończeniu uruchomienia przepływu pracy, takie jak zbudowane pliki binarne lub dzienniki budowy.
> W tym celu należy używać artefaktów https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
1. [ ] Kiedy chcesz zapisać pliki binarne wygenerowane przez zadanie budowy, aby użyć ich w kolejnym zadaniu wdrożenia w celu wdrożenia nowej wersji aplikacji.
> W tym celu należy używać artefaktów https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
### Kiedy powinieneś używać `artifacts`? (Wybierz dwie.)
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#about-workflow-artifacts
- [x] Użyj artifacts, aby zapisać pliki wygenerowane przez zadanie, które można obejrzeć po zakończeniu działania workflow, takie jak wyniki testów lub logi kompilacji.
- [x] Użyj artifacts, aby zapisać pliki binarne wygenerowane przez zadanie kompilacji, które będą wykorzystane w kolejnym zadaniu wdrożeniowym w celu wdrożenia nowej wersji aplikacji.
- [ ] Użyj artifacts, aby ponownie wykorzystywać pliki, które nie zmieniają się często pomiędzy zadaniami lub uruchomieniami workflow, takie jak zależności kompilacji z systemu zarządzania pakietami.
> Do tego celu powinno być używane caching https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching
- [ ] Użyj artifacts, aby tworzyć nowe wersje swojej aplikacji wraz z release notes, wzmianek i/lub współtwórców.
> To jest przypadek użycia dla releases, a nie artifacts.
### Jeśli workflow jest uruchamiany na gałęzi `feature-a`, czy może przywracać `cache` utworzone na domyślnej gałęzi `main`?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache
1. [x] Tak, wszystkie gałęzie mogą przywracać cache utworzony na domyślnej gałęzi
1. [ ] Tak, wszystkie cache mogą być dostępne dla workflowów na dowolnej gałęzi w tym samym repozytorium
1. [ ] Nie, cache mogą być przywracane tylko z tej samej gałęzi
1. [ ] Tak, ale tylko jeśli żadne pliki nie zostały zmienione na gałęzi `feature-a`
### Aby uzyskać dostęp do `artykułu`, który został utworzony w innym, wcześniej uruchomionym przebiegu workflow, możesz:
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#about-workflow-artifacts
1. [x] Nie możesz uzyskać dostępu do `artykułów`, które zostały utworzone w innym przebiegu workflow
1. [ ] Użyj akcji `actions/download-artifact`.
1. [ ] Użyj akcji `actions/upload-artifact`.
1. [ ] Użyj akcji `actions/download-artifact` i upewnij się, że artykuł nie wygasł
### Czego należy użyć do przechowywania raportów pokrycia kodu lub zrzutów ekranu generowanych podczas realizacji przepływu pracy wykonującego testy automatyczne dla repozytorium?
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#comparing-artifacts-and-dependency-caching
1. [x] Artefakty
1. [ ] Bufory
1. [ ] Pakiety
> https://docs.github.com/en/packages/learn-github-packages/introduction-to-github-packages
1. [ ] Wydania
> https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases
### Możesz przesyłać tylko jeden plik naraz, korzystając z akcji `actions/upload-artifact`
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#uploading-build-and-test-artifacts
1. [x] Fałsz
1. [ ] Prawda
### W zadaniu `deploy`, jeśli chcesz uzyskać dostęp do plików binarnych (zawierających Twoją aplikację) utworzonych w zadaniu `build`, powinieneś
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#comparing-artifacts-and-dependency-caching
1. [x] przesłać pliki binarne jako artefakty w `build` i pobrać je w `deploy`
1. [ ] przesłać pliki binarne jako artefakty w `deploy` i pobrać je w `build`
1. [ ] zapisać pliki binarne w pamięci podręcznej w `build` i odczytać je z pamięci podręcznej w `deploy`
1. [ ] zapisać pliki binarne w pamięci podręcznej w `deploy` i odczytać je z pamięci podręcznej w `build`
### Zadanie o nazwie `job2` wykorzystuje artefakty utworzone w `job1`. W związku z tym ważne jest, aby `job1` zakończyło się przed tym, jak `job2` zacznie szukać artefaktów. Jak należy utworzyć taką zależność?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds
1. [x] utwórz tę zależność za pomocą słowa kluczowego `needs` w `job2`
1. [ ] ta zależność jest tworzona automatycznie podczas używania `actions/download-artifact` do pobierania artefaktu z `job1`
1. [ ] utwórz tę zależność, definiując `job2` po `job1` w pliku `.yaml` przepływu pracy
1. [ ] utwórz tę zależność za pomocą słowa kluczowego `concurrency` w `job2`
### Które stwierdzenie dotyczy `Starter Workflows`? (Wybierz trzy.)
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
- [x] Pozwalają użytkownikom korzystać z gotowych (lub wymagających minimalnych zmian) szablonów przepływów pracy
- [x] GitHub dostarcza i utrzymuje starter workflows dla różnych kategorii, języków i narzędzi
- [x] Twoja organizacja może tworzyć niestandardowe starter workflows dla użytkowników w swojej organizacji
- [ ] Starter workflows nie mogą wywoływać reusable workflows
- [ ] Starter workflows są płatną funkcją GitHuba
- [ ] Starter workflows są dostarczane jako gotowe rozwiązanie i nie można ich modyfikować ani ulepszać
> https://docs.github.com/en/actions/using-workflows/using-starter-workflows#using-starter-workflows
### Sekrety i zmienne konfiguracyjne mogą być przypisane do: (Wybierz trzy.)
> https://docs.github.com/en/actions/using-workflows/sharing-workflows-secrets-and-runners-with-your-organization#sharing-secrets-and-variables-within-an-organization
- [x] Całej organizacji lub wybranych repozytoriów w organizacji
- [x] Pojedynczego repozytorium
- [x] Środowiska w repozytorium
- [ ] Środowiska współdzielonego pomiędzy wieloma repozytoriami
> Środowiska nie mogą być współdzielone pomiędzy repozytoriami
- [ ] Wielu repozytoriów, które nie są częścią organizacji/przedsiębiorstwa
- [ ] Określonego przepływu pracy w repozytorium
> Zmienne środowiskowe mogą być przypisane do przepływu pracy, zmienne konfiguracyjne nie
- [ ] Określonego zadania w przepływie pracy
> Zmienne środowiskowe mogą być przypisane do przepływu pracy, zmienne konfiguracyjne nie
### Jakie są trzy typy Akcji?
> https://docs.github.com/en/actions/creating-actions/about-custom-actions#types-of-actions
1. [x] `Docker container actions`, `JavaScript Actions`, `Composite Actions`
1. [ ] `Python Actions`, `JavaScript Actions`, `Custom Actions`
1. [ ] `Docker container Actions`, `JavaScript Actions`, `Custom Actions`
1. [ ] `Docker container actions`, `Java Actions`, `Composite Actions`
### Czy to stwierdzenie jest prawdziwe? `Akcje kontenerów Docker są zazwyczaj wolniejsze niż akcje JavaScript`
> Akcje kontenerów Docker są wolniejsze niż akcje JavaScript
1. [x] Prawda
1. [ ] Fałsz
> Ze względu na opóźnienia związane z budowaniem i pobieraniem kontenera, akcje kontenerów Docker są wolniejsze niż akcje JavaScript.
### Podczas tworzenia niestandardowego GitHub Action musisz przechowywać kod źródłowy w katalogu `.github/workflows`
> https://docs.github.com/en/actions/creating-actions/about-custom-actions#choosing-a-location-for-your-action
1. [x] Fałsz
1. [ ] Prawda
> To dotyczy `workflows`, a nie `actions`
### Podczas tworzenia niestandardowych GitHub Actions - w jakim pliku muszą być zdefiniowane wszystkie dane `metadata` akcji?
Przykłady danych: nazwa, opis, wyjścia lub wymagane wejścia
> https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions
1. [x] W pliku `action.yml` lub `action.yaml` w repozytorium akcji
1. [ ] W pliku `README` repozytorium
> Chociaż to dobra praktyka, nie jest to wymagane, aby akcja działała
1. [ ] Edytuje się to w interfejsie GitHub Marketplace podczas publikowania w celu udostępnienia
1. [ ] W pliku `action.yml` lub `action.yaml` w repozytorium akcji, ale nie jest to wymagane, jeśli akcja nie ma być udostępniana i używana publicznie
> Wszystkie akcje wymagają pliku z danymi metadata.
### Workflow został początkowo uruchomiony na `commit A` i zakończył się niepowodzeniem. Naprawiłeś workflow w kolejnym `commit B`. Gdy ponownie uruchomisz ten workflow, z którym kodem commit będzie działał?
> https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs#about-re-running-workflows-and-jobs
1. [x] Będzie działał z kodem z `commit A`
1. [ ] Będzie działał z kodem z `commit B`
> Ponowne uruchomienie workflow używa tego samego identyfikatora SHA commitu i referencji Git, co w oryginalnym zdarzeniu, które wywołało uruchomienie workflow.
1. [ ] Nie można ponownie uruchamiać workflow w GitHub Actions. Trzeba wywołać nowy workflow, który będzie działał z najnowszymi zmianami
1. [ ] Uruchomi dwa workflowy, jeden z kodem z `commit A` i jeden z kodem z `commit B`
### Jak wymagać ręcznych zatwierdzeń przez opiekuna, jeśli uruchomienie workflow jest skierowane na środowisko `production`?
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment
1. [x] Użycie zasad ochrony wdrożeń (deployment protection rules)
1. [ ] Ustawienie wymaganych recenzentów w workflow `production`
1. [ ] Użycie zasad ochrony gałęzi (branch protection rules)
1. [ ] Ręczne zatwierdzenia nie są obsługiwane przez GitHub Actions
### Które stwierdzenie jest prawdziwe w odniesieniu do środowisk?
> Każde zadanie w przepływie pracy może odwoływać się do jednego środowiska.
1. [x] Każde zadanie w przepływie pracy może odwoływać się do jednego środowiska.
1. [ ] Każdy przepływ pracy może odwoływać się do jednego środowiska.
1. [ ] Każde zadanie w przepływie pracy może odwoływać się maksymalnie do dwóch środowisk.
1. [ ] Każdy przepływ pracy może odwoływać się maksymalnie do dwóch środowisk.
### Przy korzystaniu z GitHub Actions w celu uzyskania dostępu do zasobów jednego z dostawców chmury (takich jak AWS, Azure czy GCP), najbezpieczniejszym i zalecanym sposobem uwierzytelniania jest
> https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
1. [x] Korzystanie z OIDC
1. [ ] Korzystanie z Vault
1. [ ] Przechowywanie kluczy dostępu w `secrets`
> Używanie długotrwałych kluczy dostępu nie jest zalecane ze względu na ryzyko wycieków danych lub ataków, takich jak [iniekcja skryptów](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#understanding-the-risk-of-script-injections)
1. [ ] Przechowywanie kluczy dostępu w `variables`
> Wrażliwe wartości nie powinny być przechowywane w `variables`
### Twoje publicznie dostępne repozytorium open-source zawiera przepływ pracy z wyzwalaczem zdarzenia `pull_request`. Jak możesz wymagać zatwierdzeń dla uruchomień przepływu pracy wyzwolonych z forków Twojego repozytorium?
> https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks#about-workflow-runs-from-public-forks
1. [x] Skonfiguruj wymagane zatwierdzenia dla uruchomień forków w repozytorium
1. [ ] Skonfiguruj reguły ochrony wdrożeń dla repozytorium
> Reguły ochrony wdrożeń są używane do ochrony środowisk
1. [ ] Skonfiguruj reguły ochrony gałęzi dla repozytorium
1. [ ] Przepływ pracy nie uruchomi się dla forków, jeśli użyto zdarzenia `pull_request`. Jeśli chcesz to zrobić, powinieneś użyć wyzwalacza zdarzenia `fork_pull_request` z flagą `require-approval`.
### Która z poniższych domyślnych zmiennych środowiskowych zawiera nazwę osoby lub aplikacji, która zainicjowała uruchomienie workflow?
> https://docs.github.com/en/actions/reference/environment-variables#default-environment-variables
1. [ ] `GITHUB_USER`
1. [ ] `GITHUB_REPOSITORY`
1. [ ] `GITHUB_WORKFLOW`
1. [x] `GITHUB_ACTOR`
### Które z poniższych są domyślnymi zmiennymi środowiskowymi w GitHub Actions? (Wybierz trzy.)
> https://docs.github.com/en/actions/reference/environment-variables#default-environment-variables
- [x] `GITHUB_REPOSITORY`
- [x] `GITHUB_WORKFLOW`
- [x] `GITHUB_ACTOR`
- [ ] `GITHUB_USER`
- [ ] `GITHUB_ORGANIZATION`
- [ ] `GITHUB_TOKEN`
### Twoja organizacja definiuje sekret `SomeSecret`, jednak gdy odwołujesz się do tego sekretu w workflow za pomocą `${{ secrets.SomeSecret }}`, zwracana jest inna wartość niż oczekiwano. Co może być tego przyczyną?
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#naming-your-secrets
1. [x] Sekret `SomeSecret` jest również zadeklarowany w zakresie repozytorium
1. [ ] Sekret `SomeSecret` jest również zadeklarowany w zakresie przedsiębiorstwa
> Jeśli sekret o tej samej nazwie istnieje na różnych poziomach, sekret na najniższym poziomie ma pierwszeństwo.
1. [ ] Wyrażenie `${{ secrets.SomeSecret }}` jest używane tylko dla sekretów o zakresie repozytorium
1. [ ] Musisz użyć GitHub API, aby uzyskać dostęp do sekretów o zakresie organizacji
### Który sposób jest poprawny, aby wyświetlić komunikat debugowania?
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-setting-a-debug-message
1. [x] `echo "::debug::Watch out here!"`
1. [ ] `echo ":debug:Watch out here!"`
1. [ ] `echo "::debug::message=Watch out here!"`
1. [ ] `echo "Watch out here!" >> $GITHUB_DEBUG`
### Jak organizacje korzystające z GitHub Enterprise Server mogą włączyć automatyczną synchronizację zewnętrznych GitHub Actions hostowanych na GitHub.com z ich instancją GitHub Enterprise Server?
> https://docs.github.com/en/[email protected]/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect
1. [x] Korzystając z GitHub Connect
1. [ ] GitHub Enterprise Server ma domyślnie dostęp do wszystkich akcji na GitHub.com
> GitHub Actions na GitHub Enterprise Server zostały zaprojektowane do pracy w środowiskach bez pełnego dostępu do Internetu. Domyślnie workflowy nie mogą używać akcji z GitHub.com i GitHub Marketplace.
1. [ ] Korzystając z narzędzia actions-sync
> https://docs.github.com/en/[email protected]/admin/github-actions/managing-access-to-actions-from-githubcom/manually-syncing-actions-from-githubcom#about-the-actions-sync-tool
1. [ ] GitHub Enterprise Server nie może używać akcji na GitHub.com ze względu na jego lokalny charakter i brak dostępu do Internetu
### Gdzie można znaleźć logi łączności sieciowej dla własnego hostowanego runnera GitHub?
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners#checking-self-hosted-runner-network-connectivity
1. [x] W folderze `_diag` bezpośrednio na maszynie runnera
1. [ ] Na GitHub.com na stronie konkretnego runnera
1. [ ] W logach uruchomienia zadania, które było wykonywane na tym runnerze
1. [ ] W logach uruchomienia zadania, które było wykonywane na tym runnerze z włączonym logowaniem debugowania
### Jak można zweryfikować, czy Twój samodzielnie hostowany runner GitHub ma dostęp do wszystkich wymaganych usług GitHub?
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners#checking-self-hosted-runner-network-connectivity
1. [x] Za pomocą skryptu dostarczonego przez GitHub na maszynie z runnerem
1. [ ] Próbując uzyskać dostęp do maszyny z runnerem przez `ssh`, aby zweryfikować łączność sieciową
1. [ ] Korzystając z predefiniowanego workflow GitHub Actions `network-connectivity.yml`
1. [ ] GitHub automatycznie zweryfikuje łączność sieciową przy instalacji aplikacji runnera na maszynie z runnerem
### Jaki jest poprawny sposób wyzwalania zadania tylko wtedy, gdy zmienna konfiguracyjna `MY_VAR` ma wartość `MY_VALUE`?
> https://docs.github.com/en/actions/learn-github-actions/contexts#example-usage-of-the-vars-context
1. [x] Poprzez utworzenie następującego warunku na poziomie zadania:
```yaml
my-job:
if: ${{ vars.MY_VAR == 'MY_VALUE' }}
```
1. [ ] Poprzez utworzenie następującego warunku na poziomie zadania:
```yaml
my-job:
if: ${{ vars.MY_VAR }} == 'MY_VALUE'
```
> To zawsze będzie ewaluowane jako True
1. [ ] To nie jest możliwe, ponieważ zmienne konfiguracyjne nie mogą być używane w warunkach `if`
> To prawda dla `secrets`, ale nie dla zmiennych konfiguracyjnych
1. [ ] To nie jest możliwe, ponieważ zmienne konfiguracyjne nie mogą być używane w warunkach `if` na poziomie zadania
> To prawda dla `secrets`, ale nie dla zmiennych konfiguracyjnych
### Aby uruchomić `step` tylko wtedy, gdy sekret `MY_SECRET` został ustawiony, możesz:
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-secrets
1. [x] Ustawić sekret `MY_SECRET` jako zmienną środowiskową na poziomie zadania, a następnie odnieść się do tej zmiennej środowiskowej, aby warunkowo uruchomić ten krok
```yaml
my-job:
runs-on: ubuntu-latest
env:
my_secret: ${{ secrets.MY_SECRET }}
steps:
- if: ${{ env.my_secret != '' }}
```
1. [ ] Tworząc następujący warunek na poziomie zadania
```yaml
my-job:
runs-on: ubuntu-latest
if: ${{ secrets.MY_SECRET == '' }}
```
> sekrety nie mogą być bezpośrednio odniesione w warunkach `if:`
1. [ ] Tworząc następujący warunek na poziomie kroku
```yaml
my-job:
runs-on: ubuntu-latest
steps:
- if: ${{ secrets.MY_SECRET == '' }}
```
> sekrety nie mogą być bezpośrednio odniesione w warunkach `if:`
1. [ ] Tworząc następujący warunek na poziomie kroku
```yaml
my-job:
runs-on: ubuntu-latest
steps:
- if: ${{ secrets.MY_SECRET }}
```
> sekrety nie mogą być bezpośrednio odniesione w warunkach `if:`
### Jak można użyć API GitHub do pobrania logów z uruchomienia workflow?
> https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28#download-workflow-run-logs
1. [x] `GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
1. [ ] `POST /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
1. [ ] `HEAD /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
1. [ ] `PUT /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
### Jak użyć GitHub API do utworzenia lub zaktualizowania sekretu repozytorium?
> https://docs.github.com/en/rest/actions/secrets?create-or-update-a-repository-secret=&apiVersion=2022-11-28#create-or-update-a-repository-secret
1. [x] `PUT /repos/{owner}/{repo}/actions/secrets/{secret_name}`
1. [ ] `POST /repos/{owner}/{repo}/actions/secrets/{secret_name}`
1. [ ] `HEAD /repos/{owner}/{repo}/actions/secrets/{secret_name}`
1. [ ] `GET /repos/{owner}/{repo}/actions/secrets/{secret_name}`
### Jak można zastąpić organizacyjny sekret GitHub `API_KEY` inną wartością podczas pracy w repozytorium? (Wybierz dwie.)
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#naming-your-secrets
- [x] Tworząc sekret repozytorium o tej samej nazwie `API_KEY`
- [x] Tworząc sekret środowiska o tej samej nazwie `API_KEY`
- [ ] Tworząc sekret przedsiębiorstwa o tej samej nazwie `API_KEY`
- [ ] Tworząc sekret przedsiębiorstwa o nazwie `OVERRIDE_API_KEY`
- [ ] Tworząc sekret repozytorium o nazwie `OVERRIDE_API_KEY`
- [ ] Tworząc sekret środowiska o nazwie `OVERRIDE_API_KEY`
- [ ] Tworząc sekret repozytorium o nazwie `REPOSITORY_API_KEY`
- [ ] Tworząc sekret środowiska o nazwie `ENVIRONMENT_API_KEY`
### Jakie komponenty można ponownie wykorzystać w ramach organizacji na GitHub? (Wybierz cztery.)
- [x] Sekrety
- [x] Zmienne konfiguracyjne
- [x] Samodzielnie hostowane runnery
- [x] Szablony workflow
- [ ] Artefakty
> Artefakty są używane do zachowania danych po zakończeniu zadania i/lub udostępniania tych danych innemu zadaniu w ramach tego samego workflow.
- [ ] Cache
> Cache może być ponownie wykorzystywany w workflowach w ramach jednego repozytorium.
- [ ] Zmienne środowiskowe
> Zmienne środowiskowe mogą być przypisane do kroku, zadania lub workflow. Nie mogą być udostępniane pomiędzy workflowami/repozytoriami lub organizacjami.
### Ile zadań zostanie wykonanych w poniższym przepływie pracy?
```yaml
jobs:
matrix-job:
runs-on: ubuntu-latest
strategy:
matrix:
pet: [cat, dog]
color: [pink, brown]
include:
- color: white
pet: dog
steps:
- run: echo "Hello ${{ matrix.color }} ${{ matrix.pet }}"
```
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [x] 5
1. [ ] 4
1. [ ] 6
1. [ ] 7
### Która z poniższych domyślnych zmiennych środowiskowych zawiera pełną nazwę (np. `octocat/hello-world`) repozytorium, w którym uruchamiane jest workflow?
> https://docs.github.com/en/actions/reference/environment-variables#default-environment-variables
1. [x] `GITHUB_REPOSITORY`
1. [ ] `GITHUB_REPOSITORY_ID`
1. [ ] `GITHUB_REPOSITORY_OWNER`
1. [ ] `GITHUB_REPOSITORY_OWNER_ID`
### W przepływie pracy z wieloma zadaniami uruchamianymi na hostowanych przez GitHub runnerach, czy wszystkie zadania są gwarantowane do uruchomienia na tej samej maszynie runnera?
> https://docs.github.com/en/actions/using-jobs/choosing-the-runner-for-a-job#choosing-github-hosted-runners
1. [x] Nie
1. [ ] Tak
> Każde zadanie jest uruchamiane w nowej instancji obrazu runnera określonego przez runs-on
### Jaka jest maksymalna liczba wielokrotnego użytku workflows, które można wywołać z jednego pliku workflow?
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations
1. [x] 20
1. [ ] 5
1. [ ] 1
1. [ ] 10
### Czym jest self-hosted runner?
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
1. [x] Self-hosted runner to system, który wdrażasz i zarządzasz nim, aby wykonywać zadania z GitHub Actions na GitHub.com
1. [ ] Self-hosted runner to system do przesyłania kodu na prywatny serwer
1. [ ] Self-hosted runner to system umożliwiający automatyczne tworzenie obciążeń
1. [ ] Self-hosted runner to system do zarządzania pull requestami użytkowników organizacji
### Które z poniższych stwierdzeń dotyczących GitHub Workflows i Actions jest poprawne?
> https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
1. [ ] Każda akcja składa się z jednego lub więcej workflow, które składają się z jednego lub więcej zadań (jobs), a każde zadanie składa się z jednego lub więcej kroków (steps)
1. [ ] Każdy workflow składa się z jednej lub więcej akcji (action), które składają się z jednego lub więcej zadań, a każde zadanie składa się z jednego lub więcej kroków
1. [x] Każdy workflow składa się z jednego lub więcej zadań (jobs), które składają się z jednego lub więcej kroków (steps), a każdy krok jest akcją lub skryptem
1. [ ] Każda akcja składa się z jednego lub więcej zadań, które składają się z jednego lub więcej kroków, a każdy krok to workflow
### Na którym commicie i gałęzi uruchamiają się zaplanowane przepływy pracy w GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
1. [ ] Zaplanowane przepływy pracy uruchamiają się na określonym commicie na ostatnio modyfikowanej gałęzi.
> nieprawidłowe, zarówno określony commit, jak i ostatnio modyfikowana gałąź
1. [ ] Zaplanowane przepływy pracy uruchamiają się na określonym commicie na gałęzi main.
> nieprawidłowe, zarówno określony commit, jak i gałąź main
1. [x] Zaplanowane przepływy pracy uruchamiają się na najnowszym commicie na domyślnej gałęzi repozytorium.
1. [ ] Zaplanowane przepływy pracy uruchamiają się na najnowszym commicie na gałęzi main.
> najnowszy commit jest prawidłowy, ale gałąź main nie
### Jaka jest poprawna składnia ustawiania katalogu dla wszystkich poleceń `run` w przepływie pracy?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunworking-directory
1. [x] ustaw `working-directory` w sekcji `defaults.run`
```yaml
defaults:
run:
shell: bash
working-directory: ./scripts
```
1. [ ] ustaw `directory` w sekcji `defaults.run`
```yaml
defaults:
run:
shell: bash
directory: ./scripts
```
1. [ ] ustaw `working-directory` w sekcji `job`
```yaml
defaults:
run:
shell: bash
job:
working-directory: ./scripts
```
1. [ ] ustaw `directory` w sekcji `job`
```yaml
defaults:
run:
shell: bash
job:
directory: ./scripts
```
### Jak można ponownie wykorzystać zdefiniowany workflow w wielu repozytoriach? (Wybierz dwie odpowiedzi.)
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
- [ ] Kopiując plik workflow do każdego repozytorium
- [x] Korzystając z szablonów workflow
- [ ] Tworząc wielokrotnego użycia akcję (reusable action)
- [x] Definiując workflow w centralnym repozytorium
### Jak możesz zapewnić, że zadanie uruchamia się tylko na określonej gałęzi?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#using-filters
1. [x] Używając filtra branches
1. [ ] Używając filtra runs-on
1. [ ] Używając filtra jobs
1. [ ] Używając słowa kluczowego branch
### Co robi słowo kluczowe `needs` w workflow GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds
1. [x] Określa zależności danego zadania
1. [ ] Definiuje zmienne środowiskowe
1. [ ] Konfiguruje środowisko
1. [ ] Uruchamia zadanie na podstawie zdarzenia
### Które słowo kluczowe pozwala zdefiniować zmienne środowiskowe w przepływie pracy GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenv
1. [x] env
1. [ ] vars
1. [ ] secrets
1. [ ] config
### Jaki jest cel słowa kluczowego `with` w przepływie pracy GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepswith
1. [ ] Do definiowania zmiennych środowiskowych
1. [x] Do określenia parametrów wejściowych dla akcji
1. [ ] Do konfiguracji zależności
1. [ ] Do uruchamiania innego przepływu pracy
### Która z poniższych składni GitHub Actions jest używana do uruchamiania wielu poleceń w jednym kroku?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/workflow-commands-for-github-actions#example-of-a-multiline-string
1. [ ] Użycie && do łączenia poleceń
1. [ ] Definiowanie poleceń w tablicy
1. [x] Użycie wielowierszowego ciągu z |
1. [ ] Oddzielanie poleceń średnikiem ;
### Jak można buforować zależności, aby przyspieszyć wykonywanie przepływu pracy?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/caching-dependencies-to-speed-up-workflows#about-caching-workflow-dependencies
1. [ ] Używając słowa kluczowego cache
1. [x] Używając akcji actions/cache
1. [ ] Przechowując je w repozytorium
1. [ ] Używając słowa kluczowego store
### Co robi słowo kluczowe `matrix` w przepływie pracy GitHub Actions?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-a-matrix-for-your-jobs
1. [x] Pozwala zdefiniować wiele konfiguracji zadań do wykonywania równolegle
1. [ ] Ustawia zmienne środowiskowe dla zadania
1. [ ] Wyzwala przepływy pracy na podstawie harmonogramu
1. [ ] Definiuje sekrety dla przepływu pracy
### Które z poniższych można użyć do ograniczenia liczby równocześnie uruchomionych zadań w przebiegu GitHub Actions?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-concurrency
1. [x] concurrency
1. [ ] limit
1. [ ] max-jobs
1. [ ] parallelism
### Jaki jest domyślny limit czasu dla zadania w GitHub Actions?
> https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits
1. [ ] 30 minut
1. [ ] 60 minut
1. [ ] 120 minut
1. [x] 360 minut
### Jak można określić system operacyjny dla zadania w GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on
1. [ ] Używając słowa kluczowego os
1. [x] Używając słowa kluczowego runs-on
1. [ ] Używając słowa kluczowego platform
1. [ ] Używając słowa kluczowego env
### W przepływie pracy GitHub Actions, jak określić konkretną wersję Node.js do użycia w zadaniu?
> https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-nodejs#specifying-the-nodejs-version
1. [x]
```yaml
uses: actions/setup-node@v4
with:
node-version: 20
```
1. [ ]
```yaml
uses: actions/node-setup@v4
with:
node-version: 20
```
1. [ ]
```yaml
uses: setup-node@v4
with:
version: 20
```
1. [ ]
```yaml
uses: setup-node@v4
with:
node: 20
```
### Jak odwołać się do sekretu przechowywanego w GitHub Secrets w workflow?
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow
1. [x] ${{ secrets.SECRET_NAME }}
1. [ ] ${{ secret.SECRET_NAME }}
1. [ ] ${{ env.SECRET_NAME }}
1. [ ] ${{ config.SECRET_NAME }}
### Jaka jest domyślna powłoka używana przez GitHub Actions na serwerach Windows?
> https://github.blog/changelog/2019-10-17-github-actions-default-shell-on-windows-runners-is-changing-to-powershell/
1. [ ] bash
1. [ ] sh
1. [x] powershell
1. [ ] cmd
### Które z poniższych stwierdzeń dotyczących dodawania hostowanego samodzielnie runnera w GitHub Actions są prawdziwe? (Wybierz trzy.)
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners#adding-a-self-hosted-runner-to-a-repository
- [x] Możesz dodać hostowanego samodzielnie runnera do repozytorium
- [x] Możesz dodać hostowanego samodzielnie runnera do organizacji
- [x] Możesz dodać hostowanego samodzielnie runnera do przedsiębiorstwa
- [ ] Nie możesz dodać hostowanego samodzielnie runnera do poziomu workflow
> Nie możesz dodać na poziomie workflow
- [ ] Nie możesz dodać hostowanego samodzielnie runnera do poziomu kroku
> Nie możesz dodać na poziomie kroku
### Wybierz domyślną zmienną środowiskową, która zawiera system operacyjny runnera wykonującego zadanie
> https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables
1. [x] `RUNNER_OS`
1. [ ] `GITHUB_RUNNER_OS`
1. [ ] `RUNNER_ARCH`
1. [ ] `RUNNER_NAME`
### Jak `actions/cache` w GitHub Actions obsługuje brak trafienia w cache?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#managing-caches
1. [ ] wymaga ręcznej interwencji w celu utworzenia nowego cache
1. [ ] szukając cache w innych repozytoriach
1. [x] automatycznie tworząc nowy cache, jeśli zadanie zakończy się pomyślnie
1. [ ] przerywając działanie workflow w przypadku braku trafienia w cache
### Jak można określić harmonogram działania workflow GitHub Actions, aby uruchamiał się tylko w dni robocze?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
1. [ ] dodać warunek w YAML workflow dla dni roboczych
1. [ ] nie jest to możliwe w GitHub Actions
1. [ ] użyć on: schedule: weekdays jako wyzwalacza zdarzeń
1. [x] użyć on: schedule: cron jako wyzwalacza zdarzeń
### Jakie jest zalecane podejście do przechowywania sekretów większych niż 48 KB?
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#limits-for-secrets
1. [ ] unikać całkowitego przechowywania dużych sekretów w celu zapewnienia bezpieczeństwa
1. [ ] sekrety większe niż 48 KB nie mogą być przechowywane
1. [x] zaszyfrować i przechowywać sekrety w repozytorium, ale passphrase do deszyfrowania zachować jako sekret
1. [ ] przechowywać duże sekrety bezpośrednio jako sekrety repozytorium, aby uniknąć ograniczeń
### Wybierz funkcje sprawdzania statusu w GitHub Actions
> https://docs.github.com/en/actions/learn-github-actions/expressions#status-check-functions
1. [x] `success()`, `always()`, `cancelled()` i `failure()`
1. [ ] `completed()`, `always()`, `cancelled()` i `failure()`
1. [ ] `status()`, `always()`, `cancelled()` i `failure()`
1. [ ] `state()`, `always()`, `cancelled()` i `failure()`
### Jak zapewnić, aby krok `Upload Failure test report` był wykonywany tylko wtedy, gdy krok `Run Tests` zakończy się niepowodzeniem?
> https://docs.github.com/en/actions/learn-github-actions/expressions#status-check-functions
1. [x]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
if: failure() && steps.run-tests.outcome == 'failure'
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
1. [ ]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
if: always() && steps.run-tests.outcome == 'failure'
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
1. [ ]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
if: steps.run-tests.outcome == 'failure'
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
1. [ ]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
### Który kontekst zawiera informacje o zdarzeniu, które wywołało uruchomienie workflow?
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-event-information
1. [x] `github.event`
1. [ ] `github.repository`
1. [ ] `github.job`
1. [ ] `jobs.<job_id>.result`
### W GitHub Actions, jeśli zdefiniujesz jednocześnie filtry branches i paths, jaki będzie efekt dla wykonywania workflow?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore
1. [x] workflow uruchomi się tylko wtedy, gdy zarówno `branches`, jak i `paths` zostaną spełnione
1. [ ] workflow uruchomi się, gdy zostanie spełniony którykolwiek z warunków `branches` lub `paths`, ale zastosuje tylko pasujący filtr
1. [ ] workflow uruchomi się, gdy zostanie spełniony którykolwiek z warunków `branches` lub `paths`
1. [ ] workflow nie uruchomi się, gdy zarówno `branches`, jak i `paths` zostaną spełnione
### Jakie są zalecane praktyki dotyczące traktowania zmiennych środowiskowych w GitHub Actions, niezależnie od używanego systemu operacyjnego i powłoki?
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-an-environment-variable
1. [x] traktować zmienne środowiskowe jako wielkość liter ma znaczenie
1. [ ] używać tylko wielkich liter w nazwach zmiennych środowiskowych
1. [ ] ignorować rozróżnianie wielkości liter, ponieważ GitHub Actions robi to automatycznie
1. [ ] polegać na zachowaniu używanego systemu operacyjnego
### Które z poniższych stwierdzeń dokładnie opisuje zachowanie zadań w przepływie pracy odwołujących się do reguł ochrony środowiska?
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment
1. [x] zadania w przepływie pracy nie rozpoczną się, dopóki wszystkie reguły ochrony środowiska nie zostaną spełnione
1. [ ] zadania w przepływie pracy nigdy się nie rozpoczną, jeśli środowisko ma reguły ochrony
1. [ ] zadania w przepływie pracy rozpoczną się natychmiast, niezależnie od reguł ochrony środowiska
1. [ ] zadania w przepływie pracy rozpoczną się tylko wtedy, gdy niektóre reguły ochrony środowiska zostaną spełnione
### Jaki jest cel parametru `restore-keys` w `actions/cache` w GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#managing-caches
1. [x] podać alternatywne klucze do użycia w przypadku braku trafienia w cache
1. [ ] wskazać, czy nastąpiło trafienie w cache
1. [ ] określić lokalizację plików z cache
1. [ ] włączyć funkcjonalność cache między systemami operacyjnymi
### Którą zmienną należałoby ustawić na `true`, aby włączyć logowanie debugowania kroków?
> https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging
1. [x] `ACTIONS_STEP_DEBUG`
1. [ ] `ACTIONS_JOB_DEBUG`
1. [ ] `ACTIONS_RUNNER_DEBUG`
1. [ ] `ACTIONS_WORKFLOW_DEBUG`
### Jaka konfiguracja jest odpowiednia do uruchomienia workflow w odpowiedzi na zdarzenia webhook związane z akcjami check_run?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#check_run
1. [x]
```yaml
on:
check_run:
types: [rerequested, completed]
```
1. [ ]
```yaml
on:
check_run:
types: [started]
```
1. [ ]
```yaml
on:
check_run:
type: [closed]
```
1. [ ]
```yaml
on:
check_run:
filter: [requested]
```
### Jaki jest cel użycia słowa kluczowego `timeout-minutes` w kroku?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepstimeout-minutes
1. [x] ogranicza czas wykonania pojedynczego kroku
1. [ ] definiuje interwał czasowy dla pojedynczych poleceń w kroku
1. [ ] ustawia limit czasu oczekiwania na zewnętrzne zdarzenia przed przejściem do kolejnego kroku
1. [ ] określa maksymalny czas, przez jaki dozwolone jest działanie zadania
### Dave tworzy szablonowy przepływ pracy dla swojej organizacji. Gdzie Dave musi przechowywać pliki przepływów pracy oraz powiązane pliki metadanych dla szablonowego przepływu pracy?
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
1. [x] w katalogu o nazwie `workflow-templates` w repozytorium o nazwie `.github`
1. [ ] w katalogu o nazwie `workflow-templates` w bieżącym repozytorium
1. [ ] w katalogu o nazwie `.github/org-templates`
1. [ ] w katalogu o nazwie `.github/workflow-templates`
### Dave chce być powiadamiany, gdy komentarz zostanie dodany do zgłoszenia w repozytorium GitHub. Które wyzwalanie zdarzeń należy użyć w konfiguracji przepływu pracy?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment
1. [x] `issue_comment`
1. [ ] `issues.comment`
1. [ ] `issues`
1. [ ] `comment`
### Jakiego poziomu dostępu wymaga repozytorium na GitHubie, aby usunąć pliki dziennika z uruchomień przepływów pracy?
> https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs
1. [x] write
1. [ ] read
1. [ ] admin
1. [ ] owner
### Co jest prawdą na temat poniższej konfiguracji przepływu pracy, jeśli zostanie uruchomiona w repozytorium `octo/my-dev-repo`?
```yaml
name: deploy-workflow
on: [push]
jobs:
production-deploy:
if: github.repository == 'octo/my-prod-repo'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '14'
- run: npm install -g bats
```
> https://docs.github.com/en/actions/using-jobs/using-conditions-to-control-job-execution
1. [x] zadanie `production-deploy` zostanie oznaczone jako pominięte
1. [ ] zadanie `production-deploy` zakończy się błędem
1. [ ] zadanie `production-deploy` wykona trzy kroki
1. [ ] zadanie `production-deploy` zostanie uruchomione, jeśli `node-version` to `14`
### Jak uzyskać dostęp do aktualnych wartości zmiennych w macierzy w ramach zadania w poniższym przykładzie:
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [x] odwołując się do zmiennych za pomocą kontekstu `matrix` z użyciem składni, takiej jak `matrix.version` i `matrix.os`
1. [ ] używając składni `matrix.property`
1. [ ] używając słowa kluczowego `context` w konfiguracji zadania
1. [ ] uzyskując dostęp do zmiennych bezpośrednio za pomocą składni `version` i `os`
### Jakiego poziomu uprawnień wymaga ponowne uruchomienie przepływów pracy?
> https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs
1. [x] write
1. [ ] read
1. [ ] admin
1. [ ] owner
### Kiedy można usunąć uruchomienia przepływu pracy? (wybierz dwa)
> https://docs.github.com/en/actions/managing-workflow-runs/deleting-a-workflow-run
- [x] Gdy uruchomienie przepływu pracy zostało zakończone
- [x] Gdy uruchomienie przepływu pracy ma dwa tygodnie
- [ ] Gdy uruchomienie przepływu pracy ma 10 dni
- [ ] Gdy uruchomienie przepływu pracy jest w toku
### Kto może ominąć skonfigurowane reguły ochrony wdrażania, aby wymusić wdrożenie (domyślnie)
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#allow-administrators-to-bypass-configured-protection-rules
1. [x] Administratorzy repozytorium
1. [ ] Każdy z uprawnieniami zapisu w repozytorium
1. [ ] Każdy z uprawnieniami odczytu w repozytorium
### Jak pominąć uruchomienie kolejnego przepływu pracy podczas commitowania lub tworzenia PR?
```yaml
name: Build
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
name: Extract artifact version
...
```
>https://docs.github.com/en/actions/managing-workflow-runs/skipping-workflow-runs
1. [x] Poprzez umieszczenie dowolnego z następujących słów kluczowych w wiadomości commita lub w tytule pull requesta:
```yaml
[skip ci]
[ci skip]
[no ci]
[skip actions]
[actions skip]
```
1. [ ] Podając `SKIP_WORKFLOW` w wiadomości commita
1. [ ] Powyższy przepływ pracy będzie uruchamiany w każdym przypadku zdarzenia push lub pull requesta
### Jak można określić, czy akcja jest akcją kontenerową, patrząc na jej plik action.yml?
> https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-docker-container-actions
1. [x] `runs.using` ma wartość `docker`
1. [ ] `runs.using` ma wartość `container`
1. [ ] `runs.using` ma wartość `Dockerfile`
1. [ ] `runs.main` ma wartość `container`
### Jaka jest poprawna składnia do określenia skryptu czyszczącego w akcji kontenera?
> https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runspost-entrypoint
1. [x]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
post-entrypoint: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
post: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
after: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
after-entrypoint: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
cleanup: 'cleanup.sh'
```
### Co jest prawdą o domyślnych zmiennych? (wybierz trzy)
> https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables
- [x] Domyślne zmienne środowiskowe są ustawiane przez GitHub i nie są definiowane w pliku workflow
- [x] Większość domyślnych zmiennych środowiskowych ma odpowiadającą im właściwość w kontekście
- [x] Obecnie wartość domyślnej zmiennej środowiskowej CI może być nadpisana, ale nie ma gwarancji, że zawsze będzie to możliwe
- [ ] Możesz dodać nową domyślną zmienną środowiskową, dodając do niej prefiks „GITHUB_”
- [ ] Domyślne zmienne środowiskowe zawsze mają prefiks „GITHUB_”
- [ ] Domyślne zmienne środowiskowe mogą być dostępne za pomocą kontekstu env
### Jakie zakresy są zdefiniowane dla zmiennych niestandardowych w przepływie pracy? (wybierz trzy)
> https://docs.github.com/en/actions/learn-github-actions/variables#defining-environment-variables-for-a-single-workflow
- [x] Cały przepływ pracy, używając `env` na najwyższym poziomie pliku przepływu pracy
- [x] Zawartość zadania w przepływie pracy, używając `jobs.<job_id>.env`
- [x] Konkretnego kroku w zadaniu, używając `jobs.<job_id>.steps[*].env`
- [ ] Wszystkich zadań w przepływie pracy, używając `jobs.env`
- [ ] Całego przepływu pracy, używając `custom.env` na najwyższym poziomie pliku przepływu pracy
- [ ] Konkretnego środowiska w repozytorium, używając `environment.<environment_id>.env` na najwyższym poziomie pliku przepływu pracy
### Co należy dodać do `actions/checkout`, jeśli `my-org/my-private-repo` jest prywatnym repozytorium różniącym się od tego, które zawiera obecny workflow?
```yaml
name: deploy-workflow
on: [push]
jobs:
my-job:
runs-on: ubuntu-latest
steps:
- name: "Checkout GitHub Action"
uses: actions/checkout@v4
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
```
> https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#example-using-an-action-inside-a-different-private-repository-than-the-workflow
1. [x] Utwórz sekret GitHub `MY_ACCESS_TOKEN`
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: ${{ secrets.MY_ACCESS_TOKEN }}
```
1. [ ] Utwórz wejście `MY_ACCESS_TOKEN`
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: ${{ MY_ACCESS_TOKEN }}
```
1. [ ] Zmienna środowiskowa `GITHUB_TOKEN`
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: $GITHUB_TOKEN
```
1. [ ] Pozostaw bez zmian, ponieważ tokeny dostępowe będą przekazywane automatycznie
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
```
### Mając poniższą konfigurację, ile zadań uruchomi GitHub Actions, gdy ta macierz zostanie oceniona?
```yaml
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node: [14, 16]
include:
- os: macos-latest
node: 18
- os: ubuntu-latest
node: 14
```
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow#expanding-or-adding-matrix-configurations
1. [ ] 4 zadania
1. [x] 5 zadań
1. [ ] 6 zadań
1. [ ] 7 zadań
1. [ ] Żadne zadania nie zostaną uruchomione, ponieważ składnia jest nieprawidłowa.
### Na jakich poziomach można definiować zmienne środowiskowe? (Wybierz trzy)
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables
- [x] Poziom przepływu pracy (Workflow level)
- [x] Poziom zadania (Job level)
- [x] Poziom kroku (Step level)
- [ ] Poziom akcji (Action level)
### W jaki sposób zależne zadanie powinno odwoływać się do wartości `output1` wygenerowanej przez zadanie o nazwie `job1` wcześniej w tym samym przebiegu działania?
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/passing-information-between-jobs
1. [x] `${{needs.job1.outputs.output1}}`
1. [ ] `${{job1.outputs.output1}}`
1. [ ] `${{needs.job1.output1}}`
1. [ ] `${{depends.job1.output1}}`
Szczegóły
Czy ten test praktyczny okazał się pomocny?
Zostaw ⭐ w repozytorium i rozważ wsparcie społeczności poprzez:
- kontrybucję jednego lub więcej pytań do egzaminu próbnego (zajmuje kilka minut)