Yarn: "Integritas salah saat mengambil dari cache"

Penguatan cek integrity yang diperkenalkan di #7582 tampaknya memunculkan masalah. Sebagai perbaikan sementara, saya mengomentari kode melakukan pemeriksaan integrity .

Dugaan saya adalah bahwa untuk beberapa paket, sementara file yarn.lock lokal mungkin berisi integrity , catatan pada registri jarak jauh mungkin tidak. Dalam kasus saya, ini [email protected] .

Semoga @arcanis dapat membantu membagikan beberapa saran untuk menyelesaikan masalah @~@

@xclidongbo Tolong beri judul ulang masalah untuk mencerminkan kesalahan yang dilemparkan, sehingga orang yang mengalaminya semua bisa tiba di sini. Terima kasih :)

Beberapa konteks: entri lockfile lama (lebih dari setahun yang lalu?) tidak memiliki bidang integritas. Kembali ketika ditambahkan, kami memutuskan untuk tidak memigrasikannya secara otomatis, karena menghasilkan banyak perubahan pada proyek yang tidak curiga.

Jadi yang terjadi adalah ketika menginstal dari entri tanpa integritas seperti itu, integritas tidak disimpan dalam cache, dan kemudian ketika nanti menginstal proyek dengan file kunci modern dengan bidang integritas, kami melaporkan bahwa cache disimpan tanpa integritas dan menolak untuk menggunakannya.

Solusinya adalah pertama-tama aktifkan migrasi dengan menambahkan yang berikut ini di ~/.yarnrc :

unsafe-disable-integrity-migration false

Kemudian bersihkan cache dan instal ulang:

yarn cache clean
yarn install -f

Saya pikir saya hanya akan membuat rilis patch yang akan memigrasikan lockfiles secara paksa... Sudah lebih dari setahun yang lalu, semoga perubahannya tidak terlalu mengganggu sekarang Atau saya bisa menunggu mayor berikutnya yang dijadwalkan dirilis dalam beberapa bulan.

Perbaikan validasi tampaknya merupakan perubahan yang melanggar karena cache sekarang tidak dapat dibagikan di seluruh entri dengan dan tanpa bidang integritas.

Setiap dependensi yang diinstal dari yarn.lock dengan unsafe-disable-integrity-migration true yang sebelumnya tidak di-cache sekarang akan menyebabkan kesalahan ini setiap kali repo lain tanpa pengaturan itu mencoba menginstal salah satu dependensi itu... bahwa ada kemungkinan yang sangat tinggi dari berbagai proyek yang berbagi setidaknya satu ketergantungan transitif.

Migrasi paksa file kunci juga tampak seperti perubahan yang melanggar, karena versi sebelum/sesudah perubahan tidak akan kompatibel lagi.

Dari perspektif saya yang terbatas, saya akan:

1. Perbarui pesan kesalahan, itu tidak memberikan informasi apa pun sehingga sangat sulit untuk mengetahui apa yang harus dilakukan. Saya harus men-debug kode benang secara langsung untuk mencari tahu apa masalahnya.
2. Dukung kedua jenis entri lockfile dengan:
   a) Selalu tambahkan bidang integritas ke cache, terlepas dari apakah entri lockfile memiliki bidang integritas atau tidak, sehingga kedua jenis entri yarn.lock dapat memanfaatkan cache
   b) Menyimpan versi cache yang terpisah untuk entri dengan dan tanpa bidang integritas

Jika tidak ada opsi untuk 2) yang berfungsi maka saya kira migrasi paksa file kunci lebih baik daripada benang yang tidak berfungsi sama sekali.

Setiap dependensi yang diinstal dari yarn.lock dengan unsafe-disable-integrity-migration true yang sebelumnya tidak di-cache sekarang akan menyebabkan kesalahan ini setiap kali repo lain tanpa pengaturan itu mencoba menginstal salah satu dependensi itu... bahwa ada kemungkinan yang sangat tinggi dari berbagai proyek yang berbagi setidaknya satu ketergantungan transitif.

Catatan cukup - hanya entri lockfile lama . Misalnya, jika Anda membuat proyek baru sekarang, Anda akan melihat bidang integritas diisi dengan benar. Demikian pula, jika Anda mengambil file kunci lama dan menambahkan ketergantungan baru, bidang integritas juga akan ada di sana (tetapi entri yang ada tidak akan menerima yang baru).

