Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Memecahkan masalah error build dan lainnya

Halaman ini menyediakan strategi pemecahan masalah serta solusi untuk beberapa pesan error umum yang mungkin Anda lihat saat menjalankan build.

Apakah Anda melihat log build?

Gunakan log build Logging atau Cloud Storage untuk mendapatkan informasi selengkapnya tentang error build. Log yang ditulis ke stdout atau stderr dapat dilihat menggunakan Google Cloud konsol dan gcloud CLI.

Build manual gagal karena pengguna tidak memiliki akses ke log build

Anda melihat error berikut saat mencoba menjalankan a build secara manual:

AccessDeniedAccess denied. [EMAIL_ADDRESS] does not have storage.objects.get access to the Google Cloud Storage object.

Anda melihat error ini karena Cloud Build mengharuskan pengguna yang menjalankan build manual dan menggunakan bucket log Cloud Storage default memiliki peran IAM Project Viewer selain peran Cloud Build Editor. Untuk mengatasi error ini, Anda dapat melakukan salah satu tindakan berikut:

Gunakan bucket log default, dan berikan peran Project Viewer dan peran Cloud Build Editor kepada pengguna yang menjalankan build. Untuk mengetahui petunjuk cara memberikan izin ini, lihat Mengonfigurasi akses ke resource Cloud Build.
Buat bucket Cloud Storage Anda sendiri untuk menyimpan log. Untuk mengetahui petunjuknya, lihat Menyimpan log build di bucket yang dibuat pengguna.

Build gagal karena izin `iam.serviceAccounts.actAs` tidak ada

Anda melihat error berikut saat mencoba men-deploy build menggunakan layanan terkelola seperti Cloud Run atau App Engine:

Missing necessary permission iam.serviceAccounts.actAs for [USER] on the service account [SERVICE ACCOUNT]

Untuk mengatasi error ini, konfigurasikan akun layanan Cloud Build yang Anda tentukan atau akun layanan Cloud Build default untuk meniru identitas akun layanan dari layanan terkelola yang Anda gunakan untuk build. Untuk mengetahui informasi selengkapnya tentang tugas ini, lihat Mengonfigurasi peniruan akun layanan Cloud Build untuk layanan terkelola.

Untuk mengetahui informasi tambahan tentang akun layanan dan izin, lihat topik berikut:

Error izin ditolak saat men-deploy di Cloud Run Functions

Anda melihat error berikut saat mencoba menggunakan Cloud Run Functions:

ResponseError: status=[403], code=[Ok], message=[Permission 'cloudfunctions.functions.get' denied]

Untuk mengatasi error ini, berikan peran Developer Cloud Run Functions ke akun layanan build Anda.

Pemicu build gagal karena izin `cloudbuild.builds.create` tidak ada

Anda melihat error seperti berikut saat menjalankan pemicu build:

Failed to trigger build: Permission 'cloudbuild.builds.create' denied on resource 'projects/xxxxxxxx' (or it may not exist)

Pemicu build menggunakan akun layanan untuk membuat build. Error ini menunjukkan bahwa akun layanan tidak memiliki izin IAM cloudbuild.builds.create, yang diperlukan agar akun layanan dapat menjalankan pemicu build. Anda dapat mengatasi error ini dengan memberikan peran Cloud Build Service Account IAM ke akun layanan yang ditentukan pengguna atau akun layanan default.

Pengiriman build gagal karena izin agen layanan tidak ada

Jika agen layanan Cloud Build dihapus atau tidak memiliki izin, hal ini dapat menyebabkan error berikut saat mengirimkan build.

Caller does not have required permission to use project $PROJECT_ID. Grant the caller the roles/serviceusage.serviceUsageConsumer role, or a custom role with the serviceusage.services.use permission, by visiting https://console.developers.google.com/iam-admin/iam/project?project=$PROJECT_ID and then retry. Propagation of the new permission may take a few minutes.

Penelepon dalam skenario ini adalah agen layanan Cloud Build. Untuk mengatasi masalah izin ini, ikuti langkah-langkah berikut:

