Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Berikut adalah beberapa fitur yang dapat Anda temukan di sebagian besar sistem CI.
Lingkungan
Penting untuk memilih dan memahami lingkungan hardware dan software tempat
sistem menjalankan alur kerja. Pertimbangan penting untuk aplikasi
Android adalah:
Platform: Linux, Mac, Windows, dan versinya.
Memori yang tersedia: Mem-build aplikasi dan menjalankan emulator dapat menggunakan banyak
RAM, dan sering kali parameter seperti ukuran heap JVM perlu disesuaikan untuk
menghindari error kehabisan memori.
Software bawaan: Sistem CI biasanya menyediakan image dengan sejumlah besar alat yang sudah tersedia, seperti Java Development Kit (JDK), Android Software Development Kit (SDK), alat build, platform, dan emulator.
Arsitektur runner dan kumpulan petunjuk: ARM, x86. Hal ini penting saat
menggunakan emulator.
Variabel lingkungan: Beberapa variabel ditetapkan oleh sistem CI (misalnya:
ANDROID_HOME) dan Anda dapat menetapkannya sendiri untuk, misalnya, menghindari kredensial
hardcode di alur kerja Anda.
Ada banyak aspek lain yang harus Anda pertimbangkan, seperti jumlah core
yang tersedia dan apakah virtualisasi diaktifkan untuk menjalankan emulator.
Log dan laporan
Jika ada langkah yang gagal, sistem CI akan memberi tahu Anda dan biasanya tidak mengizinkan Anda menggabungkan
perubahan. Untuk mengetahui apa yang salah, cari kesalahan di log.
Selain itu, pembuatan dan pengujian akan menghasilkan laporan yang biasanya disimpan sebagai
artefak dari build tertentu tersebut. Bergantung pada sistem CI, Anda dapat menggunakan
plugin untuk memvisualisasikan hasil laporan tersebut.
Waktu proses cache dan CI
Sistem CI menggunakan cache build untuk mempercepat prosesnya. Dalam bentuknya yang paling sederhana, mereka
menyimpan semua file cache Gradle setelah build berhasil dan memulihkannya sebelum
yang baru. Hal ini bergantung pada fitur cache build Gradle dan harus
diaktifkan di project Anda.
Beberapa cara untuk meningkatkan waktu proses dan keandalan meliputi:
Modul: Mendeteksi modul mana yang terpengaruh oleh perubahan dan hanya
mem-build dan mengujinya.
Lewati cache: Jika build menyertakan skrip yang telah diubah developer,
abaikan cache build. Lebih aman untuk membangun dari awal.
Pengujian shard: Pengujian sharding khusus berinstrumen, dan dapat berguna untuk melakukan sharding
pengujian di beberapa perangkat. Dukungan ini didukung oleh runner Android, Perangkat yang Dikelola Gradle, dan Firebase Test Lab.
Build shard: Anda dapat melakukan sharding build di beberapa instance server.
Kelemahan mengacu pada pengujian atau alat yang gagal sesekali. Anda harus selalu
mencoba menemukan dan memperbaiki masalah yang menghasilkan build dan pengujian yang tidak stabil, tetapi beberapa
di antaranya sulit direproduksi, terutama saat menjalankan pengujian berinstrumen.
Strategi yang biasa digunakan adalah mencoba kembali pengujian setiap kali gagal, hingga jumlah maksimum
percobaan ulang gagal.
Tidak ada satu cara untuk mengonfigurasi percobaan ulang karena hal ini dapat terjadi di beberapa
level. Tabel berikut menguraikan tindakan yang dapat Anda lakukan sebagai respons terhadap
kegagalan uji yang tidak stabil:
Gagal
Tindakan
Emulator tidak responsif selama satu detik, sehingga memicu waktu tunggu
Menjalankan kembali pengujian yang gagal
Emulator gagal di-booting
Jalankan kembali seluruh tugas
Ada error koneksi selama fase checkout kode
Mulai ulang alur kerja
Penting untuk mencatat dan melacak bagian sistem yang tidak stabil dan berinvestasi dalam menjaga CI yang andal dan cepat, dengan hanya mengandalkan percobaan ulang
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-27 UTC."],[],[],null,["# CI features\n\nThe following are some features that you can find in most CI systems.\n\nEnvironment\n-----------\n\nIt's important to choose and understand the hardware and software environment in\nwhich the system executes the workflow. Important considerations for Android\napplications are:\n\n- **Platform**: Linux, Mac, Windows, and their versions.\n- **Available memory**: Building apps and running emulators can use a lot of RAM and it's often necessary to tweak parameters such as the JVM's heap size to avoid out-of-memory errors.\n- **Preinstalled software**: CI systems usually provide images with a large collection of tools already available, such as the Java Development Kit (JDK), the Android Software Development Kit (SDK), build tools, platforms and emulators.\n- **Runner architecture and instruction set**: ARM, x86. This is important when using emulators.\n- **Environment variables** : Some are set by the CI system (for example: `ANDROID_HOME`) and you can set your own to, for example, avoid hardcoding credentials in your workflow.\n\nThere are many other aspects you should consider, such as the number of cores\navailable, and whether virtualization is enabled to run emulators.\n\nLogs and reports\n----------------\n\nWhen a step fails, the CI system notifies you and usually doesn't let you merge\nthe change. To find out what has gone wrong, look for errors in the logs.\n\nAdditionally, building and testing generates reports that are usually stored as\nartifacts of that particular build. Depending on the CI system, you can use\nplugins to visualize the results of those reports.\n\nCache and CI run times\n----------------------\n\nCI systems use a build cache to speed up the process. In its simplest form, they\nsave all the Gradle cache files after a successful build and restore them before\na new one. This relies on [Gradle's build cache](https://docs.gradle.org/current/userguide/build_cache.html) feature and should be\nenabled in your project.\n| **Note:** take into account the time that it takes for the cache to download as, if the cache becomes too big and it contains more than is necessary, it could be detrimental to the overall build time.\n\nSome ways to improve run times and reliability include:\n\n- **Modules**: Detecting which modules are affected by a change and only building and testing those.\n- **Skip caches**: If the build includes scripts that a developer has modified, ignore the build caches. It's safer to build from scratch.\n- **Shard tests**: Especially instrumented tests, it can be helpful to shard tests across multiple devices. This is supported by the Android runner, Gradle Managed Devices and Firebase Test Lab.\n- **Shard builds**: You can shard the build across multiple server instances.\n- **Remote cache** : You can also use [Gradle's remote cache](https://docs.gradle.org/current/userguide/build_cache.html).\n\nRetry failed tests\n------------------\n\nFlakiness refers to tests or tools that fail intermittently. You should always\ntry to find and fix the problems that generate flaky builds and tests, but some\nof them are difficult to reproduce, especially when running instrumented tests.\nA common strategy is to retry test runs whenever they fail, up to a maximum\nnumber of retries.\n\nThere is no single way to configure retries, as they can occur at multiple\nlevels. The following table outlines the action you might take in response to a\nflaky test failure:\n\n| Failure | Action |\n|--------------------------------------------------------------|-----------------------|\n| Emulator was unresponsive for a second, triggering a timeout | Rerun the failed test |\n| Emulator failed to boot | Rerun the whole task |\n| There was a connection error during the code checkout phase | Restart the workflow |\n\nIt's important to log and keep track of which parts of the system are flaky and\ninvest in keeping CI reliable and fast, only relying on retries"]]