Perbarui pesan kesalahan, itu tidak memberikan informasi apa pun sehingga sangat sulit untuk mengetahui apa yang harus dilakukan. Saya harus men-debug kode benang secara langsung untuk mencari tahu apa masalahnya.

Kedengarannya masuk akal.

b) Menyimpan versi cache yang terpisah untuk entri dengan dan tanpa bidang integritas

Hm Kedengarannya mungkin. Saya menyelidiki menggunakan integritas sebagai entri cache sebelumnya, dan itu terbukti cukup menantang karena waktu pemeriksaan integritas. Tetapi jika kita hanya menambahkan penanda untuk memperjelas apakah ada bidang integritas atau tidak ... ya, itu mungkin berhasil.

@arcanis Kami telah mengalami masalah ini dengan file yarn.lock terbaru beberapa kali. Dan setelah membersihkan cache, masalah muncul lagi dalam keadaan tertentu. Apakah cache yang rusak karena pemutusan benang yang tidak terduga atau pemutusan jaringan menyebabkan masalah ini?

Dapatkah seseorang menggunakan nightly terbaru kami dan memberi tahu saya apakah Anda masih mendapatkan kesalahan ini?

Kami mengalami masalah terkait kegagalan checksum integritas dengan yarn 1.19.0. Terlihat sangat seperti ini. Saya menguji setiap malam dan sepertinya tidak banyak membantu.

@arcanis Tampaknya berfungsi untuk kasus saya.

@arcanis Saya tidak lagi mengalami kesalahan setelah menggunakan nightly terbaru, terima kasih atas perbaikan cepatnya!

Sebenarnya, saya berbicara terlalu cepat. Saya baru saja mengalami kesalahan yang sama tetapi disebabkan karena alasan yang berbeda:

Integritas antara versi yang di-cache dan non-cache tidak cocok.

Dari apa yang saya lihat, integritas jarak jauh yang di-cache adalah sha-1 sedangkan integritas yang dibandingkan adalah sha-512, yang saya asumsikan menyebabkan ketidakcocokan.

Apakah Anda memiliki repro kecil yang dapat saya gunakan?

Saya mengalami beberapa kegagalan pembangunan proyek karena pemeriksaan integritas, saat ini harus melewati file lock karena --no-lockfile .

Ini tentu saja mengalahkan tujuan dari file lock sama sekali.

Apakah langkah-langkah yang ditetapkan di sini merupakan jalur migrasi yang disarankan https://github.com/yarnpkg/yarn/issues/7584#issuecomment -536437423?

Apakah langkah-langkah yang ditetapkan di sini merupakan jalur migrasi yang disarankan #7584 (komentar) ?

Ya. Anda juga dapat menggunakan nightly terbaru, dan jika tidak berhasil, silakan bagikan kasus reproduksi ("Jalankan yarn cache clean , lalu yarn install pada proyek berikut, Benang akan gagal dipasang", sesuatu seperti ini).

Kami tiba-tiba mulai melihat masalah ini di server build kami kemarin, dengan v1.19.0. Kami belum melihatnya di salah satu mesin dev. Saya kira ini berarti yarn cache clean mungkin akan memperbaikinya (kecuali saya tidak memiliki akses ke server build untuk benar-benar mencoba ini)?

Saya menduga menginstal versi malam tidak akan menjadi solusi yang dapat diterima. Apakah ada timeline untuk versi berikutnya yang akan menyertakan perbaikan ini? Saya melihat beberapa posting kembali bahwa Anda mengatakan versi utama berikutnya adalah beberapa bulan lagi ... tetapi sepertinya Anda telah menemukan perbaikan yang dapat dirilis dalam rilis perbaikan bug sekarang?

Saya menduga menginstal versi malam tidak akan menjadi solusi yang dapat diterima. Apakah ada timeline untuk versi berikutnya yang akan menyertakan perbaikan ini? Saya melihat beberapa posting kembali bahwa Anda mengatakan versi utama berikutnya adalah beberapa bulan lagi ... tetapi sepertinya Anda telah menemukan perbaikan yang dapat dirilis dalam rilis perbaikan bug sekarang?