Pastikan agen layanan Cloud Build ada. Anda dapat melihat agen layanan untuk project dengan membuka halaman IAM di Google Cloud konsol dan mencentang kotak Tampilkan akun layanan terkelola Google. Jika tidak ada, Anda dapat membuatnya dengan menjalankan perintah gcloud CLI berikut:
```
gcloud beta services identity create --service=cloudbuild.googleapis.com \
    --project=PROJECT_ID
```

Selanjutnya, berikan peran IAM roles/cloudbuild.serviceAgent ke agen layanan Cloud Build:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com" \
    --role="roles/cloudbuild.serviceAgent"

Jika Anda ingin memverifikasi identitas IAM mana yang berpotensi bertanggung jawab untuk mendorong masalah izin agen layanan, ikuti langkah-langkah berikut:

Buka Logs Explorer di Google Cloud konsol:

Buka Logs Explorer

Masukkan teks berikut di kolom kueri:

resource.type="project"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"
"service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com"

Jika Anda melihat entri log setelah menggunakan kueri ini, periksa apakah ada entri yang menghapus izin dari agen layanan (service-PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com). Jika ada, lihat protoPayload.authenticationInfo.principalEmail di log tersebut untuk menentukan identitas IAM yang bertanggung jawab untuk menghapus izin atau peran roles/cloudbuild.serviceAgent yang berisi izin yang tercantum dalam pesan error.

Pemicu gagal dengan error `Couldn't read commit`

Anda melihat error berikut saat menjalankan pemicu build:

  Failed to trigger build: Couldn't read commit

Cloud Build menampilkan pesan ini jika Anda mencoba memicu build menggunakan cabang yang tidak ada. Tinjau nama direktori Anda untuk mengetahui ejaan dan konsistensi. Untuk mengetahui petunjuk tentang penyiapan pemicu, lihat Membuat dan mengelola pemicu build.

Tidak dapat membuat pemicu Pub/Sub

Anda melihat error berikut saat membuat pemicu Pub/Sub:

  Failed to create trigger: Request is prohibited by organization's policy

Error ini menunjukkan bahwa Pub/Sub API dibatasi di project Anda. Project yang membatasi Pub/Sub API membatasi kemampuan untuk membuat Langganan Push. Anda dapat menghapus Pub/Sub sementara dari layanan yang dibatasi di perimeter Anda, membuat pemicu, dan membatasi Pub/Sub API lagi untuk mengatasi error tersebut.

Tidak dapat Mengambil atau Mengambil cabang dari repositori pribadi karena error: `fatal: could not read Username`

Anda melihat error berikut saat mencoba melakukan git pull atau git fetch di cabang jarak jauh dari repositori pribadi:

fatal: could not read Username for '<REMOTE_URL>': No such device or address

Error ini diharapkan terjadi di repositori pribadi, karena helper kredensial git sengaja dihapus setelah kloning awal repositori. Untuk mengambil cabang jarak jauh dari repositori pribadi, siapkan kredensial otorisasi (Token API, Kunci SSH) secara manual sebagai langkah build. Pelajari lebih lanjut cara mengakses repositori GitHub pribadi.

Build gagal karena otorisasi ssh tidak valid

Anda melihat error berikut saat menjalankan build:

Could not parse ssh: [default]: invalid empty ssh-agent socket, make sure SSH_AUTH_SOCK is set

Error ini menunjukkan masalah dengan otorisasi SSH. Contoh umumnya adalah error otorisasi SSH yang terjadi saat mengakses repositori GitHub pribadi dengan Cloud Build. Untuk mengetahui petunjuk cara menyiapkan SSH untuk GitHub, lihat Mengakses repositori GitHub pribadi.

Build gagal karena error `No route to host`

Anda melihat error berikut atau yang serupa saat menjalankan build di pool pribadi:

Unable to connect to the server: dial tcp 192.168.10.XX:<port>: connect: no route to host

