Amazon CodeCatalyst tidak lagi terbuka untuk pelanggan baru. Pelanggan yang sudah ada dapat terus menggunakan layanan ini seperti biasa. Lihat informasi yang lebih lengkap di [Cara bermigrasi dari CodeCatalyst](migration.md).
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Menjalankan alur kerja
*Operasi* adalah satu iterasi dari sebuah alur kerja. Selama menjalankan, CodeCatalyst melakukan tindakan yang ditentukan dalam file konfigurasi alur kerja dan mengeluarkan log, artefak, dan variabel terkait.
Anda dapat memulai proses secara manual, atau Anda dapat memulainya secara otomatis, melalui *pemicu alur kerja*. Contoh pemicu alur kerja mungkin adalah pengembang perangkat lunak yang mendorong komit ke cabang utama Anda.
Anda juga dapat menghentikan alur kerja secara manual di tengah pemrosesannya jika Anda memulainya secara tidak sengaja.
Jika beberapa alur kerja berjalan dimulai sekitar waktu yang sama, Anda dapat mengonfigurasi bagaimana Anda ingin proses ini diantrian. Anda dapat menggunakan perilaku antrian default, di mana proses diantrian satu demi satu dalam urutan di mana mereka dimulai, atau Anda dapat memiliki run yang lebih baru menggantikan (atau 'mengambil alih') dari yang sebelumnya untuk mempercepat proses Anda. Menyiapkan alur kerja Anda agar terjadi secara paralel, sehingga tidak ada proses menunggu yang lain, juga dimungkinkan.
Setelah memulai alur kerja, baik secara manual maupun otomatis, Anda dapat melihat status proses dan detail lainnya. Misalnya, Anda dapat melihat kapan dimulai, siapa yang dimulai, dan apakah masih berjalan.
**Topics**
+ [Memulai proses alur kerja secara manual](workflows-manually-start.md)
+ [Memulai alur kerja berjalan secara otomatis menggunakan pemicu](workflows-add-trigger.md)
+ [Mengkonfigurasi pemicu manual saja](workflows-manual-only.md)
+ [Menghentikan alur kerja](workflows-stop.md)
+ [Gating alur kerja berjalan](workflows-gates.md)
+ [Memerlukan persetujuan pada alur kerja berjalan](workflows-approval.md)
+ [Mengonfigurasi perilaku antrian run](workflows-configure-runs.md)
+ [Caching file antara alur kerja berjalan](workflows-caching.md)
+ [Melihat status dan detail alur kerja](workflows-view-run.md)
# Memulai proses alur kerja secara manual
Di Amazon CodeCatalyst, Anda dapat memulai alur kerja yang dijalankan secara manual dari CodeCatalyst konsol.
Untuk informasi selengkapnya tentang alur kerja berjalan, lihat[Menjalankan alur kerja](workflows-working-runs.md).
**catatan**
Anda juga dapat memulai alur kerja yang dijalankan secara otomatis dengan [mengonfigurasi pemicu](workflows-add-trigger.md).
**Untuk memulai alur kerja, jalankan secara manual**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Jalankan**.
# Memulai alur kerja berjalan secara otomatis menggunakan pemicu
Anda dapat memulai CodeCatalyst alur kerja Amazon yang dijalankan secara otomatis dengan pemicu alur kerja.
*Pemicu alur kerja*, atau hanya *pemicu*, memungkinkan Anda memulai alur kerja yang berjalan secara otomatis ketika peristiwa tertentu terjadi, seperti push kode. Anda mungkin ingin mengonfigurasi pemicu untuk membebaskan pengembang perangkat lunak Anda dari keharusan memulai alur kerja yang berjalan secara manual melalui konsol. CodeCatalyst
Anda dapat menggunakan tiga jenis pemicu:
+ **Push** - Pemicu push kode menyebabkan alur kerja dijalankan setiap kali komit didorong.
+ **Permintaan tarik** - Pemicu permintaan tarik menyebabkan alur kerja dijalankan setiap kali permintaan tarik dibuat, direvisi, atau ditutup.
+ **Jadwal** - Pemicu jadwal menyebabkan alur kerja berjalan dimulai pada jadwal yang Anda tentukan. Pertimbangkan untuk menggunakan pemicu jadwal untuk menjalankan build malam perangkat lunak Anda sehingga build terbaru siap untuk pengembang perangkat lunak Anda untuk bekerja keesokan paginya.
Anda dapat menggunakan push, pull request, dan schedule trigger sendiri atau dalam kombinasi dalam alur kerja yang sama.
Pemicu bersifat opsional—jika Anda tidak mengonfigurasinya, Anda hanya dapat memulai alur kerja secara manual.
**Tip**
Untuk melihat pemicu beraksi, luncurkan proyek dengan cetak biru. Sebagian besar cetak biru berisi alur kerja dengan pemicu. Cari `Trigger` properti di file definisi alur kerja cetak biru. Untuk informasi selengkapnya tentang cetak biru, lihat [Membuat proyek dengan cetak biru](projects-create.md#projects-create-console-template).
**Topics**
+ [Contoh: Pemicu dalam alur kerja](workflows-add-trigger-examples.md)
+ [Pedoman penggunaan untuk pemicu dan cabang](workflows-add-trigger-considerations.md)
+ [Menambahkan pemicu ke alur kerja](workflows-add-trigger-add.md)
# Contoh: Pemicu dalam alur kerja
Contoh berikut menunjukkan cara menambahkan berbagai jenis pemicu dalam file definisi CodeCatalyst alur kerja Amazon.
Untuk informasi lebih lanjut tentang menggunakan pemicu, lihat [Memulai alur kerja berjalan secara otomatis menggunakan pemicu](workflows-add-trigger.md).
**Topics**
+ [Contoh: Pemicu push kode sederhana](#workflows-add-trigger-examples-push-simple)
+ [Contoh: Pemicu 'push to main' sederhana](#workflows-add-trigger-examples-push-main)
+ [Contoh: Pemicu permintaan tarik sederhana](#workflows-add-trigger-examples-pull-simple)
+ [Contoh: Pemicu jadwal sederhana](#workflows-add-trigger-examples-schedule-simple)
+ [Contoh: Pemicu dengan jadwal dan cabang](#workflows-add-trigger-examples-schedule-branches)
+ [Contoh: Pemicu dengan jadwal, dorongan, dan cabang](#workflows-add-trigger-examples-schedule-push-branches)
+ [Contoh: Pemicu dengan tarikan dan cabang](#workflows-add-trigger-examples-pull-branches)
+ [Contoh: Pemicu dengan tarikan, cabang, dan acara 'CLOSED'](#workflows-add-trigger-examples-push-pull-close)
+ [Contoh: Pemicu dengan dorongan, cabang, dan file](#workflows-add-trigger-examples-push-multi)
+ [Contoh: Pemicu manual](#workflows-add-trigger-examples-manual)
+ [Contoh: Pemicu dalam pengaturan CI/CD multi-alur kerja](#workflows-add-trigger-usecases)
## Contoh: Pemicu push kode sederhana
Contoh berikut menunjukkan pemicu yang memulai alur kerja yang dijalankan setiap kali kode didorong ke cabang *mana pun* di repositori sumber Anda.
*Ketika pemicu ini diaktifkan, CodeCatalyst mulai menjalankan alur kerja menggunakan file di cabang yang Anda dorong (yaitu, cabang tujuan).*
Misalnya, jika Anda mendorong komit ke`main`, CodeCatalyst mulai menjalankan alur kerja menggunakan file definisi workfow dan file sumber lainnya. `main`
Sebagai contoh lain, jika Anda mendorong komit ke`feature-branch-123`, CodeCatalyst mulai menjalankan alur kerja menggunakan file definisi workfow dan file sumber lainnya. `feature-branch-123`
```
Triggers:
- Type: PUSH
```
**catatan**
Jika Anda ingin alur kerja dijalankan hanya ketika Anda mendorong ke`main`, lihat[Contoh: Pemicu 'push to main' sederhana](#workflows-add-trigger-examples-push-main).
## Contoh: Pemicu 'push to main' sederhana
Contoh berikut menunjukkan pemicu yang memulai alur kerja yang dijalankan setiap kali kode didorong ke `main` cabang—dan *hanya* cabang—di repositori sumber Anda. `main`
```
Triggers:
- Type: PUSH
Branches:
- main
```
## Contoh: Pemicu permintaan tarik sederhana
Contoh berikut menunjukkan pemicu yang memulai alur kerja yang dijalankan setiap kali permintaan tarik dibuat atau direvisi di repositori sumber Anda.
*Ketika pemicu ini diaktifkan, CodeCatalyst mulai menjalankan alur kerja menggunakan file definisi alur kerja dan file sumber lain di cabang yang Anda tarik (yaitu, cabang sumber).*
Misalnya, jika Anda membuat permintaan tarik dengan cabang sumber yang dipanggil `feature-123` dan cabang tujuan dipanggil`main`, CodeCatalyst mulai menjalankan alur kerja menggunakan file definisi workfow dan file sumber lainnya. `feature-123`
```
Triggers:
- Type: PULLREQUEST
Events:
- OPEN
- REVISION
```
## Contoh: Pemicu jadwal sederhana
Contoh berikut menunjukkan pemicu yang memulai alur kerja berjalan pada tengah malam (UTC\$10) setiap Senin sampai Jumat.
Ketika pemicu ini diaktifkan, CodeCatalyst mulai menjalankan alur kerja tunggal untuk setiap cabang di repositori sumber Anda yang berisi file definisi alur kerja dengan pemicu ini.
Misalnya, jika Anda memiliki tiga cabang di repositori sumber Anda,,`main`, `release-v1``feature-123`, dan masing-masing cabang ini berisi file definisi alur kerja dengan pemicu berikut, CodeCatalyst mulai tiga alur kerja berjalan: satu menggunakan file di, yang lain menggunakan file di `main``release-v1`, dan yang lain menggunakan file di. `feature-123`
```
Triggers:
- Type: SCHEDULE
Expression: "0 0 ? * MON-FRI *"
```
Untuk lebih banyak contoh ekspresi cron yang dapat Anda gunakan di `Expression` properti, lihat[Expression](workflow-reference.md#workflow.triggers.expression).
## Contoh: Pemicu dengan jadwal dan cabang
Contoh berikut menunjukkan pemicu yang memulai alur kerja berjalan pada pukul 18:15 (UTC\$10) setiap hari.
Ketika pemicu ini diaktifkan, CodeCatalyst mulai menjalankan alur kerja menggunakan file di `main` cabang, dan memulai proses tambahan untuk setiap cabang yang dimulai dengan`release-`.
Misalnya, jika Anda memiliki cabang bernama`main`,, `release-v1``bugfix-1`, dan `bugfix-2` di repositori sumber Anda, CodeCatalyst mulai dua alur kerja berjalan: satu menggunakan file di`main`, dan yang lain menggunakan file di. `release-v1` Itu *tidak* memulai alur kerja berjalan untuk `bugfix-1` cabang `bugfix-1` dan.
```
Triggers:
- Type: SCHEDULE
Expression: "15 18 * * ? *"
Branches:
- main
- release\-.*
```
Untuk lebih banyak contoh ekspresi cron yang dapat Anda gunakan di `Expression` properti, lihat[Expression](workflow-reference.md#workflow.triggers.expression).
## Contoh: Pemicu dengan jadwal, dorongan, dan cabang
Contoh berikut menunjukkan pemicu yang memulai alur kerja berjalan pada tengah malam (UTC\$10) setiap hari, dan setiap kali kode didorong ke cabang. `main`
Dalam contoh ini:
+ Alur kerja dimulai pada tengah malam setiap hari. Proses alur kerja menggunakan file definisi alur kerja dan file sumber lainnya di cabang. `main`
+ Jalankan alur kerja juga dimulai setiap kali Anda mendorong komit ke `main` cabang. Proses alur kerja menggunakan file definisi alur kerja dan file sumber lainnya di cabang tujuan ()`main`.
```
Triggers:
- Type: SCHEDULE
Expression: "0 0 * * ? *"
Branches:
- main
- Type: PUSH
Branches:
- main
```
Untuk lebih banyak contoh ekspresi cron yang dapat Anda gunakan di `Expression` properti, lihat[Expression](workflow-reference.md#workflow.triggers.expression).
## Contoh: Pemicu dengan tarikan dan cabang
Contoh berikut menunjukkan pemicu yang memulai alur kerja yang dijalankan setiap kali seseorang membuka atau memodifikasi permintaan tarik dengan cabang tujuan yang dipanggil. `main` *Meskipun cabang yang ditentukan dalam `Triggers` konfigurasi adalah`main`, alur kerja yang dijalankan akan menggunakan file definisi alur kerja dan file sumber lainnya di cabang *sumber* (yang merupakan cabang yang Anda tarik).*
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
## Contoh: Pemicu dengan tarikan, cabang, dan acara 'CLOSED'
Contoh berikut menunjukkan pemicu yang memulai alur kerja yang dijalankan setiap kali permintaan tarik ditutup pada cabang yang dimulai dengan`main`.
Dalam contoh ini:
+ Saat Anda menutup permintaan tarik dengan cabang tujuan yang dimulai`main`, alur kerja dimulai secara otomatis menggunakan file definisi alur kerja dan file sumber lainnya di cabang sumber (sekarang ditutup).
+ Jika Anda telah mengonfigurasi repositori sumber Anda untuk menghapus cabang secara otomatis setelah permintaan tarik digabungkan, cabang ini tidak akan pernah memiliki kesempatan untuk memasuki status. `CLOSED` Ini berarti bahwa cabang yang digabungkan tidak akan mengaktifkan `CLOSED` pemicu permintaan tarik. Satu-satunya cara untuk mengaktifkan `CLOSED` pemicu dalam skenario ini adalah dengan menutup permintaan tarik tanpa menggabungkannya.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main.*
Events:
- CLOSED
```
## Contoh: Pemicu dengan dorongan, cabang, dan file
Contoh berikut menunjukkan pemicu yang memulai alur kerja yang dijalankan setiap kali perubahan dilakukan pada `filename.txt` file, atau file apa pun di `src` direktori, di `main` cabang.
Ketika pemicu ini diaktifkan, CodeCatalyst mulai menjalankan alur kerja menggunakan file definisi alur kerja dan file sumber lainnya di `main` cabang.
```
Triggers:
- Type: PUSH
Branches:
- main
FilesChanged:
- filename.txt
- src\/.*
```
## Contoh: Pemicu manual
Untuk mengonfigurasi pemicu manual, hilangkan `Triggers` bagian dari file definisi alur kerja. Tanpa bagian ini, pengguna dipaksa untuk memulai alur kerja secara manual dengan memilih tombol **Run** di CodeCatalyst konsol. Untuk informasi selengkapnya, lihat [Memulai proses alur kerja secara manual](workflows-manually-start.md).
## Contoh: Pemicu dalam pengaturan CI/CD multi-alur kerja
Contoh ini menjelaskan cara mengatur pemicu saat Anda ingin menggunakan CodeCatalyst alur kerja Amazon terpisah untuk integrasi berkelanjutan (CI) dan penerapan berkelanjutan (CD).
Dalam skenario ini, Anda menyiapkan dua alur kerja:
+ **alur kerja CI — alur** kerja ini membangun dan menguji aplikasi Anda saat permintaan tarik dibuat atau direvisi.
+ **alur kerja CD — alur** kerja ini membangun dan menyebarkan aplikasi Anda saat permintaan tarik digabungkan.
File definisi **alur kerja CI** akan terlihat mirip dengan ini:
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
Actions:
BuildAction:
instructions-for-building-the-app
TestAction:
instructions-for-test-the-app
```
`Triggers`Kode menunjukkan untuk memulai alur kerja yang dijalankan secara otomatis setiap kali pengembang perangkat lunak membuat permintaan tarik (atau [memodifikasinya) yang](pull-requests-update.md) meminta untuk menggabungkan cabang fitur mereka ke cabang. `main` CodeCatalyst memulai alur kerja berjalan menggunakan kode sumber di cabang sumber (yang merupakan cabang fitur).
File definisi **alur kerja CD** akan terlihat mirip dengan ini:
```
Triggers:
- Type: PUSH
Branches:
- main
Actions:
BuildAction:
instructions-for-building-the-app
DeployAction:
instructions-for-deploying-the-app
```
`Triggers`Kode menunjukkan untuk memulai alur kerja secara otomatis ketika penggabungan terjadi. `main` CodeCatalyst memulai alur kerja berjalan menggunakan kode sumber di `main` cabang.
# Pedoman penggunaan untuk pemicu dan cabang
Bagian ini menjelaskan beberapa pedoman utama saat menyiapkan CodeCatalyst pemicu Amazon yang menyertakan cabang.
Untuk informasi lebih lanjut tentang menggunakan pemicu, lihat [Memulai alur kerja berjalan secara otomatis menggunakan pemicu](workflows-add-trigger.md).
+ **Pedoman 1:** Untuk pemicu permintaan push dan pull, jika Anda akan menentukan cabang, Anda harus menentukan cabang tujuan (atau 'to') dalam konfigurasi pemicu. Jangan pernah menentukan sumber (atau 'dari') cabang.
Dalam contoh berikut, push dari cabang manapun untuk `main` mengaktifkan alur kerja.
```
Triggers:
- Type: PUSH
Branches:
- main
```
Dalam contoh berikut, permintaan tarik dari cabang mana pun ke `main` mengaktifkan alur kerja.
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
+ **Pedoman 2:** *Untuk pemicu push, setelah alur kerja diaktifkan, alur kerja akan berjalan menggunakan file definisi alur kerja dan file sumber di cabang tujuan.*
+ **Pedoman 3:** *Untuk pemicu permintaan tarik, setelah alur kerja diaktifkan, alur kerja akan berjalan menggunakan file definisi alur kerja dan file sumber di cabang sumber (meskipun Anda menentukan cabang tujuan dalam konfigurasi pemicu).*
+ **Pedoman 4:** Pemicu yang sama persis di satu cabang mungkin tidak berjalan di cabang lain.
Pertimbangkan pemicu dorong berikut:
```
Triggers:
- Type: PUSH
Branches:
- main
```
Jika file definisi alur kerja yang berisi pemicu ini ada `main` dan dikloning`test`, alur kerja tidak akan pernah mulai secara otomatis menggunakan file di `test` (meskipun Anda dapat memulai alur kerja *secara manual* agar file tersebut digunakan). `test` Tinjau **Pedoman 2** untuk memahami mengapa alur kerja tidak akan pernah berjalan secara otomatis menggunakan file di. `test`
Pertimbangkan juga pemicu permintaan tarik berikut:
```
Triggers:
- Type: PULLREQUEST
Branches:
- main
Events:
- OPEN
- REVISION
```
Jika file definisi alur kerja yang berisi pemicu ini ada di`main`, alur kerja tidak akan pernah berjalan menggunakan file di. `main` (Namun, jika Anda membuat `test` cabang dari`main`, alur kerja akan berjalan menggunakan file di`test`.) Tinjau **Pedoman 3** untuk memahami alasannya.
# Menambahkan pemicu ke alur kerja
Gunakan petunjuk berikut untuk menambahkan pemicu push, pull, atau schedule ke CodeCatalyst alur kerja Amazon Anda.
Untuk informasi lebih lanjut tentang menggunakan pemicu, lihat [Memulai alur kerja berjalan secara otomatis menggunakan pemicu](workflows-add-trigger.md).
------
#### [ Visual ]
**Untuk menambahkan pemicu (editor visual)**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Edit**.
1. Pilih **Visual**.
1. Dalam diagram alur kerja, pilih kotak **Sumber** dan **Pemicu.**
1. Di panel konfigurasi, Pilih **Tambah pemicu**.
1. Dalam **Tambahkan pemicu** kotak dialog, berikan informasi di bidang, sebagai berikut.
**Jenis pemicu**
Tentukan jenis pemicu. Anda dapat menggunakan salah satu nilai berikut:
+ **Dorong** (editor visual) atau `PUSH` (editor YAMAL)
Pemicu push memulai alur kerja saat perubahan didorong ke repositori sumber Anda. *Workflow run akan menggunakan file di cabang yang Anda dorong (yaitu, cabang tujuan).*
+ **Permintaan tarik** (editor visual) atau `PULLREQUEST` (editor YAMG)
Pemicu permintaan tarik memulai alur kerja saat permintaan tarik dibuka, diperbarui, atau ditutup di repositori sumber Anda. Workflow run akan menggunakan file di cabang yang Anda tarik *dari* (yaitu, cabang sumber).
+ **Jadwal** (editor visual) atau `SCHEDULE` (editor YAMG)
Pemicu jadwal memulai alur kerja berjalan pada jadwal yang ditentukan oleh ekspresi cron yang Anda tentukan. Jalankan alur kerja terpisah akan dimulai untuk setiap cabang di repositori sumber Anda menggunakan file cabang. (Untuk membatasi cabang tempat pemicu diaktifkan, gunakan bidang **Cabang** (editor visual) atau `Branches` properti (editor YAMG).)
Saat mengonfigurasi pemicu jadwal, ikuti panduan ini:
+ Hanya gunakan satu pemicu jadwal per alur kerja.
+ Jika Anda telah menentukan beberapa alur kerja di CodeCatalyst ruang Anda, sebaiknya Anda menjadwalkan tidak lebih dari 10 alur kerja untuk memulai secara bersamaan.
+ Pastikan Anda mengonfigurasi ekspresi cron pemicu dengan waktu yang cukup di antara proses. Untuk informasi selengkapnya, lihat [Expression](workflow-reference.md#workflow.triggers.expression).
Sebagai contoh, silakan lihat [Contoh: Pemicu dalam alur kerja](workflows-add-trigger-examples.md).
**Acara untuk permintaan tarik**
Bidang ini hanya muncul jika Anda memilih jenis pemicu **permintaan Tarik**.
Tentukan jenis peristiwa permintaan tarik yang akan memulai alur kerja. Berikut ini adalah nilai yang valid:
+ **Permintaan tarik dibuat** (editor visual) atau `OPEN` (editor YAMG)
Proses alur kerja dimulai saat permintaan tarik dibuat.
+ **Permintaan tarik ditutup** (editor visual) atau `CLOSED` (editor YAMG)
Proses alur kerja dimulai saat permintaan tarik ditutup. Perilaku `CLOSED` acara itu rumit, dan paling baik dipahami melalui sebuah contoh. Untuk informasi selengkapnya, lihat [Contoh: Pemicu dengan tarikan, cabang, dan acara 'CLOSED'](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close).
+ **Revisi baru dibuat untuk menarik permintaan** (editor visual) atau `REVISION` (editor YAMG)
Alur kerja dijalankan ketika revisi ke permintaan tarik dibuat. Revisi pertama dibuat saat permintaan tarik dibuat. Setelah itu, revisi baru dibuat setiap kali seseorang mendorong komit baru ke cabang sumber yang ditentukan dalam permintaan tarik. Jika Anda menyertakan `REVISION` peristiwa dalam pemicu permintaan tarik Anda, Anda dapat menghilangkan `OPEN` acara tersebut, karena `REVISION` merupakan superset dari. `OPEN`
Anda dapat menentukan beberapa peristiwa dalam pemicu permintaan tarik yang sama.
Sebagai contoh, lihat [Contoh: Pemicu dalam alur kerja](workflows-add-trigger-examples.md).
**Jadwal**
Bidang ini hanya muncul jika Anda memilih jenis pemicu **Jadwal**.
Tentukan ekspresi cron yang menjelaskan kapan Anda ingin alur kerja terjadwal Anda berjalan terjadi.
Ekspresi cron CodeCatalyst menggunakan sintaks enam bidang berikut, di mana setiap bidang dipisahkan oleh spasi:
*minutes* *hours* *days-of-month* *month* *days-of-week* *year*
**Contoh ekspresi cron**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/codecatalyst/latest/userguide/workflows-add-trigger-add.html)
Saat menentukan ekspresi cron di CodeCatalyst, pastikan Anda mengikuti panduan ini:
+ Tentukan ekspresi cron tunggal per `SCHEDULE` pemicu.
+ Lampirkan ekspresi cron dalam tanda kutip ganda (`"`) di editor YAMG.
+ Tentukan waktu di Coordinated Universal Time (UTC). Zona waktu lain tidak didukung.
+ Konfigurasikan setidaknya 30 menit di antara proses. Irama yang lebih cepat tidak didukung.
+ Tentukan *days-of-week* bidang *days-of-month* atau, tetapi tidak keduanya. Jika Anda menentukan nilai atau tanda bintang (`*`) di salah satu bidang, Anda harus menggunakan tanda tanya (`?`) di bidang lainnya. Tanda bintang berarti 'semua' dan tanda tanya berarti 'apa saja'.
Untuk lebih banyak contoh ekspresi cron dan informasi tentang wildcard seperti`?`,`*`, dan`L`, lihat [referensi ekspresi Cron di Panduan](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html) Pengguna *Amazon EventBridge *. Ekspresi cron masuk EventBridge dan CodeCatalyst bekerja dengan cara yang persis sama.
Untuk contoh pemicu jadwal, lihat[Contoh: Pemicu dalam alur kerja](workflows-add-trigger-examples.md).
**Cabang** dan **pola Cabang**
(Opsional)
Tentukan cabang di repositori sumber Anda yang dipantau pemicu untuk mengetahui kapan harus memulai alur kerja. Anda dapat menggunakan pola regex untuk menentukan nama cabang Anda. Misalnya, gunakan `main.*` untuk mencocokkan semua cabang yang dimulai dengan`main`.
Cabang yang akan ditentukan berbeda tergantung pada jenis pemicu:
+ *Untuk pemicu push, tentukan cabang yang Anda dorong, yaitu cabang *tujuan*.* Satu alur kerja akan dimulai per cabang yang cocok, menggunakan file di cabang yang cocok.
Contoh:`main.*`, `mainline`
+ *Untuk pemicu permintaan tarik, tentukan cabang yang Anda dorong, yaitu cabang *tujuan*.* Satu alur kerja akan dimulai per cabang yang cocok, menggunakan file definisi alur kerja dan file sumber di cabang **sumber** (*bukan* cabang yang cocok).
Contoh:`main.*`,`mainline`, `v1\-.*` (cocok dengan cabang yang dimulai dengan`v1-`)
+ Untuk pemicu jadwal, tentukan cabang yang berisi file yang ingin Anda jalankan terjadwal untuk digunakan. Satu alur kerja akan dimulai per cabang yang cocok, menggunakan file definisi alur kerja dan file sumber di cabang yang cocok.
Contoh:`main.*`, `version\-1\.0`
**catatan**
Jika Anda *tidak* menentukan cabang, pemicu memantau semua cabang di repositori sumber Anda, dan akan memulai alur kerja menggunakan file definisi alur kerja dan file sumber di:
Cabang yang Anda dorong (*untuk* pemicu push). Untuk informasi selengkapnya, lihat [Contoh: Pemicu push kode sederhana](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple).
*Cabang yang Anda tarik (untuk pemicu permintaan tarik).* Untuk informasi selengkapnya, lihat [Contoh: Pemicu permintaan tarik sederhana](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple).
Semua cabang (untuk pemicu jadwal). Satu alur kerja akan dimulai per cabang di repositori sumber Anda. Untuk informasi selengkapnya, lihat [Contoh: Pemicu jadwal sederhana](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple).
Untuk informasi lebih lanjut tentang cabang dan pemicu, lihat[Pedoman penggunaan untuk pemicu dan cabang](workflows-add-trigger-considerations.md).
Untuk contoh lainnya, lihat [Contoh: Pemicu dalam alur kerja](workflows-add-trigger-examples.md).
**File diubah**
Bidang ini hanya muncul jika Anda memilih jenis pemicu **permintaan **Push** atau Pull**.
Tentukan file atau folder di repositori sumber Anda yang dipantau pemicu untuk mengetahui kapan harus memulai alur kerja. Anda dapat menggunakan ekspresi reguler untuk mencocokkan nama file atau jalur.
Sebagai contoh, lihat [Contoh: Pemicu dalam alur kerja](workflows-add-trigger-examples.md).
1. (Opsional) Pilih **Validasi** untuk memvalidasi kode YAMAL alur kerja sebelum melakukan.
1. Pilih **Komit**, masukkan pesan komit, dan pilih **Komit** lagi.
------
#### [ YAML ]
**Untuk menambahkan pemicu (editor YAMAL)**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Edit**.
1. Pilih **YAMAL.**
1. Tambahkan `Triggers` bagian dan properti yang mendasari menggunakan contoh berikut sebagai panduan. Untuk informasi lebih lanjut, lihat [Triggers](workflow-reference.md#triggers-reference) di[Alur kerja definisi YAMAL](workflow-reference.md).
Pemicu push kode mungkin terlihat seperti ini:
```
Triggers:
- Type: PUSH
Branches:
- main
```
Pemicu permintaan tarik mungkin terlihat seperti ini:
```
Triggers:
- Type: PULLREQUEST
Branches:
- main.*
Events:
- OPEN
- REVISION
- CLOSED
```
Pemicu jadwal mungkin terlihat seperti ini:
```
Triggers:
- Type: SCHEDULE
Branches:
- main.*
# Run the workflow at 1:15 am (UTC+0) every Friday until the end of 2023
Expression: "15 1 ? * FRI 2022-2023"
```
Untuk lebih banyak contoh ekspresi cron yang dapat Anda gunakan di `Expression` properti, lihat[Expression](workflow-reference.md#workflow.triggers.expression).
Untuk lebih banyak contoh push, pull request, dan schedule trigger, lihat[Contoh: Pemicu dalam alur kerja](workflows-add-trigger-examples.md).
1. (Opsional) Pilih **Validasi** untuk memvalidasi kode YAMAL alur kerja sebelum melakukan.
1. Pilih **Komit**, masukkan pesan komit, dan pilih **Komit** lagi.
------
# Mengkonfigurasi pemicu manual saja
Anda dapat membatasi alur kerja sehingga hanya dapat dimulai secara manual oleh tim Anda menggunakan tombol **Run** di CodeCatalyst konsol. Untuk mengkonfigurasi fungsi ini, Anda harus menghapus `Triggers` bagian dalam file definisi alur kerja. `Triggers`Bagian ini disertakan secara default saat Anda membuat alur kerja, tetapi bagian ini opsional dan dapat dihapus.
Gunakan petunjuk berikut untuk menghapus `Triggers` bagian dalam file definisi alur kerja sehingga alur kerja hanya dapat dimulai secara manual.
Untuk informasi lebih lanjut tentang menggunakan pemicu, lihat [Memulai alur kerja berjalan secara otomatis menggunakan pemicu](workflows-add-trigger.md).
Untuk informasi selengkapnya tentang menjalankan alur kerja, lihat[Menjalankan alur kerja](workflows-working-runs.md).
------
#### [ Visual ]
**Untuk menghapus bagian 'Pemicu' (editor visual)**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Edit**.
1. Pilih **Visual**.
1. Pilih kotak **Sumber** dalam diagram alur kerja.
1. Di bawah **Pemicu**, pilih ikon tempat sampah untuk menghapus `Triggers` bagian dari alur kerja.
1. (Opsional) Pilih **Validasi** untuk memvalidasi kode YAMAL alur kerja sebelum melakukan.
1. Pilih **Komit**, masukkan pesan komit, dan pilih **Komit** lagi.
------
#### [ YAML ]
**Untuk menghapus bagian 'Pemicu' (editor YAMAL)**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Edit**.
1. Pilih **YAMAL.**
1. Temukan `Triggers` bagian dan hapus.
1. (Opsional) Pilih **Validasi** untuk memvalidasi kode YAMAL alur kerja sebelum melakukan.
1. Pilih **Komit**, masukkan pesan komit, dan pilih **Komit** lagi.
------
# Menghentikan alur kerja
Gunakan prosedur berikut untuk menghentikan alur kerja yang sedang berlangsung. Anda mungkin ingin berhenti berlari jika dimulai secara tidak sengaja.
Saat Anda menghentikan proses alur kerja, CodeCatalyst tunggu tindakan yang sedang berlangsung selesai sebelum menandai proses sebagai **Berhenti di konsol**. CodeCatalyst Setiap tindakan yang tidak memiliki kesempatan untuk memulai tidak akan dimulai, dan akan ditandai sebagai **Ditinggalkan**.
**catatan**
Jika run antri (yaitu, tidak ada tindakan yang sedang berlangsung), maka run segera dihentikan.
Untuk informasi selengkapnya tentang alur kerja berjalan, lihat[Menjalankan alur kerja](workflows-working-runs.md).
**Untuk menghentikan alur kerja**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Di bawah **Alur kerja**, pilih **Runs** dan pilih run dalam proses dari daftar.
1. Pilih **Berhenti**.
# Gating alur kerja berjalan
*Gate* adalah komponen alur kerja yang dapat Anda gunakan untuk mencegah alur kerja berjalan kecuali kondisi tertentu terpenuhi. Contoh gerbang adalah gerbang **Persetujuan** tempat pengguna harus mengirimkan persetujuan di CodeCatalyst konsol sebelum proses alur kerja diizinkan untuk dilanjutkan.
Anda dapat menambahkan gerbang di antara urutan tindakan dalam alur kerja, atau sebelum tindakan pertama (yang berjalan segera setelah **Sumber** diunduh). Anda juga dapat menambahkan gerbang setelah tindakan terakhir, jika Anda perlu melakukannya.
Untuk informasi selengkapnya tentang alur kerja berjalan, lihat[Menjalankan alur kerja](workflows-working-runs.md).
**Topics**
+ [Jenis gerbang](#workflows-gates-types)
+ [Bisakah saya mengatur gerbang untuk berjalan secara paralel dengan tindakan lain?](#workflows-approval-parallel)
+ [Bisakah saya menggunakan gerbang untuk mencegah alur kerja berjalan?](#workflows-gates-prevent)
+ [Keterbatasan gerbang](#workflows-gate-limitations)
+ [Menambahkan gerbang ke alur kerja](workflows-gates-add.md)
+ [Gerbang dan tindakan sekuensing](workflows-gates-depends-on.md)
+ [Menentukan versi gerbang](workflows-gates-version.md)
## Jenis gerbang
Saat ini, Amazon CodeCatalyst mendukung satu jenis gerbang: gerbang **Persetujuan**. Untuk informasi selengkapnya, lihat [Memerlukan persetujuan pada alur kerja berjalan](workflows-approval.md).
## Bisakah saya mengatur gerbang untuk berjalan secara paralel dengan tindakan lain?
Tidak. Gates hanya bisa berjalan sebelum atau sesudah tindakan. Untuk informasi selengkapnya, lihat [Gerbang dan tindakan sekuensing](workflows-gates-depends-on.md).
## Bisakah saya menggunakan gerbang untuk mencegah alur kerja berjalan?
Ya, dengan kualifikasi.
Anda dapat mencegah alur kerja *menjalankan tugas*, yang sedikit berbeda dari mencegahnya *memulai*.
Untuk mencegah alur kerja melakukan tugas, tambahkan gerbang sebelum tindakan pertama dalam alur kerja. Dalam skenario ini, alur kerja *akan dimulai —artinya akan* mengunduh file repositori sumber Anda—tetapi akan dicegah melakukan tugas sampai gerbang dibuka kuncinya.
**catatan**
Alur kerja yang dimulai dan kemudian diblokir oleh gerbang masih dihitung terhadap *jumlah maksimum alur kerja bersamaan berjalan per kuota ruang* dan kuota lainnya. Untuk memastikan bahwa Anda tidak melebihi kuota alur kerja, pertimbangkan untuk menggunakan pemicu alur kerja untuk memulai alur kerja secara kondisional alih-alih menggunakan gerbang. Pertimbangkan juga untuk menggunakan aturan persetujuan permintaan tarik alih-alih gerbang. Untuk informasi selengkapnya tentang kuota, pemicu, dan aturan persetujuan permintaan tarik, lihat [Kuota untuk alur kerja di CodeCatalyst](workflows-quotas.md)[Memulai alur kerja berjalan secara otomatis menggunakan pemicu](workflows-add-trigger.md), dan. [Mengelola persyaratan untuk menggabungkan permintaan tarik dengan aturan persetujuan](source-pull-requests-approval-rules.md)
## Keterbatasan gerbang
Gates memiliki batasan sebagai berikut:
+ Gates tidak dapat digunakan bersama dengan fitur berbagi komputasi. Untuk informasi selengkapnya tentang fitur ini, lihat [Berbagi komputasi di seluruh tindakan](compute-sharing.md).
+ Gates tidak dapat digunakan dalam kelompok aksi. Untuk informasi selengkapnya tentang grup aksi, lihat[Mengelompokkan tindakan ke dalam kelompok aksi](workflows-group-actions.md).
# Menambahkan gerbang ke alur kerja
Di Amazon CodeCatalyst, Anda dapat menambahkan gerbang ke alur kerja untuk mencegahnya berjalan kecuali kondisi tertentu terpenuhi. Gunakan petunjuk berikut untuk menambahkan gerbang ke alur kerja.
Untuk informasi lebih lanjut tentang gerbang, lihat[Gating alur kerja berjalan](workflows-gates.md).
**Untuk menambah dan mengkonfigurasi gerbang**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Edit**.
1. Pilih **Visual**.
1. Di sebelah kiri, pilih **Gates**.
1. Di katalog gerbang, cari gerbang, lalu pilih tanda plus (**\$1**) untuk menambahkan gerbang ke alur kerja Anda.
1. Konfigurasikan gerbang. Pilih **Visual** untuk menggunakan editor visual, atau **YAMAL untuk** menggunakan editor YAMAL. Untuk petunjuk terperinci, lihat:
+ [Menambahkan gerbang 'Persetujuan'](workflows-approval-add.md)
1. (Opsional) Pilih **Validasi** untuk memastikan kode YAMAL valid.
1. Pilih **Komit** untuk melakukan perubahan Anda.
# Gerbang dan tindakan sekuensing
Di Amazon CodeCatalyst, Anda dapat mengatur gerbang untuk dijalankan sebelum atau setelah tindakan alur kerja, grup tindakan, atau gerbang. Misalnya, Anda dapat mengatur `Approval` gerbang untuk dijalankan sebelum `Deploy` tindakan. Dalam hal ini, `Deploy` tindakan dikatakan *tergantung pada* `Approval` gerbang.
Untuk mengatur dependensi antara gerbang dan tindakan, konfigurasikan properti **Depend on** gate atau action. Untuk petunjuk, silakan lihat [Menyiapkan dependensi antar tindakan](workflows-depends-on-set-up.md). Instruksi yang direferensikan mengacu pada *tindakan* alur kerja tetapi berlaku sama untuk gerbang.
Untuk contoh cara mengatur **Tergantung pada** properti dengan gerbang, lihat[Contoh: Gerbang 'Persetujuan'](workflows-approval-example.md).
Untuk informasi lebih lanjut tentang gerbang, lihat[Gating alur kerja berjalan](workflows-gates.md).
Untuk informasi selengkapnya tentang tindakan alur kerja, lihat[Mengkonfigurasi tindakan alur kerja](workflows-actions.md).
# Menentukan versi gerbang
Secara default, saat Anda menambahkan gerbang ke alur kerja, CodeCatalyst tambahkan versi lengkap ke file definisi alur kerja menggunakan format:
`vmajor.minor.patch`
Sebagai contoh:
```
My-Gate:
Identifier: aws/approval@v1
```
Anda dapat memperpanjang versi sehingga alur kerja menggunakan versi mayor atau minor tertentu dari gerbang. Untuk petunjuk, silakan lihat [Menentukan versi tindakan yang akan digunakan](workflows-action-versions.md). Topik yang direferensikan mengacu pada tindakan alur kerja tetapi berlaku sama untuk gerbang.
Untuk informasi lebih lanjut tentang gerbang di CodeCatalyst, lihat[Gating alur kerja berjalan](workflows-gates.md).
# Memerlukan persetujuan pada alur kerja berjalan
Anda dapat mengonfigurasi alur kerja untuk meminta persetujuan sebelum dapat dilanjutkan. Untuk mencapai ini, Anda harus menambahkan [gerbang](workflows-gates.md) **Persetujuan** ke alur kerja. *Gerbang Persetujuan* mencegah alur kerja berjalan hingga pengguna atau kumpulan pengguna mengirimkan satu atau beberapa persetujuan di konsol. CodeCatalyst Setelah semua persetujuan diberikan, gerbang 'tidak terkunci' dan alur kerja dijalankan diizinkan untuk dilanjutkan.
Gunakan gerbang **Persetujuan** dalam alur kerja Anda untuk memberi kesempatan kepada tim pengembangan, operasi, dan kepemimpinan Anda untuk meninjau perubahan Anda sebelum diterapkan ke khalayak yang lebih luas.
Untuk informasi selengkapnya tentang alur kerja berjalan, lihat[Menjalankan alur kerja](workflows-working-runs.md).
**Topics**
+ [Bagaimana cara membuka gerbang persetujuan?](#workflows-approval-conditions)
+ [Kapan menggunakan gerbang 'Persetujuan'](#workflows-approval-when)
+ [Siapa yang bisa memberikan persetujuan?](#workflows-approval-who)
+ [Bagaimana cara memberi tahu pengguna bahwa persetujuan diperlukan?](#workflows-approval-notify-methods)
+ [Dapatkah saya menggunakan gerbang 'Persetujuan' untuk mencegah alur kerja berjalan?](#workflows-approval-prevent)
+ [Bagaimana cara kerja persetujuan alur kerja dengan mode lari antrian, digantikan, dan paralel?](#workflows-approval-run-mode)
+ [Contoh: Gerbang 'Persetujuan'](workflows-approval-example.md)
+ [Menambahkan gerbang 'Persetujuan'](workflows-approval-add.md)
+ [Mengkonfigurasi pemberitahuan persetujuan](workflows-approval-notify.md)
+ [Menyetujui atau menolak alur kerja](workflows-approval-approve.md)
+ [Gerbang 'Persetujuan' YAMAL](approval-ref.md)
## Bagaimana cara membuka gerbang persetujuan?
Untuk membuka gerbang **Persetujuan**, *semua* ketentuan berikut harus dipenuhi:
+ **Kondisi 1**: Jumlah persetujuan yang diperlukan harus diserahkan. Jumlah persetujuan yang diperlukan dapat dikonfigurasi, dan setiap pengguna diizinkan untuk mengirimkan satu persetujuan.
+ **Kondisi 2**: Semua persetujuan harus diserahkan sebelum waktu gerbang habis. Waktu gerbang habis 14 hari setelah diaktifkan. Periode ini tidak dapat dikonfigurasi.
+ **Kondisi 3**: Tidak ada yang harus menolak alur kerja yang dijalankan. Penolakan tunggal akan menyebabkan alur kerja berjalan gagal.
+ **Kondisi 4**: (Hanya berlaku jika Anda menggunakan mode lari yang digantikan.) Lari tidak boleh digantikan oleh lari nanti. Untuk informasi selengkapnya, lihat [Bagaimana cara kerja persetujuan alur kerja dengan mode lari antrian, digantikan, dan paralel?](#workflows-approval-run-mode).
Jika salah satu kondisi tidak terpenuhi, CodeCatalyst hentikan alur kerja dan atur status run ke **Gagal** (dalam kasus **Kondisi 1** hingga **3**) atau **Digantikan** (dalam kasus **Kondisi** 4).
## Kapan menggunakan gerbang 'Persetujuan'
Biasanya, Anda akan menggunakan gerbang **Persetujuan** dalam alur kerja yang menyebarkan aplikasi dan sumber daya lainnya ke server produksi atau lingkungan di mana standar kualitas harus divalidasi. Dengan menempatkan gerbang sebelum penyebaran ke produksi, Anda memberi pengulas kesempatan untuk memvalidasi revisi perangkat lunak baru Anda sebelum tersedia untuk umum.
## Siapa yang bisa memberikan persetujuan?
Setiap pengguna yang merupakan anggota proyek Anda dan yang memiliki peran **Kontributor** atau **administrator Proyek** dapat memberikan persetujuan. Pengguna dengan peran **administrator Space** yang termasuk dalam ruang proyek Anda juga dapat memberikan persetujuan.
**catatan**
Pengguna dengan peran **Peninjau** tidak dapat memberikan persetujuan.
## Bagaimana cara memberi tahu pengguna bahwa persetujuan diperlukan?
Untuk memberi tahu pengguna bahwa persetujuan diperlukan, Anda harus:
+ CodeCatalyst Kirimi mereka pemberitahuan Slack. Untuk informasi selengkapnya, lihat [Mengkonfigurasi pemberitahuan persetujuan](workflows-approval-notify.md).
+ Buka halaman di CodeCatalyst konsol tempat tombol **Setujui** dan **Tolak** berada, dan tempel URL halaman itu ke aplikasi email atau pesan yang ditujukan kepada pemberi persetujuan. Untuk informasi selengkapnya tentang cara menavigasi ke halaman ini, lihat[Menyetujui atau menolak alur kerja](workflows-approval-approve.md).
## Dapatkah saya menggunakan gerbang 'Persetujuan' untuk mencegah alur kerja berjalan?
Ya, dengan kualifikasi. Untuk informasi selengkapnya, lihat [Bisakah saya menggunakan gerbang untuk mencegah alur kerja berjalan?](workflows-gates.md#workflows-gates-prevent).
## Bagaimana cara kerja persetujuan alur kerja dengan mode lari antrian, digantikan, dan paralel?
[Saat menggunakan mode lari antrian, digantikan, atau paralel, gerbang **Persetujuan** bekerja dengan cara yang mirip dengan tindakan.](workflows-actions.md) Kami menyarankan membaca[Tentang mode lari antrian](workflows-configure-runs.md#workflows-configure-runs-queued),[Tentang mode lari yang digantikan](workflows-configure-runs.md#workflows-configure-runs-superseded), [Tentang mode parallel run](workflows-configure-runs.md#workflows-configure-runs-parallel) bagian untuk membiasakan diri dengan mode run ini. Setelah Anda memiliki pemahaman dasar tentang mereka, kembali ke bagian ini untuk mencari tahu bagaimana mode run ini bekerja ketika gerbang **Persetujuan** hadir.
Ketika gerbang **Persetujuan** hadir, proses diproses sebagai berikut:
+ Jika Anda menggunakan [mode lari antrian, run akan mengantri](workflows-configure-runs.md#workflows-configure-runs-queued) di belakang run yang saat ini menunggu persetujuan di gerbang. Ketika gerbang itu menjadi tidak terkunci (yaitu, semua persetujuan telah diberikan), proses berikutnya dalam antrian maju ke gerbang, dan menunggu persetujuan. Proses ini berlanjut dengan proses antrian yang diproses melalui gerbang. one-by-one [Figure 1](#figure-1-workflow-queued-run-mode-ma)menggambarkan proses ini.
+ Jika Anda menggunakan [mode run yang digantikan](workflows-configure-runs.md#workflows-configure-runs-superseded), perilakunya sama dengan mode lari antrian, kecuali bahwa alih-alih menjalankan menumpuk dalam antrian di gerbang, proses yang lebih baru menggantikan (mengambil alih dari) proses sebelumnya. Tidak ada antrian, dan lari apa pun yang saat ini menunggu di gerbang untuk persetujuan akan dibatalkan dan digantikan oleh proses yang lebih baru. [Figure 2](#figure-2-workflow-superseded-run-mode-ma)menggambarkan proses ini.
+ Jika Anda menggunakan [mode parallel run, run](workflows-configure-runs.md#workflows-configure-runs-parallel) start secara paralel dan tidak ada bentuk antrian. Setiap proses diproses oleh gerbang segera karena tidak ada jalan di depannya. [Figure 3](#figure-3-workflow-parallel-run-mode-ma)menggambarkan proses ini.
**Gambar 1****: 'Mode lari antrian' dan gerbang Persetujuan**
![\[Cara kerja gerbang 'Persetujuan' dengan 'mode lari antrian'\]](http://docs.aws.amazon.com/id_id/codecatalyst/latest/userguide/images/flows/runmode-queued-ma.png)
**Gambar 2****: 'Mode lari yang digantikan' dan gerbang Persetujuan**
![\[Cara kerja gerbang 'Persetujuan' dengan 'mode run yang digantikan'\]](http://docs.aws.amazon.com/id_id/codecatalyst/latest/userguide/images/flows/runmode-superseded-ma.png)
**Gambar 3****: 'Mode lari paralel' dan gerbang Persetujuan**
![\[Cara kerja gerbang 'Persetujuan' dengan 'mode lari paralel'\]](http://docs.aws.amazon.com/id_id/codecatalyst/latest/userguide/images/flows/runmode-parallel-ma.png)
# Contoh: Gerbang 'Persetujuan'
Contoh berikut menunjukkan cara menambahkan gerbang **Persetujuan** yang disebut `Approval_01` antara dua tindakan yang disebut`Staging`, dan`Production`. `Staging`Aksi berjalan pertama, `Approval_01` gerbang kedua, dan `Production` aksi terakhir. `Production`Tindakan hanya berjalan jika `Approval_01` gerbang tidak terkunci. `DependsOn`Properti memastikan bahwa`Staging`,`Approval_01`, dan `Production` fase berjalan dalam urutan berurutan.
Untuk informasi selengkapnya tentang gerbang **Persetujuan**, lihat[Memerlukan persetujuan pada alur kerja berjalan](workflows-approval.md).
```
Actions:
Staging: # Deploy to a staging server
Identifier: aws/ecs-deploy@v1
Configuration:
...
Approval_01:
Identifier: aws/approval@v1
DependsOn:
- Staging
Configuration:
ApprovalsRequired: 2
Production: # Deploy to a production server
Identifier: aws/ecs-deploy@v1
DependsOn:
- Approval_01
Configuration:
...
```
# Menambahkan gerbang 'Persetujuan'
Untuk mengonfigurasi alur kerja agar memerlukan persetujuan, Anda harus menambahkan gerbang **Persetujuan** ke alur kerja. Gunakan petunjuk berikut untuk menambahkan gerbang **Persetujuan** ke alur kerja Anda.
Untuk informasi lebih lanjut tentang gerbang ini, lihat[Memerlukan persetujuan pada alur kerja berjalan](workflows-approval.md).
------
#### [ Visual ]
**Untuk menambahkan gerbang 'Persetujuan' ke alur kerja (editor visual)**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Edit**.
1. Di kiri atas, pilih **Gates**.
1. Di katalog **Gates**, di **Approval**, pilih tanda plus (**\$1**).
1. Pilih **Input**, dan di bidang **Tergantung pada**, lakukan hal berikut.
Tentukan tindakan, grup tindakan, atau gerbang yang harus berjalan dengan sukses agar gerbang ini berjalan. Secara default, saat Anda menambahkan gerbang ke alur kerja, gerbang diatur untuk bergantung pada tindakan terakhir dalam alur kerja Anda. Jika Anda menghapus properti ini, gerbang tidak akan tergantung pada apa pun, dan akan berjalan terlebih dahulu, sebelum tindakan lain.
**catatan**
Gerbang harus dikonfigurasi untuk dijalankan sebelum atau sesudah tindakan, grup tindakan, atau gerbang. Itu tidak dapat diatur untuk berjalan secara paralel dengan tindakan lain, kelompok tindakan, dan gerbang.
Untuk informasi selengkapnya tentang **Tergantung pada** fungsionalitas, lihat[Gerbang dan tindakan sekuensing](workflows-gates-depends-on.md).
1. Pilih tab **Konfigurasi**.
1. Di bidang **nama Gerbang**, lakukan hal berikut.
Tentukan nama yang ingin Anda berikan gerbang. Semua nama gerbang harus unik dalam alur kerja. Nama gerbang terbatas pada karakter alfanumerik (a-z, A-Z, 0-9), tanda hubung (-), dan garis bawah (\$1). Spasi tidak diizinkan. Anda tidak dapat menggunakan tanda kutip untuk mengaktifkan karakter dan spasi khusus dalam nama gerbang.
1. (Opsional) Di bidang **Jumlah persetujuan**, lakukan hal berikut.
Tentukan jumlah minimum persetujuan yang diperlukan untuk membuka gerbang **Persetujuan**. Minimal adalah`1`. Maksimal adalah`2`. Jika dihilangkan, default-nya adalah `1`.
**catatan**
Jika Anda ingin menghilangkan `ApprovalsRequired` properti, hapus `Configuration` bagian gerbang dari file definisi alur kerja.
1. (Opsional) Pilih **Validasi** untuk memvalidasi kode YAMAL alur kerja sebelum melakukan.
1. Pilih **Komit**, masukkan pesan komit, dan pilih **Komit** lagi.
------
#### [ YAML ]
**Untuk menambahkan gerbang 'Persetujuan' ke alur kerja (editor YAMG)**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Edit**.
1. Pilih **YAMAL.**
1. Tambahkan `Approval` bagian dan properti yang mendasari menggunakan contoh berikut sebagai panduan. Untuk informasi lebih lanjut, lihat [Gerbang 'Persetujuan' YAMAL](approval-ref.md) di[Alur kerja definisi YAMAL](workflow-reference.md).
```
Actions:
MyApproval_01:
Identifier: aws/approval@v1
DependsOn:
- PreviousAction
Configuration:
ApprovalsRequired: 2
```
Untuk contoh lain, lihat[Contoh: Gerbang 'Persetujuan'](workflows-approval-example.md).
1. (Opsional) Pilih **Validasi** untuk memvalidasi kode YAMAL alur kerja sebelum melakukan.
1. Pilih **Komit**, masukkan pesan komit, dan pilih **Komit** lagi.
------
# Mengkonfigurasi pemberitahuan persetujuan
Anda dapat CodeCatalyst mengirim pemberitahuan ke saluran Slack yang memberi tahu pengguna bahwa alur kerja berjalan memerlukan persetujuan. Pengguna melihat notifikasi dan mengklik tautan di dalamnya. Tautan membawa mereka ke halaman CodeCatalyst persetujuan di mana mereka dapat menyetujui atau menolak alur kerja.
Anda juga dapat mengonfigurasi notifikasi untuk memberi tahu pengguna bahwa alur kerja telah disetujui, ditolak, atau bahwa permintaan persetujuan telah kedaluwarsa.
Gunakan petunjuk berikut untuk mengatur notifikasi Slack.
**Sebelum Anda mulai**
Pastikan Anda telah menambahkan gerbang **Persetujuan** ke alur kerja Anda. Untuk informasi selengkapnya, lihat [Menambahkan gerbang 'Persetujuan'](workflows-approval-add.md).
**Untuk mengirim pemberitahuan persetujuan alur kerja ke saluran Slack**
1. Konfigurasikan CodeCatalyst dengan Slack. Untuk informasi selengkapnya, lihat [Memulai dengan notifikasi Slack](getting-started-notifications.md).
1. Dalam CodeCatalyst proyek yang berisi alur kerja yang memerlukan persetujuan, aktifkan notifikasi, jika belum diaktifkan. Untuk mengaktifkan notifikasi:
1. Arahkan ke proyek Anda dan di panel navigasi, pilih **Pengaturan proyek**.
1. Di bagian atas, pilih **Notifikasi**.
1. Di **acara Pemberitahuan**, pilih **Edit notifikasi**.
1. Aktifkan **persetujuan alur kerja tertunda** dan pilih saluran Slack tempat CodeCatalyst akan mengirim notifikasi.
1. (Opsional) Aktifkan notifikasi tambahan untuk memberi tahu orang tentang persetujuan yang disetujui, ditolak, dan kedaluwarsa. **Anda dapat mengaktifkan **Workflow run approved**, **Workflow run ditolak**, **Persetujuan alur kerja digantikan, dan persetujuan** alur kerja habis.** Di sebelah setiap notifikasi, pilih saluran Slack tempat CodeCatalyst akan mengirim notifikasi.
1. Pilih **Simpan**.
# Menyetujui atau menolak alur kerja
Alur kerja yang menyertakan gerbang **Persetujuan** harus disetujui atau ditolak. Pengguna dapat memberikan persetujuan atau penolakan mereka mulai dari:
+ CodeCatalyst konsol
+ tautan yang disediakan oleh anggota tim
+ pemberitahuan Slack otomatis
Setelah pengguna memberikan persetujuan atau penolakan mereka, keputusan ini tidak dapat dibatalkan.
**catatan**
Hanya pengguna tertentu yang dapat menyetujui atau menolak alur kerja yang dijalankan. Untuk informasi selengkapnya, lihat [Siapa yang bisa memberikan persetujuan?](workflows-approval.md#workflows-approval-who).
**Sebelum kamu memulai**
Pastikan Anda telah menambahkan gerbang **Persetujuan** ke alur kerja Anda. Untuk informasi selengkapnya, lihat [Menambahkan gerbang 'Persetujuan'](workflows-approval-add.md).
**Untuk menyetujui atau menolak alur kerja yang dijalankan mulai dari konsol CodeCatalyst**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Dalam diagram alur kerja, pilih kotak yang mewakili gerbang **Persetujuan**.
Panel samping muncul.
**catatan**
Pada titik ini, Anda dapat mengirim URL halaman ini ke pemberi persetujuan lain jika Anda mau.
1. Di bawah **keputusan Tinjau**, pilih **Menyetujui** atau **Tolak**.
1. (Opsional) Di **Komentar - opsional**, masukkan komentar yang menunjukkan mengapa Anda menyetujui atau menolak alur kerja berjalan.
1. Pilih **Kirim**.
**Untuk menyetujui atau menolak alur kerja yang dimulai dari tautan yang disediakan oleh anggota tim**
1. Pilih tautan yang dikirimkan kepada Anda oleh anggota tim Anda. (Anda dapat meminta anggota tim Anda membaca prosedur sebelumnya untuk mendapatkan tautan.)
1. Masuk ke CodeCatalyst, jika ditanya.
Anda diarahkan ke halaman persetujuan jalankan alur kerja.
1. Di bawah **keputusan Tinjau**, pilih **Menyetujui** atau **Tolak**.
1. (Opsional) Di **Komentar - opsional**, masukkan komentar yang menunjukkan mengapa Anda menyetujui atau menolak alur kerja berjalan.
1. Pilih **Kirim**.
**Untuk menyetujui atau menolak alur kerja yang dimulai dari pemberitahuan Slack otomatis**
1. Pastikan notifikasi Slack sudah diatur. Lihat [Mengkonfigurasi pemberitahuan persetujuan](workflows-approval-notify.md).
1. Di Slack, di saluran tempat pemberitahuan persetujuan dikirim, pilih tautan dalam pemberitahuan persetujuan.
1. Masuk ke CodeCatalyst, jika ditanya.
Anda diarahkan ke halaman jalankan alur kerja.
1. Dalam diagram alur kerja, pilih gerbang persetujuan.
1. Di bawah **keputusan Tinjau**, pilih **Menyetujui** atau **Tolak**.
1. (Opsional) Di **Komentar - opsional**, masukkan komentar yang menunjukkan mengapa Anda menyetujui atau menolak alur kerja berjalan.
1. Pilih **Kirim**.
# Gerbang 'Persetujuan' YAMAL
Berikut ini adalah definisi YAMAL dari gerbang **Persetujuan**. Untuk mempelajari cara menggunakan gerbang ini, lihat[Memerlukan persetujuan pada alur kerja berjalan](workflows-approval.md).
Definisi tindakan ini ada sebagai bagian dalam file definisi alur kerja yang lebih luas. Untuk informasi selengkapnya tentang file ini, lihat[Alur kerja definisi YAMAL](workflow-reference.md).
**catatan**
Sebagian besar properti YAMAL yang mengikuti memiliki elemen UI yang sesuai di editor visual. Untuk mencari elemen UI, gunakan **Ctrl\$1F**. Elemen akan terdaftar dengan properti YAMLnya yang terkait.
```
# The workflow definition starts here.
# See Properti tingkat atas for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The 'Approval' gate definition starts here.
Approval:
Identifier: aws/approval@v1
DependsOn:
- another-action
Configuration:
ApprovalsRequired: number
```
## Approval
(Diperlukan)
Tentukan nama yang ingin Anda berikan gerbang. Semua nama gerbang harus unik dalam alur kerja. Nama gerbang terbatas pada karakter alfanumerik (a-z, A-Z, 0-9), tanda hubung (-), dan garis bawah (\$1). Spasi tidak diizinkan. Anda tidak dapat menggunakan tanda kutip untuk mengaktifkan karakter dan spasi khusus dalam nama gerbang.
Default: `Approval_nn`.
UI yang sesuai: Tab konfigurasi/nama **Gerbang**
## Identifier
(*Approval*/**Identifier**)
(Diperlukan)
Mengidentifikasi gerbang. Gerbang **Persetujuan** mendukung versi`1.0.0`. Jangan mengubah properti ini kecuali Anda ingin mempersingkat versinya. Untuk informasi selengkapnya, lihat [Menentukan versi tindakan yang akan digunakan](workflows-action-versions.md).
Default: `aws/approval@v1`.
**UI yang sesuai: Diagram alur Approval kerja/\$1nn/ aws/persetujuan @v1 label**
## DependsOn
(*Approval*/**DependsOn**)
(Opsional)
Tentukan tindakan, grup tindakan, atau gerbang yang harus berjalan dengan sukses agar gerbang ini berjalan. Secara default, saat Anda menambahkan gerbang ke alur kerja, gerbang diatur untuk bergantung pada tindakan terakhir dalam alur kerja Anda. Jika Anda menghapus properti ini, gerbang tidak akan tergantung pada apa pun, dan akan berjalan terlebih dahulu, sebelum tindakan lain.
**catatan**
Gerbang harus dikonfigurasi untuk dijalankan sebelum atau sesudah tindakan, grup tindakan, atau gerbang. Itu tidak dapat diatur untuk berjalan secara paralel dengan tindakan lain, kelompok tindakan, dan gerbang.
Untuk informasi selengkapnya tentang **Tergantung pada** fungsionalitas, lihat[Gerbang dan tindakan sekuensing](workflows-gates-depends-on.md).
**UI yang sesuai: Tab masukan/Tergantung pada**
## Configuration
(*Approval*/**Configuration**)
(Opsional)
Bagian di mana Anda dapat menentukan properti konfigurasi gerbang.
UI yang sesuai: Tab **konfigurasi**
## ApprovalsRequired
(*Approval*/Configuration/**ApprovalsRequired**)
(Opsional)
Tentukan jumlah minimum persetujuan yang diperlukan untuk membuka gerbang **Persetujuan**. Minimal adalah`1`. Maksimal adalah`2`. Jika dihilangkan, default-nya adalah `1`.
**catatan**
Jika Anda ingin menghilangkan `ApprovalsRequired` properti, hapus `Configuration` bagian gerbang dari file definisi alur kerja.
UI yang sesuai: Tab **konfigurasi/Jumlah persetujuan**
# Mengonfigurasi perilaku antrian run
Secara default di Amazon CodeCatalyst, ketika beberapa alur kerja berjalan terjadi pada saat yang sama, CodeCatalyst mengantri, dan memprosesnya satu per satu, dalam urutan dimulai. Anda dapat mengubah perilaku default ini dengan menentukan *mode run*. Ada beberapa mode lari:
+ (Default) Mode lari antrian — CodeCatalyst proses berjalan satu per satu
+ Mode lari yang digantikan - CodeCatalyst proses berjalan satu per satu, dengan proses yang lebih baru menyalip yang lebih lama
+ Parallel run mode — CodeCatalyst proses berjalan secara paralel
Untuk informasi selengkapnya tentang alur kerja berjalan, lihat[Menjalankan alur kerja](workflows-working-runs.md).
**Topics**
+ [Tentang mode lari antrian](#workflows-configure-runs-queued)
+ [Tentang mode lari yang digantikan](#workflows-configure-runs-superseded)
+ [Tentang mode parallel run](#workflows-configure-runs-parallel)
+ [Mengkonfigurasi mode lari](#workflows-configure-runs-configure)
## Tentang mode lari antrian
Dalam *mode lari antrian*, proses berjalan terjadi secara seri, dengan menunggu berjalan membentuk antrian.
Antrian terbentuk di titik masuk ke tindakan dan grup tindakan, sehingga Anda dapat memiliki *beberapa antrian dalam alur kerja yang sama (lihat*). [Figure 1](#figure-1-workflow-queued-run-mode) Ketika lari antrian memasuki suatu tindakan, tindakan terkunci dan tidak ada jalan lain yang bisa masuk. Ketika run selesai dan keluar dari aksi, aksi menjadi tidak terkunci dan siap untuk menjalankan berikutnya.
[Figure 1](#figure-1-workflow-queued-run-mode)mengilustrasikan alur kerja yang dikonfigurasi dalam mode lari antrian. Ini menunjukkan:
+ Tujuh berjalan bekerja dengan cara mereka melalui alur kerja.
+ Dua antrian: satu di luar entri ke sumber input (**Repo: main**), dan satu di luar entri ke tindakan. **BuildTestActionGroup**
+ Dua blok terkunci: sumber input (**Repo: Main**) dan. **BuildTestActionGroup**
Berikut adalah bagaimana hal-hal akan terjadi saat alur kerja menjalankan pemrosesan selesai:
+ **Ketika **Run-4D444** selesai mengkloning repositori sumber, itu akan keluar dari sumber input dan bergabung dengan antrian di belakang Run-3C333.** Kemudian, **Run-5E555** akan masuk ke sumber input.
+ Ketika **Run-1A111** selesai membangun dan menguji, itu akan keluar dari tindakan dan memasuki tindakan. **BuildTestActionGroup**DeployAction**** Kemudian, **Run-2B222** akan memasuki aksi. **BuildTestActionGroup**
**Gambar 1**: Alur kerja yang dikonfigurasi dalam 'mode lari antrean'
![\[Alur kerja yang dikonfigurasi dalam 'mode lari antrean'\]](http://docs.aws.amazon.com/id_id/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png)
Gunakan mode lari antrian jika:
+ **Anda ingin menjaga one-to-one hubungan antara fitur dan proses — fitur ini dapat dikelompokkan saat menggunakan mode yang diganti.** Misalnya, saat Anda menggabungkan fitur 1 di komit 1, jalankan 1 dimulai, dan saat Anda menggabungkan fitur 2 di komit 2, jalankan 2 dimulai, dan seterusnya. Jika Anda menggunakan mode yang digantikan alih-alih mode antrian, fitur Anda (dan komit) akan dikelompokkan bersama dalam proses yang menggantikan yang lain.
+ **Anda ingin menghindari kondisi balapan dan masalah tak terduga yang mungkin terjadi saat menggunakan mode paralel**. Misalnya, jika dua pengembang perangkat lunak, Wang dan Saanvi, memulai alur kerja berjalan pada waktu yang kira-kira bersamaan untuk menyebarkan ke cluster Amazon ECS, proses Wang mungkin memulai tes integrasi pada cluster sementara menjalankan Saanvi menyebarkan kode aplikasi baru ke cluster, menyebabkan tes Wang gagal atau menguji kode yang salah. Sebagai contoh lain, Anda mungkin memiliki target yang tidak memiliki mekanisme penguncian, dalam hal ini kedua proses dapat menimpa perubahan satu sama lain dengan cara yang tidak terduga.
+ **Anda ingin membatasi beban pada** sumber daya komputasi yang CodeCatalyst digunakan untuk memproses proses Anda. Misalnya, jika Anda memiliki tiga tindakan dalam alur kerja Anda, Anda dapat memiliki maksimum tiga proses yang terjadi pada saat yang sama. Memaksakan batasan pada jumlah run yang dapat terjadi sekaligus membuat throughput run lebih dapat diprediksi.
+ **Anda ingin membatasi jumlah permintaan yang dibuat ke layanan pihak ketiga** berdasarkan alur kerja. Misalnya, alur kerja Anda mungkin memiliki tindakan build yang menyertakan instruksi untuk menarik gambar dari Docker Hub. [Docker Hub membatasi jumlah permintaan tarik](https://www.docker.com/increase-rate-limits) yang dapat Anda buat hingga jumlah tertentu per jam per akun, dan Anda akan dikunci jika melampaui batas. Menggunakan mode lari antrian untuk memperlambat throughput run Anda akan memiliki efek menghasilkan lebih sedikit permintaan ke Docker Hub per jam, sehingga membatasi potensi penguncian dan mengakibatkan kegagalan build dan run.
**Ukuran antrian maksimal**: 50
Catatan tentang **ukuran antrian maksimum**:
+ Ukuran antrian maksimum mengacu pada jumlah maksimum proses yang diizinkan di *semua antrian* dalam alur kerja.
+ Jika antrian menjadi lebih panjang dari 50 run, maka CodeCatalyst turunkan lari ke-51 dan selanjutnya.
**Perilaku kegagalan**:
Jika proses menjadi tidak responsif saat sedang diproses oleh suatu tindakan, maka proses di belakangnya ditahan dalam antrian hingga waktu tindakan habis. Waktu tindakan habis setelah satu jam.
Jika run gagal di dalam suatu tindakan, maka lari antrian pertama di belakangnya diizinkan untuk melanjutkan.
## Tentang mode lari yang digantikan
*Mode lari yang diganti sama dengan mode lari* *antrian kecuali* bahwa:
+ Jika proses antrian mengejar lari lain dalam antrian, proses selanjutnya menggantikan (mengambil alih dari) proses sebelumnya, dan proses sebelumnya dibatalkan dan ditandai sebagai 'digantikan'.
+ Sebagai hasil dari perilaku yang dijelaskan dalam bullet pertama, antrian hanya dapat menyertakan satu run ketika mode run digantikan digunakan.
Menggunakan alur kerja [Figure 1](#figure-1-workflow-queued-run-mode) sebagai panduan, menerapkan mode run yang digantikan ke alur kerja ini akan menghasilkan hal berikut:
+ **Run-7G777** **akan menggantikan dua run lainnya dalam antreannya, dan akan menjadi satu-satunya run yang tersisa di Antrian \$11.** **Run-6F666** **dan Run-5E555 akan dibatalkan.**
+ **Run-3C333** **akan menggantikan **Run-2B222 dan menjadi satu-satunya run yang tersisa di Antrian** \$12.** **Run-2b222** akan dibatalkan.
Gunakan mode lari yang digantikan jika Anda ingin:
+ throughput yang lebih baik daripada dengan mode antrian
+ bahkan lebih sedikit permintaan ke layanan pihak ketiga dibandingkan dengan mode antrian; ini menguntungkan jika layanan pihak ketiga memiliki batas tarif, seperti Docker Hub
## Tentang mode parallel run
Dalam *mode parallel run*, run tidak tergantung satu sama lain dan jangan menunggu proses lain selesai sebelum memulai. Tidak ada antrian, dan run throughput hanya dibatasi oleh seberapa cepat tindakan di dalam alur kerja selesai.
Gunakan mode parallel run di lingkungan pengembangan di mana setiap pengguna memiliki cabang fitur mereka sendiri dan menyebarkan ke target yang tidak dibagikan oleh pengguna lain.
**penting**
Jika Anda memiliki target bersama yang dapat diterapkan oleh beberapa pengguna, seperti fungsi Lambda di lingkungan produksi, jangan gunakan mode paralel, karena kondisi balapan dapat terjadi. *Kondisi balapan* terjadi ketika alur kerja paralel berjalan mencoba mengubah sumber daya bersama pada saat yang sama, yang mengarah ke hasil yang tidak dapat diprediksi.
**Jumlah maksimum parallel run**: 1000 per CodeCatalyst spasi
## Mengkonfigurasi mode lari
Anda dapat mengatur mode lari ke antrian, digantikan, atau paralel. Defaultnya antri.
Saat Anda mengubah mode lari dari antrian atau digantikan menjadi paralel CodeCatalyst , membatalkan proses yang diantrian, dan memungkinkan proses yang saat ini sedang diproses oleh tindakan selesai sebelum membatalkannya.
Ketika Anda mengubah mode run dari parallel ke antrian atau digantikan, memungkinkan CodeCatalyst semua berjalan paralel yang berjalan saat ini selesai. Setiap proses yang Anda mulai setelah mengubah mode run menjadi antrian atau digantikan menggunakan mode baru.
------
#### [ Visual ]
**Untuk mengubah mode lari menggunakan editor visual**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Edit**.
1. Di kanan atas, pilih properti **Workflow**.
1. Perluas **Lanjutan**, dan di bawah **mode Jalankan**, pilih salah satu dari berikut ini:
1. **Antrian — lihat** [Tentang mode lari antrian](#workflows-configure-runs-queued)
1. **Digantikan** — lihat [Tentang mode lari yang digantikan](#workflows-configure-runs-superseded)
1. **Paralel** - lihat [Tentang mode parallel run](#workflows-configure-runs-parallel)
1. (Opsional) Pilih **Validasi** untuk memvalidasi kode YAMAL alur kerja sebelum melakukan.
1. Pilih **Komit**, masukkan pesan komit, dan pilih **Komit** lagi.
------
#### [ YAML ]
**Untuk mengubah mode lari menggunakan editor YAMAL**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Edit**.
1. Pilih **YAMAL.**
1. Tambahkan `RunMode` properti, seperti ini:
```
Name: Workflow_6d39
SchemaVersion: "1.0"
RunMode: QUEUED|SUPERSEDED|PARALLEL
```
Untuk informasi lebih lanjut, lihat deskripsi `RunMode` properti di [Properti tingkat atas](workflow-reference.md#workflow.top.level) bagian[Alur kerja definisi YAMAL](workflow-reference.md).
1. (Opsional) Pilih **Validasi** untuk memvalidasi kode YAMAL alur kerja sebelum melakukan.
1. Pilih **Komit**, masukkan pesan komit, dan pilih **Komit** lagi.
------
# Caching file antara alur kerja berjalan
Saat caching file diaktifkan, tindakan build dan test menyimpan file on-disk ke cache dan mengembalikannya dari cache tersebut dalam alur kerja berikutnya. Caching mengurangi latensi yang disebabkan oleh membangun atau mengunduh dependensi yang tidak berubah di antara proses. CodeCatalyst juga mendukung cache fallback, yang dapat digunakan untuk mengembalikan cache sebagian yang berisi beberapa dependensi yang diperlukan. Ini membantu mengurangi dampak latensi dari kehilangan cache.
**catatan**
Caching file hanya tersedia dengan tindakan CodeCatalyst [pembuatan](build-workflow-actions.md) dan [pengujian](test-workflow-actions.md) Amazon, dan hanya jika file tersebut dikonfigurasi untuk menggunakan jenis **EC2**[komputasi](workflows-working-compute.md#compute.types).
**Topics**
+ [Tentang file caching](#workflows-caching.files)
+ [Membuat cache](#workflows-caching.fallback)
+ [Kendala caching file](#workflows-caching.constraints)
## Tentang file caching
File caching memungkinkan Anda untuk mengatur data Anda ke dalam beberapa cache, yang masing-masing direferensikan di bawah properti. `FileCaching` Setiap cache menyimpan direktori yang ditentukan oleh jalur tertentu. Direktori yang ditentukan akan dipulihkan dalam alur kerja masa depan berjalan. Berikut ini adalah contoh cuplikan YAMAL untuk caching dengan beberapa cache bernama dan. `cacheKey1` `cacheKey2`
```
Actions:
BuildMyNpmApp:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: npm install
- Run: npm run test
Caching:
FileCaching:
cacheKey1:
Path: file1.txt
RestoreKeys:
- restoreKey1
cacheKey2:
Path: /root/repository
RestoreKeys:
- restoreKey2
- restoreKey3
```
**catatan**
CodeCatalyst menggunakan caching berlapis-lapis, yang terdiri dari cache lokal dan cache jarak jauh. Ketika armada yang disediakan atau mesin sesuai permintaan mengalami kehilangan cache pada cache lokal, dependensi akan dipulihkan dari cache jarak jauh. Akibatnya, beberapa tindakan berjalan mungkin mengalami latensi dari mengunduh cache jarak jauh.
CodeCatalyst menerapkan pembatasan akses cache untuk memastikan bahwa tindakan dalam satu alur kerja tidak dapat mengubah cache dari alur kerja yang berbeda. Ini melindungi setiap alur kerja dari orang lain yang mungkin mendorong data yang salah yang memengaruhi build atau penerapan. Pembatasan diberlakukan dengan cakupan cache yang mengisolasi cache ke setiap alur kerja dan pasangan cabang. Misalnya, `workflow-A` di cabang `feature-A` memiliki cache file yang berbeda dari `workflow-A` di cabang `feature-B` saudara.
Kesalahan cache terjadi ketika alur kerja mencari cache file tertentu dan tidak dapat menemukannya. Ini dapat terjadi karena beberapa alasan, seperti ketika cabang baru dibuat atau ketika cache baru direferensikan dan belum dibuat. Ini juga dapat terjadi ketika cache kedaluwarsa, yang secara default terjadi 14 hari setelah terakhir digunakan. Untuk mengurangi kesalahan cache dan meningkatkan tingkat klik cache, CodeCatalyst mendukung cache fallback. Cache fallback adalah cache alternatif dan memberikan kesempatan untuk memulihkan cache sebagian, yang bisa menjadi versi cache yang lebih lama. Cache dipulihkan dengan terlebih dahulu mencari kecocokan di bawah `FileCaching` untuk nama properti, dan jika tidak ditemukan, evaluasi`RestoreKeys`. Jika ada cache yang hilang untuk nama properti dan semua`RestoreKeys`, alur kerja akan terus berjalan, karena caching adalah upaya terbaik dan tidak dijamin.
## Membuat cache
Anda dapat menggunakan petunjuk berikut untuk menambahkan cache ke alur kerja Anda.
------
#### [ Visual ]
**Untuk menambahkan cache menggunakan editor visual**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Edit**.
1. Pilih **Visual**.
1. Dalam diagram alur kerja, pilih tindakan di mana Anda ingin menambahkan cache Anda.
1. Pilih **Konfigurasi**.
1. Di bawah **File caching - opsional**, pilih **Tambahkan cache** dan masukkan informasi ke dalam bidang, sebagai berikut:
**Kunci**
Tentukan nama nama properti cache utama Anda. Nama properti cache harus unik dalam alur kerja Anda. Setiap tindakan dapat memiliki hingga lima entri. `FileCaching`
**Jalan**
Tentukan jalur terkait untuk cache Anda.
**Kembalikan kunci - opsional**
Tentukan kunci pemulihan yang akan digunakan sebagai fallback ketika properti cache utama tidak dapat ditemukan. Kembalikan nama kunci harus unik dalam alur kerja Anda. Setiap cache dapat memiliki hingga lima entri. `RestoreKeys`
1. (Opsional) Pilih **Validasi** untuk memvalidasi kode YAMM alur kerja sebelum melakukan.
1. Pilih **Komit**, masukkan pesan komit, lalu pilih **Komit** lagi.
------
#### [ YAML ]
**Untuk menambahkan cache menggunakan editor YAMM**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Pilih **Edit**.
1. Pilih **YAMAL.**
1. Dalam tindakan alur kerja, tambahkan kode yang mirip dengan berikut ini:
```
action-name:
Configuration:
Steps: ...
Caching:
FileCaching:
key-name:
Path: file-path
# # Specify any additional fallback caches
# RestoreKeys:
# - restore-key
```
1. (Opsional) Pilih **Validasi** untuk memvalidasi kode YAMM alur kerja sebelum melakukan.
1. Pilih **Komit**, masukkan pesan komit, dan pilih **Komit** lagi.
------
## Kendala caching file
Berikut ini adalah kendala untuk nama properti dan: `RestoreKeys`
+ Nama harus unik dalam alur kerja.
+ Nama terbatas pada karakter alfanumerik (A-Z, a-z, 0-9), tanda hubung (-), dan garis bawah (\$1).
+ Nama dapat memiliki hingga 180 karakter.
+ Setiap tindakan dapat memiliki hingga lima cache. `FileCaching`
+ Setiap cache dapat memiliki hingga lima entri. `RestoreKeys`
Berikut ini adalah kendala untuk jalur:
+ Tanda bintang (\$1) tidak diperbolehkan.
+ Jalur dapat memiliki hingga 255 karakter.
# Melihat status dan detail alur kerja
Di Amazon CodeCatalyst, Anda dapat melihat status dan detail dari satu alur kerja yang dijalankan, atau beberapa proses secara bersamaan.
Untuk daftar kemungkinan status jalankan lihat[Alur kerja menjalankan status](workflows-view-run-status.md).
**catatan**
Anda juga dapat melihat status alur kerja, yang berbeda dari status *menjalankan* alur kerja. Untuk informasi selengkapnya, lihat [Melihat status alur kerja](workflows-view-status.md).
Untuk informasi selengkapnya tentang alur kerja berjalan, lihat[Menjalankan alur kerja](workflows-working-runs.md).
**Topics**
+ [Melihat status dan detail dari satu run](#workflows-view-run-single)
+ [Melihat status dan detail semua proses dalam proyek Anda](#workflows-view-run-all)
+ [Melihat status dan detail semua proses alur kerja tertentu](#workflows-view-run-wf)
+ [Melihat alur kerja dalam diagram alur kerja](#workflows-view-run-wf-diagram)
## Melihat status dan detail dari satu run
Anda mungkin ingin melihat status dan detail alur kerja tunggal untuk memeriksa apakah itu berhasil, untuk melihat pada jam berapa selesai, atau untuk melihat siapa atau apa yang memulainya.
**Untuk melihat status dan detail dari satu run**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Di bawah nama alur kerja, pilih **Runs**.
1. Di **Riwayat Jalankan****, di kolom Run ID**, pilih run. Misalnya, `Run-95a4d`.
1. Di bawah nama run, lakukan salah satu hal berikut:
+ **Visual** untuk melihat diagram alur kerja yang menunjukkan tindakan alur kerja dan statusnya (lihat[Alur kerja menjalankan status](workflows-view-run-status.md)). Tampilan ini juga menunjukkan repositori sumber dan cabang yang digunakan selama menjalankan.
Dalam diagram alur kerja, pilih tindakan untuk melihat detail seperti log, laporan, dan output yang dihasilkan oleh tindakan selama menjalankan. Informasi yang ditampilkan tergantung pada jenis tindakan yang dipilih. Untuk informasi selengkapnya tentang melihat log build atau deploy, lihat [Melihat hasil tindakan build](build-view-results.md) atau[Melihat log penerapan](deploy-deployment-logs.md).
+ **YAMM** untuk melihat file definisi alur kerja yang digunakan untuk menjalankan.
+ **Artefak** untuk melihat artefak yang dihasilkan oleh alur kerja dijalankan. Untuk informasi lebih lanjut tentang artifact, lihat [Berbagi artefak dan file antar tindakan](workflows-working-artifacts.md).
+ **Laporan** untuk melihat laporan pengujian dan jenis laporan lain yang dihasilkan oleh alur kerja yang dijalankan. Untuk informasi selengkapnya tentang laporan, lihat[Jenis laporan kualitas](test-workflow-actions.md#test-reporting).
+ **Variabel** untuk melihat variabel output yang dihasilkan oleh alur kerja yang dijalankan. Untuk informasi lebih lanjut tentang variabel, lihat[Menggunakan variabel dalam alur kerja](workflows-working-with-variables.md).
**catatan**
Jika alur kerja induk run telah dihapus, pesan yang menunjukkan fakta ini akan muncul di bagian atas halaman rincian proses.
## Melihat status dan detail semua proses dalam proyek Anda
Anda mungkin ingin melihat status dan detail dari semua alur kerja yang berjalan dalam proyek Anda memahami berapa banyak aktivitas alur kerja yang terjadi dalam proyek Anda, dan mempelajari tentang kesehatan keseluruhan alur kerja Anda.
**Untuk melihat status dan detail semua proses dalam proyek Anda**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Di bawah **Alur kerja**, pilih **Runs**.
Semua proses, untuk semua alur kerja, di semua cabang, di semua repositori dalam proyek Anda, ditampilkan.
Halaman ini mencakup kolom berikut:
+ **Run ID** — Pengidentifikasi unik dari proses. Pilih tautan run ID untuk melihat informasi terperinci tentang proses.
+ **Status** - Status pemrosesan alur kerja yang dijalankan. Untuk informasi selengkapnya tentang status run, lihat[Alur kerja menjalankan status](workflows-view-run-status.md).
+ **Trigger** — Orang, commit, pull request (PR), atau jadwal yang memulai alur kerja berjalan. Untuk informasi selengkapnya, lihat [Memulai alur kerja berjalan secara otomatis menggunakan pemicu](workflows-add-trigger.md).
+ **Alur kerja** - Nama alur kerja tempat proses dimulai, dan repositori sumber dan cabang tempat file definisi alur kerja berada. Anda mungkin perlu memperluas lebar kolom untuk melihat informasi ini.
**catatan**
Jika kolom ini disetel ke **Tidak tersedia**, biasanya karena alur kerja terkait telah dihapus atau dipindahkan.
+ **Waktu mulai** — Waktu ketika alur kerja berjalan dimulai.
+ **Durasi** - Berapa lama alur kerja berjalan untuk diproses. Durasi yang sangat panjang atau sangat singkat mungkin mengindikasikan masalah.
+ **Waktu akhir** - Waktu ketika alur kerja berjalan berakhir.
## Melihat status dan detail semua proses alur kerja tertentu
Anda mungkin ingin melihat status dan detail semua proses yang terkait dengan alur kerja tertentu untuk melihat apakah ada proses yang membuat hambatan dalam alur kerja, atau untuk melihat proses mana yang sedang berlangsung atau telah selesai.
**Untuk melihat status dan detail semua proses alur kerja tertentu**
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
1. Di bawah nama alur kerja, pilih **Runs**.
Jalankan yang terkait dengan alur kerja yang dipilih muncul.
Halaman ini dibagi menjadi dua bagian:
+ **Aktif berjalan** - Menampilkan berjalan yang sedang berlangsung. Lari ini akan berada di salah satu status berikut: **Sedang berlangsung**.
+ **Run history** - Menampilkan run yang telah selesai (yaitu, tidak sedang berlangsung).
Untuk informasi selengkapnya tentang status run, lihat[Alur kerja menjalankan status](workflows-view-run-status.md).
## Melihat alur kerja dalam diagram alur kerja
Anda dapat melihat status semua proses alur kerja saat mereka maju bersama melalui alur kerja. Jalankan ditampilkan dalam diagram alur kerja (sebagai lawan dari dalam tampilan daftar). Ini memberi Anda representasi visual dari proses mana yang sedang diproses oleh tindakan mana, dan lari mana yang menunggu dalam antrian.
**Untuk melihat status beberapa proses saat mereka maju bersama melalui alur kerja**
**catatan**
Prosedur ini hanya berlaku jika alur kerja Anda menggunakan mode lari antrian atau digantikan. Untuk informasi selengkapnya, lihat [Mengonfigurasi perilaku antrian run](workflows-configure-runs.md).
1. Buka CodeCatalyst konsol di [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Pilih proyek Anda.
1. **Di panel navigasi, pilih **CI/CD, lalu pilih Alur** kerja.**
1. Pilih nama alur kerja Anda. Anda dapat memfilter berdasarkan repositori sumber atau nama cabang tempat alur kerja ditentukan, atau memfilter berdasarkan nama atau status alur kerja.
**catatan**
Pastikan Anda melihat halaman alur kerja dan bukan halaman run.
1. Pilih tab **Status terbaru** di kiri atas.
Diagram alur kerja muncul.
1. Tinjau diagram alur kerja. Diagram menunjukkan semua proses yang sedang berlangsung dalam alur kerja, dan proses terbaru yang telah selesai. Lebih khusus lagi:
+ Lari yang muncul di bagian atas, sebelum **Sumber**, antri dan menunggu untuk memulai.
+ Jalankan yang muncul di antara tindakan diantrian dan menunggu untuk diproses oleh tindakan berikutnya.
+ Runs yang muncul dalam suatu tindakan adalah 1. saat ini sedang diproses oleh tindakan, 2. telah selesai diproses oleh tindakan, atau 3. tidak diproses oleh tindakan (biasanya karena tindakan sebelumnya gagal).