Saya tidak ingin menerbitkan beberapa rilis tambalan yang tidak lengkap dalam jangka waktu yang singkat. Mengingat bahwa beberapa orang telah melaporkan masih memiliki beberapa masalah (cc @Blasz), saya menunggu untuk mendapatkan informasi lebih lanjut sebelum memutuskan apakah akan merilis sekarang atau nanti. Oleh karena itu saya meminta repro

Jika Anda membutuhkannya sekarang, nightly adalah tindakan terbaik (mereka dimaksudkan untuk stabil, karena kami hanya bergabung di master saat CI berwarna hijau).

Saya tidak akan dapat memberi Anda repo, tetapi saya dapat memberi Anda daftar paket yang telah kami instal sebagai dependensi dan devDependencies jika ini ada gunanya?

"ketergantungan": {
"lodash.clonedeep": "4.5.0",
"bereaksi": "16.8.6",
"inti-js": "3.2.1",
"isomorphic-fetch": "2.2.1",
"react-bootstrap": "0.32.4",
"react-bootstrap-toggle": "2.3.2",
"react-dom": "16.8.6",
"react-router-dom": "5.0.1",
"react-scripts": "3.0.1"
},

"devDependencies": {
"@rescripts/cli": "0.0.11",
"@rescripts/utilities": "0.0.5",
"@jenis/enzim": "3.10.3",
"@types/enzyme-adapter-react-16": "1.0.5",
"@types/jest": "24.0.15",
"@types/lodash.clonedeep": "4.5.6",
"@types/node": "12.6.1",
"@types/react": "16.8.23",
"@types/react-bootstrap": "0.32.19",
"@types/react-dom": "16.8.4",
"@types/react-router-dom": "4.3.4",
"enzim": "3.10.0",
"enzyme-adapter-react-16": "1.14.0",
"sejarah": "4.9.0",
"enzim lelucon": "7.0.2",
"jest-junit": "6.4.0",
"tslint": "5.18.0",
"tslint-react": "4.0.0",
"ketik": "3.5.3",
"yarn-run-all": "3.1.1"
}

Tidak juga, tidak, jika Anda tidak menggunakan nightly.

Hai @arcanis , di beberapa CI tidak ada opsi bagus untuk menghapus cache. Dan, beberapa orang menghadapi Incorrect integrity when fetching from the cache . Apa pendapat Anda tentang membatalkan cache ketika kami mencapai skenario ini?

Sebenarnya, saya berbicara terlalu cepat. Saya baru saja mengalami kesalahan yang sama tetapi disebabkan karena alasan yang berbeda:

Integritas antara versi yang di-cache dan non-cache tidak cocok.

Dari apa yang saya lihat, integritas jarak jauh yang di-cache adalah sha-1 sedangkan integritas yang dibandingkan adalah sha-512, yang saya asumsikan menyebabkan ketidakcocokan.

@arcanis Saya belum dapat membuat repro kecil karena saya menentukan itu terkait dengan registri npm internal yang kami gunakan.

Registri yang kami gunakan tidak mengembalikan bidang integrity sehingga versi cache dari paket yang diselesaikan dari registri menggunakan hash sha1 . Ketika paket yang sama kemudian diselesaikan dari npm alih-alih registri kita sendiri, ia memiliki bidang integritas sha512 dan menyebabkan bentrokan.

Saya tidak terlalu akrab dengan pendaftar internal jadi saya tidak yakin apa solusi yang tepat. Bisakah kita menyimpan cache berdasarkan registri daripada menggunakan cache yang sama di berbagai registri? Atau batalkan saja cache seperti yang disarankan @torifat .

Saya juga tidak yakin mengapa @xclidongbo memutuskan untuk menutup ini karena masalah belum sepenuhnya teratasi, saya sarankan untuk membuka kembali ini. Sudah ada duplikat lain di #7589.

Untuk referensi, kami menggunakan registri artifactory yang belum mendukung bidang integritas sha512: https://www.jfrog.com/jira/browse/RTFACT-20084

Terima kasih telah menyelidiki, multi-pendaftaran mungkin menjadi alasan mengapa orang mengalami masalah.

Hai @arcanis , di beberapa CI tidak ada opsi bagus untuk menghapus cache