Cloud Build menjalankan Cloud builder-nya di mesin virtual dalam project yang dikelola Google menggunakan container Docker. Antarmuka bridge Docker (dan akibatnya container yang terhubung ke antarmuka ini) diberi rentang IP 192.168.10.0/24, yang membuat komunikasi dengan host eksternal di subnet yang sama menjadi tidak mungkin. Saat mengalokasikan rentang IP untuk resource di project Anda selama konfigurasi pool pribadi, sebaiknya pilih rentang di luar 192.168.10.0/24. Untuk mengetahui petunjuknya, lihat Menyiapkan lingkungan untuk pool pribadi.

Build gagal dengan pesan error: "Expired", dan tidak menampilkan log apa pun

Anda memicu atau mengirimkan build dan build tersebut gagal, menampilkan error "Expired", dan tidak ada log yang dibuat.

Periksa hal berikut dalam konfigurasi Anda:

Anda telah mengonfigurasi nilai queueTtl yang lebih rendah (misalnya, 20 detik).

Tingkatkan nilai dalam skema Anda dan jalankan build lagi. Lihat queueTtl untuk mengetahui informasi selengkapnya.
Anda telah mencapai kuota untuk build serentak.

Anda dapat meminta peningkatan melalui halaman Kuota di Google Cloud konsol. Untuk mengetahui detail selengkapnya, lihat Kuota dan Batas.
Anda menggunakan pool pribadi dan telah memilih mesin non-default.

Build mungkin memerlukan waktu lebih lama untuk dimulai karena mungkin perlu menunggu mesin virtual baru dimulai. Lihat Jenis mesin untuk mengetahui informasi selengkapnya.

Anda dapat mencoba mengubah jenis mesin.
Anda menggunakan pool pribadi dan telah menentukan rentang IP untuk pool tersebut.

Rentang IP fisik menentukan jumlah VM pekerja di pool, dan dengan demikian menentukan batas build serentak, meskipun lebih rendah dari kuota Build Serentak. Build diantrekan jika tidak ada VM pekerja yang tersedia di pool.

Hal ini terjadi saat alamat IP yang tersedia dalam subnet yang ditentukan digunakan sepenuhnya, sehingga tidak ada alamat untuk dialokasikan oleh pekerja Cloud Build baru. Coba tingkatkan rentang di subnet dan jalankan kembali build.

Koneksi ke resource eksternal gagal karena tidak ada IP eksternal yang diaktifkan

Anda melihat error berikut saat menghubungkan ke resource eksternal dari pool pribadi:

 Failed to connect to <external_domain>: Connection timed out

Pool pribadi menggunakan IP eksternal untuk mengakses resource di internet publik, seperti repositori eksternal. Saat membuat atau memperbarui pool pribadi, centang kotak untuk menetapkan IP eksternal ke pool pribadi Anda. Untuk mengetahui petunjuk cara Membuat atau memperbarui kolom dalam pool pribadi, lihat Membuat dan mengelola pool pribadi.

Error waktu tunggu I/O habis

Anda melihat error berikut saat menjalankan build:

Timeout - last error: dial tcp IP_ADDRESS: i/o timeout

Error ini dapat terjadi saat build Anda mencoba mengakses resource di jaringan pribadi, tetapi gagal. Secara default, build yang dijalankan menggunakan Cloud Build dapat mengakses resource pribadi di internet publik seperti resource di repositori atau registry. Namun, build hanya dapat mengakses resource di jaringan pribadi jika Anda menggunakan pool pribadi dan mengonfigurasinya untuk mengakses jaringan pribadi. Lihat Menggunakan Cloud Build di jaringan pribadi.

Error klien 4xx

Grup error ini menunjukkan bahwa permintaan build tidak berhasil, kemungkinan karena kesalahan pengguna yang mengirimkan permintaan. Beberapa contoh error klien 4xx adalah:

**Error**: 404 : Requested entity was not found
**Error**: 404 : Trigger not found
**Error**: 400 : Failed Precondition
**Error**: 403 : Permission denied

