GitHub Actions Test Praktyczny
### Które stwierdzenie jest poprawne w odniesieniu do przekazywania uprawnień do wielokrotnie używanych workflows?
> 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ć jedynie zredukowane przez workflow wywoływane.
1. [ ] Uprawnienia `GITHUB_TOKEN` przekazywane z workflow wywołującego mogą być jedynie podwyższone przez workflow wywoływane.
1. [ ] Uprawnienia `GITHUB_TOKEN` przekazywane z workflow wywołującego mogą być zarówno zredukowane, jak i podwyższone przez workflow wywoływane.
1. [ ] Uprawnienia `GITHUB_TOKEN` przekazywane z workflow wywołującego nie mogą być ani zredukowane, ani podwyższone przez workflow wywoływane.
### Jakie są różne poziomy uprawnień, które możesz 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] Poziomie workflow
- [x] Poziomie zadania (job)
- [ ] Poziomie 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 wyzwalającym workflow?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows
1. [x] Klonowanie repozytorium
1. [ ] Zatwierdzenie pliku do gałęzi master
1. [ ] Utworzenie gałęzi
1. [ ] Dodanie etykiety do pull requesta
### Które stwierdzenie dotyczące workflows jest prawdziwe? (Wybierz trzy.)
> https://docs.github.com/en/actions/using-workflows/about-workflows
- [x] Workflows mogą uruchamiać jednocześnie jedno lub wiele zadań (jobs)
- [x] Workflows mogą być uruchamiane ręcznie, przez zdarzenie lub według harmonogramu
- [x] Workflows muszą być zdefiniowane w katalogu `.github/workflows`
- [ ] Workflows mogą być uruchamiane tylko według harmonogramu
- [ ] Workflow może uruchomić tylko jedno zadanie (job) na raz
- [ ] Workflows mogą być napisane w dowolnym z formatów `.yaml`, `.json` lub `.toml`
- [ ] Workflows mogą być udostępniane w GitHub Marketplace
> Actions (a nie workflows) mogą być udostępniane w GitHub Marketplace
### Jakie 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
- [ ] Zdefiniowane gałęzie, na których workflow będzie działać
### Które zdarzenie jest wyzwalane 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 którym formacie
1. [x] yaml
1. [ ] toml
1. [ ] json
1. [ ] xml
### Gdzie należy przechowywać poufne dane, takie jak hasła czy certyfikaty, które będą używane w workflows?
1. [x] secrets
1. [ ] config variables
1. [ ] vault
1. [ ] environment variables
### 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ą uruchamiane równolegle
1. [ ] Zadania są uruchamiane w kolejności
### Jeśli zadanie B wymaga zakoń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 stworzyć tę zależność
1. [ ] użyć słowa kluczowego `needs` w zadaniu A, aby stworzyć tę zależność
1. [ ] użyć słowa kluczowego `requires` w zadaniu B, aby stworzyć tę zależność
1. [ ] użyć słowa kluczowego `requires` w zadaniu A, aby stworzyć tę zależność
### W przypadku przepływu 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 inne zadania
### Ten kod uruchomi 6 różnych zadań równolegle przy użyciu strategii macierzy. Czy można użyć strategii macierzy do równoległego wykonywania całych workflowów?
```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óre zdefiniowanie zadania macierzy jest składniowo poprawne?
> 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 macierzy?
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [ ] Używając kontekstu `vars`
1. [x] Używając kontekstu `matrix`
1. [ ] Używając kontekstu `job`
1. [ ] Używając kontekstu `jobs`
### Jak skonfigurować workflow, aby uruchamiał się tylko podczas celowania w gałąź `prod`, używając 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żywając filtra `branches`
1. [ ] Używając filtra `branch`
1. [ ] Tworząc workflow tylko na gałęzi `prod`
1. [ ] Używając wzorców glob
### Ten workflow uruchomi się we wszystkich pull requestach, 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 wyzwalania zdarzeń `push` możesz używać wzorców <____>, aby skierować działania na 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 ręcznie uruchomić workflow 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ć uruchamiany za pomocą REST API GitHub
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputs
1. [x] Prawda
1. [ ] Fałsz
### Aby tymczasowo zatrzymać wykonywanie workflow bez modyfikowania kodu źródłowego, należy
> https://docs.github.com/en/actions/using-workflows/disabling-and-enabling-a-workflow
1. [x] Użyj opcji `Disable workflow` w GitHub Actions
1. [ ] Usuń secrets wymagane dla tego workflow
1. [ ] Usuń środowisko wymagane dla tego workflow
1. [ ] Zablokuj tworzenie nowych commitów w głównej gałęzi
### Do czego służą `typy aktywności` zdarzenia?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows
1. [x] Ograniczenie uruchamiania workflow do konkretnych typów aktywności za pomocą filtra `types`
1. [ ] Sprawdzanie, czy aktywność pochodzi od użytkownika czy bota
1. [ ] Reagowanie na nową aktywność w repository (np. nowy współpracownik)
### Chcesz utworzyć wielokrotnego użytku workflow `CI`, który uruchamia kontrole jakości, linting oraz testy dla zmian w kodzie. Jakie wyzwalanie zdarzeń powinien zdefiniować workflow `CI`, aby można go było używać w innych workflow?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
1. [x] workflow_call
1. [ ] workflow_trigger
> Nie ma takiego wyzwalania zdarzeń
1. [ ] workflow_dispatch
> Służy do ręcznego uruchamiania
1. [ ] workflow_run
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run
### Podległy workflow o nazwie `build` tworzy artefakty zip. Jak przekazać lokalizację pliku zip do workflow wywołującego, który uruchamia workflow `build`? (Wybierz trzy.)
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow
- [x] Definiujesz output na poziomie workflow w workflow `build`
- [x] Definiujesz output na poziomie zadania (job) w workflow `build`
- [x] W workflow `build` zapisujesz output do `$GITHUB_OUTPUT` w jednym z kroków
- [ ] Wszystkie outputy są automatycznie przekazywane do workflow wywołujących
### Jakie są prawidłowe przypadki użycia **defaults**? (Wybierz dwie.)
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaults
- [x] Użycie defaults.run na poziomie workflow, aby ustawić domyślną powłokę (np. bash) dla całego workflow
- [x] Użycie defaults.run na poziomie job, aby ustawić domyślny katalog roboczy dla wszystkich kroków w jednym job
- [ ] Użycie defaults.run na poziomie step, aby ustawić domyślną powłokę (np. bash) dla tego jednego kroku
> defaults.run można ustawić tylko na poziomie workflow lub job
- [ ] Użycie defaults.env na poziomie workflow, aby ustawić domyślne zmienne środowiskowe dla całego workflow
> Nie istnieje coś takiego jak defaults.env
- [ ] Użycie defaults.env na poziomie job, aby ustawić domyślne zmienne środowiskowe dla wszystkich kroków w jednym job
> Nie istnieje coś takiego jak defaults.env
### Jak możesz zapewnić, że workflow o nazwie `Deploy Prod` zawsze działa najwyżej jeden na raz?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
1. [x] Użyj `concurrency` na poziomie workflow
```yaml
concurrency: ${{ github.workflow }}
```
1. [ ] Użyj `queue` na poziomie workflow
```yaml
queue: ${{ github.workflow }}
```
1. [ ] Użyj `order` na poziomie workflow
```yaml
order: ${{ github.workflow }}
```
1. [ ] Użyj `parallel` na poziomie workflow
```yaml
parallel: ${{ github.workflow }}
```
### Twój workflow analizy Pull Request korzysta z wielu narzędzi do analizy kodu i zajmuje około 20 minut na pełne ukończenie. Jest on uruchamiany na zdarzenie `pull_request` z filtrem `branches` ustawionym na `master`. W związku z tym, jeśli programista wypchnie wiele 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 funkcji concurrency z cancel-in-progress
```yaml
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
```
1. [ ] Użyj funkcji concurrency
```yaml
concurrency:
group: ${{ github.ref }}
```
> To ustawi kolejkę uruchomień dla tego 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ę pomyślnie
1. [ ] Nie można używać `if: ${{ always() }}` i `needs` razem. Workflow zakończy się błędem przy uruchomieniu.
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 wyrażenie warunkowe `jobs.job_id.if` zapewni, że zadanie `production-deploy` zostanie uruchomione tylko w repozytorium `my-org/my-repo`? (Wybierz dwie odpowiedzi.)
```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? `Not all steps run actions, but all actions run as a step`
> 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ć actions (np. wykonując polecenie run)
### Dla każdej akcji opublikowanej w GitHub Marketplace możesz często używać jej w wielu wersjach. Które podejście jest najstabilniejsze i najbezpieczniejsze?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-versioned-actions
1. [x] Odwołanie do commit SHA
1. [ ] Odwołanie do tagu wersji
1. [ ] Odwołanie do głównej gałęzi
### Aby zapobiec niepowodzeniu zadania, gdy jeden z kroków zawiedzie, możesz 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 zawodzącym kroku
```yaml
steps:
- uses: my-org/failing-action@v1
continue-on-error: true
```
1. [ ] flagi `ignore-error` w zawodzącym kroku
```yaml
steps:
- uses: my-org/failing-action@v1
ignore-error: true
```
1. [ ] warunku `failure()` w zawodzącym kroku
```yaml
steps:
- uses: my-org/failing-action@v1
if: failure()
```
1. [ ] warunku `always()` w zawodzącym kroku
```yaml
steps:
- uses: my-org/failing-action@v1
if: always()
```
### Zdefiniowałeś zadanie macierzowe `example_matrix`. Jak można ograniczyć macierz do uruchamiania maksymalnie 2 zadań 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 w celu sprawdzenia, czy liczba zadań jest mniejsza niż 2
1. [ ] To niemożliwe, macierz zawsze uruchomi wszystkie zadania równolegle, jeśli dostępne są runnery
### Która z poniższych odpowiedzi jest poprawnym sposobem ustawienia parametru wyjściowego `PET` z wartością `DOG` w `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óra z tych opcji 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 }}"`
> Tak byłoby, gdyby `action_state` zostało zapisane w `$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 z organizacji `octo-org` oraz 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łoby 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ć `caching`?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching
1. [x] Gdy chcesz ponownie użyć plików, które nie zmieniają się często pomiędzy zadaniami lub uruchomieniami workflow, takich jak zależności budowania z systemu zarządzania pakietami.
1. [ ] Gdy chcesz ponownie użyć plików, które zmieniają się często pomiędzy zadaniami lub uruchomieniami workflow, takich jak zależności budowania z systemu zarządzania pakietami.
1. [ ] Gdy chcesz zapisać pliki wygenerowane przez zadanie, aby móc je zobaczyć po zakończeniu uruchomienia workflow, takie jak zbudowane pliki binarne lub dzienniki budowania.
> Do tego celu należy używać artefaktów https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
1. [ ] Gdy chcesz zapisać pliki binarne wygenerowane przez zadanie budowania, aby użyć ich w kolejnym zadaniu wdrożeniowym do wdrożenia nowej wersji aplikacji.
> Do tego celu należy używać artefaktów https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
### Kiedy powinno się używać `artifacts`? (Wybierz dwie odpowiedzi.)
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#about-workflow-artifacts
- [x] Używaj artifacts, aby zapisać pliki wygenerowane przez zadanie do przeglądania po zakończeniu działania workflow, takie jak wyniki testów lub logi budowy.
- [x] Używaj artifacts, aby zapisać binaria wygenerowane przez zadanie budowy w celu użycia w kolejnym zadaniu wdrażania nowej wersji aplikacji.
- [ ] Używaj artifacts, aby ponownie wykorzystać pliki, które nie zmieniają się często między zadaniami lub uruchomieniami workflow, takie jak zależności budowy z systemu zarządzania pakietami.
> W tym celu należy użyć cache https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching
- [ ] Używaj artifacts, aby tworzyć nowe wersje swojej aplikacji wraz z notatkami o wersji, wzmiankami i/lub współtwórcami.
> To jest zastosowanie dla releases, a nie artifacts.
### Jeśli workflow uruchamia się na gałęzi `feature-a`, czy może przywrócić `caches` utworzone w 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ą przywrócić pamięci podręczne utworzone w domyślnej gałęzi
1. [ ] Tak, wszystkie pamięci podręczne mogą być dostępne dla workflow na dowolnej gałęzi w tym samym repozytorium
1. [ ] Nie, pamięci podręczne mogą być przywracane tylko z tej samej gałęzi
1. [ ] Tak, ale tylko jeśli żadne pliki nie zostały zmienione w gałęzi `feature-a`
### Aby uzyskać dostęp do `artifact`, który został stworzony w innym, wcześniej wywołanym przebiegu workflow, możesz:
> https://github.com/actions/download-artifact?tab=readme-ov-file#download-artifacts-from-other-workflow-runs-or-repositories
1. [ ] Nie możesz uzyskać dostępu do `artifact`, który został stworzony w innym przebiegu workflow
1. [x] Użyj akcji `actions/download-artifact` z podwyższonymi uprawnieniami.
1. [ ] Użyj akcji `actions/upload-artifact`.
1. [ ] Użyj akcji `actions/download-artifact` i upewnij się, że artifact nie wygasł
### Czego należy użyć do przechowywania raportów pokrycia lub zrzutów ekranu generowanych podczas workflow, który wykonuje testy automatyczne dla repository?
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#comparing-artifacts-and-dependency-caching
1. [x] Artifacts
1. [ ] Caches
1. [ ] Packages
> https://docs.github.com/en/packages/learn-github-packages/introduction-to-github-packages
1. [ ] Releases
> https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases
### Możesz przesł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ę), które zostały utworzone 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. [ ] przechowywać pliki binarne w pamięci podręcznej w `build` i odczytywać je z pamięci podręcznej w `deploy`
1. [ ] przechowywać pliki binarne w pamięci podręcznej w `deploy` i odczytywać je z pamięci podręcznej w `build`
### Zadanie o nazwie `job2` używa artefaktów utworzonych w `job1`. Dlatego ważne jest, aby upewnić się, że `job1` zakończy się przed rozpoczęciem poszukiwania artefaktów przez `job2`. Jak należy utworzyć tę zależność?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds
1. [x] utwórz tę zależność, używając słowa kluczowego `needs` w `job2`
1. [ ] ta zależność jest tworzona automatycznie podczas użycia `actions/download-artifact` do pobrania artefaktu z `job1`
1. [ ] utwórz tę zależność, definiując `job2` po `job1` w definicji workflow `.yaml`
1. [ ] utwórz tę zależność, używając słowa kluczowego `concurrency` w `job2`
### Które stwierdzenie dotyczące `Starter Workflows` jest prawdziwe? (Wybierz trzy.)
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
- [x] Umożliwiają użytkownikom korzystanie z gotowych (lub wymagających minimalnych zmian) szablonów workflow
- [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 Twojej organizacji
- [ ] Starter workflows nie mogą wywoływać reusable workflows
- [ ] Starter workflows są płatną funkcją GitHub
- [ ] Starter workflows są dostarczane jako gotowe do użycia 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 zakresu: (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ła organizacja lub wybrane repository w organizacji
- [x] Pojedyncze repository
- [x] Środowisko w repository
- [ ] Środowisko współdzielone pomiędzy wieloma repository
> Środowiska nie mogą być współdzielone pomiędzy repository
- [ ] Wiele repository, które nie są częścią tej samej organizacji/Enterprise
- [ ] Konkretnego workflow w repository
> Zmienne środowiskowe mogą być przypisane do workflow, zmienne konfiguracyjne nie
- [ ] Konkretnego zadania w workflow
> Zmienne środowiskowe mogą być przypisane do workflow, zmienne konfiguracyjne nie
### Jakie są trzy rodzaje Actions?
> 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? `Docker container actions są zazwyczaj wolniejsze niż JavaScript actions`
> Docker container actions są wolniejsze niż JavaScript actions
1. [x] Prawda
1. [ ] Fałsz
> Ze względu na opóźnienia związane z budowaniem i pobieraniem kontenera, Docker container actions są wolniejsze niż JavaScript actions.
### Podczas tworzenia niestandardowej 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 musi być zdefiniowane całe `metadata` akcji?
Przykłady metadata: nazwa, opis, wyjścia lub wymagane dane wejściowe
> 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. [ ] Edytowane w interfejsie użytkownika GitHub Marketplace po opublikowaniu do udostępnienia
1. [ ] W pliku `action.yml` lub `action.yaml` w repozytorium akcji, ale nie jest to wymagane, jeśli akcja nie jest przeznaczona do udostępnienia publicznego
> Wszystkie akcje wymagają pliku metadata.
### Przepływ pracy został początkowo uruchomiony na `commit A` i zakończył się niepowodzeniem. Naprawiłeś przepływ pracy w kolejnej `commit B`. Kiedy ponownie uruchomisz ten przepływ pracy, zostanie on uruchomiony z kodem z którego commitu?
> https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs#about-re-running-workflows-and-jobs
1. [x] Zostanie uruchomiony z kodem z `commit A`
1. [ ] Zostanie uruchomiony z kodem z `commit B`
> Ponowne uruchomienie przepływu pracy używa tego samego identyfikatora commit SHA i odwołania Git, które wyzwoliły oryginalny przebieg przepływu pracy.
1. [ ] Nie można ponownie uruchomić przepływów pracy w GitHub Actions. Musisz uruchomić nowy przepływ pracy, który zostanie uruchomiony z najnowszymi zmianami
1. [ ] Wyzwoli dwa przepływy pracy, jeden z kodem z `commit A`, a drugi z kodem z `commit B`
### Jak można wymagać ręcznej akceptacji przez maintainera, jeśli uruchomienie workflow jest skierowane do środowiska `production`?
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment
1. [x] Korzystając z zasad ochrony wdrożeń (deployment protection rules)
1. [ ] Ustawiając wymaganych recenzentów w workflow `production`
1. [ ] Korzystając z zasad ochrony gałęzi (branch protection rules)
1. [ ] Ręczne akceptacje nie są obsługiwane przez GitHub Actions
### Co jest prawdą na temat środowisk?
> Każde zadanie w workflow może odnosić się do pojedynczego środowiska.
1. [x] Każde zadanie w workflow może odnosić się do pojedynczego środowiska.
1. [ ] Każdy workflow może odnosić się do pojedynczego środowiska.
1. [ ] Każde zadanie w workflow może odnosić się maksymalnie do dwóch środowisk.
1. [ ] Każdy workflow może odnosić się maksymalnie do dwóch środowisk.
### Korzystając z GitHub Actions do uzyskiwania dostępu do zasobów w jednym z dostawców chmury (takich jak AWS, Azure lub 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`
> Wykorzystywanie długoterminowych kluczy dostępu nie jest zalecane w przypadku ewentualnych wycieków bezpieczeństwa lub ataków, takich jak [script injection](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`
> Żadne wartości wrażliwe nie powinny być przechowywane w `variables`
### Twój publicznie dostępny repozytorium open-source zawiera workflow z wyzwalaczem zdarzenia `pull_request`. Jak możesz wymagać zatwierdzeń dla uruchomień workflow wyzwalanych 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 zasady ochrony wdrożeń dla repozytorium
> Zasady ochrony wdrożeń są używane do ochrony środowisk
1. [ ] Skonfiguruj zasady ochrony gałęzi dla repozytorium
1. [ ] Workflow nie zostanie wyzwolony dla forków, jeśli używasz 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 to domyślne zmienne środowiskowe 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 tajny `SomeSecret`, jednak gdy odwołujesz się do tego sekretu w workflow za pomocą `${{ secrets.SomeSecret }}`, zwraca on inną wartość niż oczekiwana. Jaki może być tego powód?
> 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 enterprise
> 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 w zakresie organizacji
### Który sposób wypisania komunikatu debugowania jest poprawny?
> 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ślny dostęp do wszystkich GitHub.com Actions
> GitHub Actions na GitHub Enterprise Server zostały zaprojektowane do pracy w środowiskach bez pełnego dostępu do internetu. Domyślnie Workflows nie mogą używać actions z GitHub.com ani 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ć GitHub.com Actions ze względu na swoją lokalną naturę i brak dostępu do internetu
### Gdzie można znaleźć dzienniki łączności sieciowej dla GitHub self-hosted-runner?
> 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, na której działa runner
1. [ ] Na GitHub.com na stronie tego konkretnego runnera
1. [ ] W dziennikach uruchomienia zadania (job run logs) dla zadania, które uruchomiono na tym runnerze
1. [ ] W dziennikach uruchomienia zadania (job run logs) dla zadania, które uruchomiono na tym runnerze z włączonym logowaniem debugowania
### Jak można zweryfikować, czy Twój GitHub self-hosted-runner 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] Używając skryptu dostarczonego przez GitHub na maszynie runnera
1. [ ] Próbując uzyskać dostęp do maszyny runnera za pomocą `ssh`, aby zweryfikować łączność sieciową
1. [ ] Używając predefiniowanego GitHub Actions workflow `network-connectivity.yml`
1. [ ] GitHub automatycznie zweryfikuje łączność sieciową podczas instalacji aplikacji runnera na maszynie runnera
### Jaki jest poprawny sposób na uruchomienie 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] Tworząc następujący warunek na poziomie zadania
```yaml
my-job:
if: ${{ vars.MY_VAR == 'MY_VALUE' }}
```
1. [ ] Tworząc następujący warunek na poziomie zadania
```yaml
my-job:
if: ${{ vars.MY_VAR }} == 'MY_VALUE'
```
> To zawsze będzie oceniane jako True
1. [ ] To nie jest możliwe, ponieważ zmienne konfiguracyjne nie mogą być używane w warunkach `if`
> To jest prawdą 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 jest prawdą 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 odwołać 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 używane 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 używane 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 używane w warunkach `if:`
### Jak możesz użyć GitHub API do pobrania logów 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 możesz użyć GitHub API, aby utworzyć lub zaktualizować secret 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ć tajny klucz na poziomie organizacji GitHub `API_KEY` inną wartością podczas pracy w ramach repozytorium? (Wybierz dwie odpowiedzi.)
> 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 mogą być ponownie użyte w ramach GitHub Organization? (Wybierz cztery.)
- [x] Secrets
- [x] Configuration Variables
- [x] Self Hosted Runners
- [x] Workflow Templates
- [ ] Artifacts
> Artifacts są używane do przechowywania danych po zakończeniu zadania i/lub dzielenia się tymi danymi z innym zadaniem w ramach tego samego workflow.
- [ ] Cache
> Cache może być używana ponownie w różnych workflows w ramach tego samego repository.
- [ ] Environment Variables
> Zmienne środowiskowe mogą być powiązane z krokiem, zadaniem lub workflow. Nie mogą być współdzielone między workflows/repositories lub organizations.
### Ile zadań zostanie wykonanych w poniższym workflow?
```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 działa 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, wszystkie uruchamiane na hostowanych przez GitHub runnerach, czy prawdą jest, że 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ślonej przez runs-on
### Jaka jest maksymalna liczba wielokrotnie używalnych workflowów, które można wywołać z pojedynczego 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 od użytkowników organizacji
### Które z poniższych stwierdzeń jest poprawne na temat GitHub Workflows i Actions?
> 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, 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ń, które składają się z jednego lub więcej kroków, 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 jest workflow
### Na którym commit i gałęzi uruchamiane są zaplanowane workflows w GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
1. [ ] Zaplanowane workflows uruchamiane są na określonym commicie w ostatnio zmodyfikowanej gałęzi.
> niepoprawne, zarówno określony commit, jak i ostatnio zmodyfikowana gałąź
1. [ ] Zaplanowane workflows uruchamiane są na określonym commicie w gałęzi main.
> niepoprawne, zarówno określony commit, jak i gałąź main
1. [x] Zaplanowane workflows uruchamiane są na najnowszym commicie w domyślnej gałęzi repozytorium.
1. [ ] Zaplanowane workflows uruchamiane są na najnowszym commicie w gałęzi main.
> najnowszy commit jest poprawny, ale gałąź main nie
### Jaka jest poprawna składnia ustawiania katalogu dla wszystkich poleceń `run` w workflow?
> 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 użyć zdefiniowanego workflow w wielu repozytoriach? (Wybierz dwie.)
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
- [ ] Poprzez skopiowanie pliku workflow do każdego repozytorium
- [x] Używając szablonów workflow
- [ ] Tworząc akcję wielokrotnego użytku
- [x] Definiując workflow w centralnym repozytorium
### Jak możesz upewnić się, ż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 filtru branches
1. [ ] Używając filtru runs-on
1. [ ] Używając filtru jobs
1. [ ] Używając słowa kluczowego branch
### Czym zajmuje się słowo kluczowe `needs` w przepływie pracy GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds
1. [x] Określa zależności zadania
1. [ ] Definiuje zmienne środowiskowe
1. [ ] Konfiguruje środowisko
1. [ ] Uruchamia zadanie na podstawie zdarzenia
### Które słowo kluczowe pozwala zdefiniować zmienne środowiskowe w workflow 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 użycia słowa kluczowego `with` w workflow 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 uruchomienia innego workflow
### Która ze 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 znaków z |
1. [ ] Rozdzielanie poleceń średnikiem ;
### Jak można buforować zależności, aby przyspieszyć wykonywanie workflow?
> 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 repository
1. [ ] Używając słowa kluczowego store
### Do czego służy 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] Umożliwia definiowanie wielu konfiguracji zadań do uruchamiania równolegle
1. [ ] Ustawia zmienne środowiskowe dla zadania
1. [ ] Wyzwala przepływy pracy na podstawie harmonogramu
1. [ ] Definiuje sekrety dla przepływu pracy
### Który z poniższych elementów można użyć do ograniczenia liczby jednocześnie uruchamianych zadań w ramach GitHub Actions workflow?
> 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
### W jaki sposób 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. [ ] Za pomocą słowa kluczowego os
1. [x] Za pomocą słowa kluczowego runs-on
1. [ ] Za pomocą słowa kluczowego platform
1. [ ] Za pomocą słowa kluczowego env
### W workflow 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 Windows runners?
> 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 własnego hostowanego 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ć własnego hostowanego runnera do repozytorium
- [x] Możesz dodać własnego hostowanego runnera do organizacji
- [x] Możesz dodać własnego hostowanego runnera do enterprise
- [ ] Nie możesz dodać własnego hostowanego runnera na poziomie workflow
> Nie można dodać na poziomie workflow
- [ ] Nie możesz dodać własnego hostowanego runnera na poziomie kroku
> Nie można dodać na poziomie kroku
### Wybierz domyślną zmienną środowiskową, która zawiera system operacyjny wykonywanego zadania przez runnera
> 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`
### W jaki sposób `actions/cache` w GitHub Actions obsługuje brak pamięci podręcznej (cache miss)?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#managing-caches
1. [ ] wymagając ręcznej interwencji w celu utworzenia nowej pamięci podręcznej
1. [ ] wyszukując pamięć podręczną w innych repozytoriach
1. [x] automatycznie tworząc nową pamięć podręczną, jeśli zadanie zostanie pomyślnie ukończone
1. [ ] przerywając workflow w przypadku braku pamięci podręcznej (cache miss)
### Jak można określić harmonogram działania workflow GitHub Actions, aby uruchamiał się tylko w dni powszednie?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
1. [ ] dodać warunek w pliku YAML workflow dla dni powszednich
1. [ ] nie jest to możliwe w GitHub Actions
1. [ ] użyć wyzwalacza zdarzeń on: schedule: weekdays
1. [x] użyć wyzwalacza zdarzeń on: schedule: cron
### 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] zaszyfruj i przechowuj sekrety w repozytorium, ale frazę deszyfrującą zachowaj 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ć, że krok `Upload Failure test report` jest 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 uruchomiło działanie 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 zarówno filtr branches, jak i paths, jaki będzie efekt uruchomienia workflow?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore
1. [x] workflow zostanie uruchomiony tylko wtedy, gdy oba warunki `branches` i `paths` zostaną spełnione
1. [ ] workflow zostanie uruchomiony, gdy spełniony zostanie którykolwiek z warunków `branches` lub `paths`, ale zastosowany zostanie tylko pasujący filtr
1. [ ] workflow zostanie uruchomiony, gdy spełniony zostanie którykolwiek z warunków `branches` lub `paths`
1. [ ] workflow nie zostanie uruchomiony, gdy oba warunki `branches` i `paths` zostaną spełnione
### Jakie jest zalecane podejście do 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 rozróżniające wielkość liter
1. [ ] używać wyłącznie wielkich liter w nazwach zmiennych środowiskowych
1. [ ] ignorować rozróżnianie wielkości liter, ponieważ GitHub Actions obsługuje to automatycznie
1. [ ] polegać na zachowaniu używanego systemu operacyjnego
### Które z poniższych stwierdzeń dokładnie opisuje zachowanie zadań workflow 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 workflow nie rozpoczną się, dopóki wszystkie reguły ochrony środowiska nie zostaną spełnione
1. [ ] zadania workflow nigdy się nie rozpoczną, jeśli środowisko ma reguły ochrony
1. [ ] zadania workflow rozpoczną się natychmiast, niezależnie od reguł ochrony środowiska
1. [ ] zadania workflow 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 pamięci podręcznej
1. [ ] wskazać, czy wystąpiło trafienie w pamięci podręcznej
1. [ ] określić lokalizację plików w pamięci podręcznej
1. [ ] włączyć funkcję pamięci podręcznej między systemami operacyjnymi
### Którą zmienną należy 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 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]
```
### Jakie jest przeznaczenie 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 przedział czasowy dla pojedynczych poleceń w ramach kroku
1. [ ] ustawia limit czasu oczekiwania na zdarzenia zewnętrzne przed przejściem do następnego kroku
1. [ ] określa maksymalny czas trwania pracy (job)
### Dave tworzy szablonowy workflow dla swojej organizacji. Gdzie Dave musi przechowywać pliki workflow i powiązane pliki metadata dla szablonowego workflow?
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
1. [x] wewnątrz katalogu o nazwie `workflow-templates` w repozytorium o nazwie `.github`
1. [ ] wewnątrz katalogu o nazwie `workflow-templates` w bieżącym repozytorium
1. [ ] wewnątrz katalogu o nazwie `.github/org-templates`
1. [ ] wewnątrz katalogu o nazwie `.github/workflow-templates`
### Dave chce otrzymywać powiadomienia, gdy w komentarzu do issue w GitHub repository zostanie dodany nowy komentarz. Którego wyzwalacza zdarzeń powinien użyć w konfiguracji workflow?
> 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 usunięcie plików dziennika z przebiegów workflow w repozytorium GitHub?
> 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 workflow, 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` uruchomi się, jeśli `node-version` wynosi `14`
### Jak możesz uzyskać dostęp do bieżących 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 workflowów
> 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 workflow? (wybierz dwie odpowiedzi)
> https://docs.github.com/en/actions/managing-workflow-runs/deleting-a-workflow-run
- [x] Gdy uruchomienie workflow zostało zakończone
- [x] Gdy uruchomienie workflow ma dwa tygodnie
- [ ] Gdy uruchomienie workflow ma 10 dni
- [ ] Gdy uruchomienie workflow jest w toku
### Kto może ominąć skonfigurowane zasady ochrony wdrożenia, 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 do zapisu w repozytorium
1. [ ] Każdy z uprawnieniami do odczytu w repozytorium
### Jak można pominąć uruchomienie poniższego workflow 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 dodanie dowolnego z poniższych słów kluczowych w wiadomości commitu lub w tytule pull-requesta
```yaml
[skip ci]
[ci skip]
[no ci]
[skip actions]
[actions skip]
```
1. [ ] Podając `SKIP_WORKFLOW` w wiadomości commitu
1. [ ] Powyższy workflow uruchomi się za każdym razem w przypadku zdarzenia push lub pull request bez wyjątków
### 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 sprzątającego w akcji kontenerowej?
> 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/reference/workflows-and-actions/variables
- [x] Domyślne zmienne środowiskowe są ustawiane przez GitHub, a nie definiowane w workflow
- [x] Większość domyślnych zmiennych środowiskowych ma odpowiadającą im właściwość kontekstu
- [x] Obecnie wartość domyślnej zmiennej środowiskowej CI można nadpisać, 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 można uzyskać za pomocą kontekstu env
### Jakie zakresy są zdefiniowane dla zmiennych niestandardowych w workflow? (wybierz trzy)
> https://docs.github.com/en/actions/learn-github-actions/variables#defining-environment-variables-for-a-single-workflow
- [x] Cały workflow, używając `env` na najwyższym poziomie pliku workflow
- [x] Zawartość zadania w workflow, używając `jobs.<job_id>.env`
- [x] Konkretnego kroku w zadaniu, używając `jobs.<job_id>.steps[*].env`
- [ ] Wszystkich zadań w workflow, używając `jobs.env`
- [ ] Cały workflow, używając `custom.env` na najwyższym poziomie pliku workflow
- [ ] Konkretnego środowiska w repozytorium, używając `environment.<environment_id>.env` na najwyższym poziomie pliku workflow
### 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 bieżący 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 dane wejściowe `MY_ACCESS_TOKEN`
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: ${{ MY_ACCESS_TOKEN }}
```
1. [ ] Zmienną środowiskową `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ępu zostaną przekazane automatycznie
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
```
### Biorąc pod uwagę następującą konfigurację, ile zadań uruchomi GitHub Actions, gdy ten matryca 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 zadanie nie zostanie 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 workflow
- [x] Poziom job
- [x] Poziom step
- [ ] Poziom action
### 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 workflow?
> 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}}`
### Która składnia polecenia workflow poprawnie ustawia zmienną środowiskową o nazwie 'API_VERSION' z wartością '2.1' dla kolejnych kroków w zadaniu GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable
1. [x] `echo "API_VERSION=2.1" >> "$GITHUB_ENV"`
1. [ ] `echo "API_VERSION=2.1" >> "$GITHUB_OUTPUT"`
1. [ ] `export API_VERSION=2.1 >> "$GITHUB_ENV"`
1. [ ] `set-env name=API_VERSION value=2.1`
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)