Saya pikir saya akan memecahkan cache lagi di rilis berikutnya, jadi CI akan mulai baru.

Apa pendapat Anda tentang membatalkan cache ketika kami mencapai skenario ini?

Meskipun dapat dilakukan, saya pikir solusi yang lebih baik adalah selalu menghasilkan checksum sha512 , terlepas dari apa yang dikembalikan oleh registri jarak jauh (selama hash lainnya cocok). Karena Anda dapat mereproduksi masalah ini, apakah Anda punya waktu untuk melihat @Blasz itu, kebetulan? Saya ingin tahu apakah hanya mengisi algorithms dengan sha512 tidak akan cukup.

1. Perbarui pesan kesalahan, itu tidak memberikan informasi apa pun sehingga sangat sulit untuk mengetahui apa yang harus dilakukan. Saya harus men-debug kode benang secara langsung untuk mencari tahu apa masalahnya.

Ya silahkan! Harus men-debug benang versi lokal "transpiled" selama berjam-jam baris demi baris untuk melihat apa yang menyebabkan ini dan pada paket mana.

Dengan --verbose setidaknya harus ada pencatatan yang lebih baik untuk apa yang terjadi.

@Blasz dapatkah Anda mengonfirmasi bahwa https://github.com/yarnpkg/yarn/pull/7591 memperbaiki masalah Anda?

@arcanis sekarang, build malamnya memperbaiki masalah ini, terima kasih

Saya menggunakan: yarn-v1.20.0-20191002.1501 (18 menit yang lalu)

Saya memiliki masalah yang sama, tetapi instalasi berlanjut:

rbose 15.127 Request "http://binary/artifactory/api/npm/npm/electron-to-chromium" finished with status code 200.
verbose 16.053 Request "http://binary/artifactory/api/npm/npm/caniuse-lite" finished with status code 200.
[2/4] 🚚  Fetching packages...
verbose 31.592 Performing "GET" request to "http://binary:80/artifactory/api/npm/npm/arui-feather/-/arui-feather-13.11.0.tgz".
verbose 31.646 Error: Incorrect integrity when fetching from the cache
    at MessageError.ExtendableBuiltin (/Users/luchanso/.yarn/lib/cli.js:721:66)
    at new MessageError (/Users/luchanso/.yarn/lib/cli.js:750:123)
    at /Users/luchanso/.yarn/lib/cli.js:48147:15
    at Generator.next (<anonymous>)
    at step (/Users/luchanso/.yarn/lib/cli.js:304:30)
    at /Users/luchanso/.yarn/lib/cli.js:315:13
    at <anonymous>
error Incorrect integrity when fetching from the cache
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
verbose 31.703 Performing "GET" request to "http://mvn//artifactory/api/npm/npm/geoip-lite/-/geoip-lite-1.2.1.tgz".
verbose 31.795 Performing "GET" request to "http://mvn//artifactory/api/npm/npm/path-parse/-/path-parse-1.0.5.tgz".
verbose 31.797 Performing "GET" request to "http://mvn//artifactory/api/npm/npm/vary/-/vary-1.1.2.tgz".
...

dan gagal di finish yarn cache clean membantu untuk pertama kalinya

@Luchanso Ini bukan obrolan. Berbagai orang berlangganan topik ini dan menerima pemberitahuan, dan kiriman Anda tidak akan membantu mereka. Silakan gunakan saluran perselisihan kami jika Anda benar-benar perlu memposting pesan yang cepat.

FWIW, kami mulai melihat kesalahan ini selama pembuatan yarn install untuk CI kemarin. Penurunan sementara ke yarn 1.18 tampaknya menjadi solusi yang baik bagi kami: kebijakan yarn set-versi 1.18

@Blasz dapatkah Anda mengonfirmasi bahwa #7591 memperbaiki masalah Anda?

Sayangnya, itu tidak memperbaikinya sepenuhnya. Saya percaya ini memperbaiki masalah di mana versi cache diselesaikan dari registri 'integritas rendah' ​​dan versi jarak jauh diselesaikan dari registri 'integritas tinggi' (npm).