Saat melihat error klien 4xx, lihat log build Anda untuk melihat apakah log tersebut berisi informasi selengkapnya tentang alasan error. Beberapa penyebab umum error klien mencakup:

Lokasi sumber yang Anda tentukan tidak memiliki hal baru untuk di-commit dan pohon kerja bersih. Dalam hal ini, periksa lokasi kode sumber Anda dan coba build lagi.
Repositori Anda tidak berisi file konfigurasi build. Jika demikian, upload file konfigurasi build ke repositori Anda dan jalankan build lagi.
Anda telah menentukan ID pemicu yang salah.
Anda baru-baru ini menambahkan repositori baru setelah menginstal aplikasi GitHub, dan Cloud Build tidak memiliki izin untuk mengakses repositori baru. Jika demikian, hubungkan repositori baru Anda ke Cloud Build.
Anda perlu memberikan izin lain ke akun layanan build Anda.

Build gagal karena batasan kuota

Anda melihat error berikut yang menunjukkan bahwa build gagal karena batasan kuota di region tertentu:

Failed to trigger build: generic::failed_precondition: due to quota restrictions, cannot run builds in this region. Please contact support.

Hubungi Cloud Customer Care untuk meningkatkan kuota Anda untuk region tertentu ini.

Masalah waktu tunggu habis saat mengambil image dari registry Docker

Anda melihat error waktu tunggu habis berikut di log Cloud Build setelah menjalankan build:

Step #0: Pulling image: python:3.8.16-alpine3.17
Step #0: Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Step 1/7 : FROM python:3.8.16-alpine3.17
Get "https://registry-1.docker.io/v2/": dial tcp 34.205.13.154:443: i/o timeout

Untuk mengatasi error ini, download image Docker menggunakan crane dan lanjutkan untuk memuat image ke image Docker Cloud Build.

Tambahkan cuplikan berikut ke file cloudbuild.yaml Anda.

...
  # Crane runs as a regular user so we need to allow it to access the directory where it saves the image.
  - name: gcr.io/cloud-builders/docker
    args:
    - a+w
    - /workspace
    entrypoint: chmod
  # Use crane to download the image through the proxy
  - name: gcr.io/go-containerregistry/crane
    env: - 'HTTPS_PROXY=HTTPS_PROXY'
    args:
    - pull
    - 'python:3.8.16-alpine3.17'
    - /workspace/image.tar
  # Use docker load to add the image into the local Cloud Build registry
  - name: gcr.io/cloud-builders/docker
    args: [load, --input, "/workspace/image.tar"]
      - .