Namun, itu tidak memecahkan sebaliknya di mana versi cache dari registri integritas tinggi dan paket diselesaikan dari registri integritas rendah. Dalam kasus ini, remote.registry berisi hash sha1 dan cacheIntegrity hanya memiliki hash sha512 jika di-cache dari entri yarn.lock yang berisi bidang integritas. Menariknya, jika paket di-cache dari registri integritas tinggi dari entri yarn.lock tanpa bidang integritas, bidang cacheIntegrity berisi hash sha1 dan sha512.

Saya akan mencoba menaikkan PR hari ini yang memperbaiki skenario ini dan meningkatkan pesan kesalahan. Saya berpikir bahwa perbaikannya dapat menambahkan sha1 ke algoritme default yang ditetapkan bersama sha512.

@blenoski Masalah ini juga mulai mengenai infrastruktur CI kami. Menurunkan versi dengan yarn policies set-version 1.18 bekerja dengan baik. Terima kasih!

Juga mulai melihat kesalahan ini yang menyebabkan gagal membangun di pengaturan Jenkins CI kami. Menambahkan yarn policies set-version 1.18 memperbaiki masalah.

Saya dapat mengonfirmasi - kami segera mulai melihat kegagalan ini di saluran kami ketika 1.19.0 dirilis. Seperti di atas, kami menemukan bahwa menambahkan yarn policies set-version 1.18.0 menyelesaikan masalah.

yarn policies set-version 1.18 berfungsi untuk repo saat ini, apakah ada cara untuk mengatur ini secara global?

@Robula itulah tujuan yarn policies set-version , menegakkan bahwa setiap orang menggunakan versi benang yang sama untuk repo tertentu.

Untuk melakukan ini secara global, Anda cukup menginstal [email protected] alih-alih 1.19 saya pikir.

kapan kita bisa mengharapkan rilis yang memperbaiki masalah ini?

Alih-alih "memperbaiki" masalah melalui yarn policies set-version 1.18.0 harus ada versi perbaikan terbaru yang mengembalikan perubahan yang menyebabkan masalah ini.

Penutupan - perbaikan yang relevan telah dipilih ke dalam 1.19.1 (sekarang dirilis).

curl --compressed -o- -L https://yarnpkg.com/install.sh | bash

Menginstal v1.19.1 yang memecahkan masalah. :bir: @arcanis

Saya berharap CHANGELOG akan menandai v1.18 sebagai disadap, sesuai rekomendasi https://semver.org/ .

Mungkin "npm deprecate" pada versi khusus ini juga?

Itu bisa menghemat banyak waktu bagi mereka yang terlambat ke pesta.

pada rilis cokelat
v1.19.1 tidak ada

1.19.1 menghasilkan:

  Error: No algorithms available for ""
      at Integrity.pickAlgorithm (/Users/kross/.yarn/lib/cli.js:32619:13)
      at Integrity.match (/Users/kross/.yarn/lib/cli.js:32604:24)
      at /Users/kross/.yarn/lib/cli.js:48145:58
      at Generator.next (<anonymous>)
      at step (/Users/kross/.yarn/lib/cli.js:304:30)
      at /Users/kross/.yarn/lib/cli.js:315:13

Saya mencoba setelah kegagalan terus-menerus pagi ini pada 1.19.0. Saya kembali ke 1.18 dan dapat menginstal.

Memutakhirkan ke v1.19.1 memperbaiki masalah

Sayangnya Ubuntu 18.04 masih memiliki 1.19 sebagai versi terbaru. Tetapi menambahkan repo yarnpkg dan memutakhirkan seperti pada https://phoenixnap.com/kb/how-to-install-yarn-ubuntu berfungsi dengan baik untuk saya.

https://github.com/yarnpkg/yarn/issues/7584#issuecomment -536437423

Solusinya adalah mengaktifkan migrasi terlebih dahulu dengan menambahkan berikut ini di ~/.yarnrc:

Anda juga bisa menggunakan:
yarn config set unsafe-disable-integrity-migration false .

Dan kemudian yarn cache clean dan yarn install -f .

Sudo menyelesaikan ini untuk saya, jadi:

sudo npx create-react-app myApp

apakah ada cara untuk memutakhirkan file kunci dengan hash sha-1 lama menjadi sha-256 tanpa menghapus dan membuat ulang seluruh file kunci?