HTTPS_PROXY: Alamat proxy HTTP Anda (misalnya, https://proxy.example.com:8888/).

Setelah image dimuat, langkah-langkah cloudbuid.yaml yang ada akan berfungsi seperti biasa, misalnya sebagai berikut:

...
  - name: python:3.8.16-alpine3.17
    args:
    - echo
    - hello
    entrypoint: bash
  # Or use it internally on a Dockerfile
  - name: gcr.io/cloud-builders/docker
    args:
    - build

Error `Unauthenticated` untuk langkah Docker yang berjalan lama

Langkah-langkah build yang melibatkan perintah Docker yang berjalan selama lebih dari satu jam (seperti mengirim image besar ke Artifact Registry) dapat gagal dengan error autentikasi. Cloud Build memperbarui token autentikasi setiap jam, tetapi Docker mungkin gagal mengambil token baru ini sehingga menyebabkan masalah autentikasi. Anda dapat menulis token Anda sendiri dengan masa aktif kustom ke file dan mereferensikannya untuk perintah Docker.

Build yang diantrekan di pool pribadi yang di-peering ke jaringan VPC

Saat Anda menjalankan build di pool pribadi yang jaringan produsen layanannya di-peering ke jaringan VPC Anda sendiri, penting untuk memastikan koneksi pribadi antara kedua jaringan ini tetap utuh. Jika Anda menghapus koneksi pribadi yang diandalkan oleh pool pribadi, Anda dapat merusak pool pribadi tersebut. Hal ini dapat muncul sebagai build yang tetap diantrekan hingga akhirnya waktu tunggu habis. Oleh karena itu, jika Anda ingin menghapus koneksi pribadi, pastikan Anda juga menghapus pool pribadi yang jaringan produsen layanannya terhubung ke jaringan VPC Anda sendiri menggunakan koneksi pribadi ini.

Mencoba menyetujui atau menolak build yang tertunda yang lebih lama dari 2 bulan

Anda tidak dapat menyetujui atau menolak build yang tertunda yang lebih lama dari 2 bulan. Mencoba melakukannya dapat menghasilkan pesan error yang terlihat seperti ini:

 404, "message": "Requested entity was not
found.", "status": "NOT_FOUND" } }

Jika hal ini terjadi, coba kirimkan build baru.

Gagal membuat pool pribadi: Pool pekerja tidak di-peering ke Service Networking API

Anda mencoba membuat pool pribadi. Namun, Anda menerima pesan error berikut:

Failed to create private pool private-worker-pool: generic::failed_precondition: network "projects/PROJECT_NAME/global/networks/vpc-scmdev-lab-vpc" is not peered to the Service Networking API; please check your configuration and the documentation for troubleshooting and setting up your pool

Agar build dapat mengakses resource pribadi dari jaringan Virtual Private Cloud, Anda harus menyiapkan koneksi peering antara jaringan Virtual Private Cloud dan jaringan Virtual Private Cloud tempat pool pribadi berada. Untuk mengetahui petunjuknya, lihat Menyiapkan koneksi pribadi antara jaringan VPC Anda dan jaringan produsen layanan.

Gagal membuat pool pribadi: tidak dapat mengakses konfigurasi peered_network

Jika Anda menggunakan VPC Bersama atau sebelumnya telah menghapus agen layanan Service Networking, pembuatan pool pribadi mungkin gagal dengan error yang mirip dengan berikut ini:

generic::permission_denied: cannot access peered_network config.

Untuk memperbaiki masalah ini, pastikan agen layanan Service Networking (service-PROJECT_NUMBER@service-networking.iam.gserviceaccount.com) ada di project layanan Anda dan memiliki izin yang diperlukan.

Buat akun layanan jika tidak ada:

gcloud beta services identity create \
    --service=servicenetworking.googleapis.com \
    --project=PROJECT_ID

Berikan peran roles/servicenetworking.serviceAgent yang diperlukan ke akun layanan:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@service-networking.iam.gserviceaccount.com" \
    --role="roles/servicenetworking.serviceAgent"

Langkah berikutnya

Pelajari cara mengelola log build.

Log build muncul tidak berurutan

Anda menjalankan langkah-langkah build yang menghasilkan log dan Anda melihat bahwa log stderr (error) muncul di UI sebelum log stdout (output standar) yang sesuai. Log muncul secara kronologis tidak berurutan.

Pengurutan ini adalah perilaku buffering stream Linux dan Docker standar. Saat kode berjalan di lingkungan non-TTY, seperti container build, stdout akan di-buffer blok (ditunda hingga buffer terisi), sedangkan stderr tetap tidak di-buffer (langsung dicetak).

Untuk melewati metode pengurutan ini dan menjamin pengurutan log yang ketat, Anda harus menonaktifkan buffering secara eksplisit di lingkungan eksekusi langkah build Anda.

Python: Tetapkan variabel lingkungan PYTHONUNBUFFERED: yaml steps: - name: 'python:3' env: ['PYTHONUNBUFFERED=1'] script: | python main.py

Skrip C/C++ dan Bash: Gunakan perintah stdbuf untuk memaksa buffering baris: yaml steps: - name: 'ubuntu' script: | stdbuf -oL ./your_binary

Java: Java tidak secara native mendukung penonaktifan buffering menggunakan flag, tetapi Anda dapat memaksa flush langsung dalam kode setelah pernyataan log penting: java System.out.println("Log message"); System.out.flush();