diff options
author | EuAndreh <eu@euandre.org> | 2022-01-16 16:52:43 -0300 |
---|---|---|
committer | EuAndreh <eu@euandre.org> | 2022-01-16 16:52:43 -0300 |
commit | 1fc994f588dd9ef2ef8395e57e2492a6b4d730eb (patch) | |
tree | ab518e8c2c229ec60ba921adbf9897b25520b99d /po/fr/LC_MESSAGES/_articles/2018-08-01-verifying-npm-ci-reproducibility.po | |
parent | .ignore: Remove unused file (diff) | |
download | euandre.org-1fc994f588dd9ef2ef8395e57e2492a6b4d730eb.tar.gz euandre.org-1fc994f588dd9ef2ef8395e57e2492a6b4d730eb.tar.xz |
git mv locale/ po/
Diffstat (limited to 'po/fr/LC_MESSAGES/_articles/2018-08-01-verifying-npm-ci-reproducibility.po')
-rw-r--r-- | po/fr/LC_MESSAGES/_articles/2018-08-01-verifying-npm-ci-reproducibility.po | 216 |
1 files changed, 216 insertions, 0 deletions
diff --git a/po/fr/LC_MESSAGES/_articles/2018-08-01-verifying-npm-ci-reproducibility.po b/po/fr/LC_MESSAGES/_articles/2018-08-01-verifying-npm-ci-reproducibility.po new file mode 100644 index 0000000..a4af1a6 --- /dev/null +++ b/po/fr/LC_MESSAGES/_articles/2018-08-01-verifying-npm-ci-reproducibility.po @@ -0,0 +1,216 @@ +# +msgid "" +msgstr "" + +msgid "" +"title: Verifying \"npm ci\" reproducibility\n" +"date: 2018-08-01\n" +"layout: post\n" +"lang: en\n" +"ref: verifying-npm-ci-reproducibility\n" +"updated_at: 2019-05-22" +msgstr "" + +msgid "" +"When [npm@5](https://blog.npmjs.org/post/161081169345/v500) came bringing " +"[package-locks](https://docs.npmjs.com/files/package-locks) with it, I was " +"confused about the benefits it provided, since running `npm install` more " +"than once could resolve all the dependencies again and yield yet another " +"fresh `package-lock.json` file. The message saying \"you should add this " +"file to version control\" left me hesitant on what to do[^package-lock-" +"message](The)." +msgstr "" + +msgid "" +"However the [addition of `npm " +"ci`](https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-" +"more-reliable) filled this gap: it's a stricter variation of `npm install` " +"which guarantees that \"[subsequent installs are able to generate identical " +"trees](https://docs.npmjs.com/files/package-lock.json)\". But are they " +"really identical? I could see that I didn't have the same problems of " +"different installation outputs, but I didn't know for **sure** if it was " +"really identical." +msgstr "" + +msgid "Computing the hash of a directory's content" +msgstr "" + +msgid "" +"I quickly searched for a way to check for the hash signature of an entire " +"directory tree, but I couldn't find one. I've made a poor man's [Merkle " +"tree](https://en.wikipedia.org/wiki/Merkle_tree) implementation using " +"`sha256sum` and a few piped commands at the terminal:" +msgstr "" + +msgid "Going through it line by line:" +msgstr "" + +msgid "#1 we define a Bash function called `merkle-tree`;" +msgstr "" + +msgid "" +"#2 it accepts a single argument: the directory to compute the merkle tree " +"from. If nothing is given, it runs on the current directory (`.`);" +msgstr "" + +msgid "" +"#3 we go to the directory, so we don't get different prefixes in `find`'s " +"output (like `../a/b`);" +msgstr "" + +msgid "" +"#4 we get all files from the directory tree. Since we're using `sha256sum` " +"to compute the hash of the file contents, we need to filter out folders from" +" it;" +msgstr "" + +msgid "" +"#5 we need to sort the output, since different file systems and `find` " +"implementations may return files in different orders;" +msgstr "" + +msgid "" +"#6 we use `xargs` to compute the hash of each file individually through " +"`sha256sum`. Since a file may contain spaces we need to escape it with " +"quotes;" +msgstr "" + +msgid "" +"#7 we compute the hash of the combined hashes. Since `sha256sum` output is " +"formatted like `<hash> <filename>`, it produces a different final hash if a " +"file ever changes name without changing it's content;" +msgstr "" + +msgid "" +"#8 we get the final hash output, excluding the `<filename>` (which is `-` in" +" this case, aka `stdin`)." +msgstr "" + +msgid "Positive points:" +msgstr "" + +msgid "" +"ignore timestamp: running more than once on different installation yields " +"the same hash;" +msgstr "" + +msgid "the name of the file is included in the final hash computation." +msgstr "" + +msgid "Limitations:" +msgstr "" + +msgid "it ignores empty folders from the hash computation;" +msgstr "" + +msgid "" +"the implementation's only goal is to represent using a digest whether the " +"content of a given directory is the same or not. Leaf presence checking is " +"obviously missing from it." +msgstr "" + +msgid "Testing locally with sample data" +msgstr "" + +msgid "It seems to work for this simple test case." +msgstr "" + +msgid "You can try copying and pasting it to verify the hash signatures." +msgstr "" + +msgid "Using `merkle-tree` to check the output of `npm ci`" +msgstr "" + +msgid "*I've done all of the following using Node.js v8.11.3 and npm@6.1.0.*" +msgstr "" + +msgid "" +"In this test case I'll take the main repo of " +"[Lerna](https://lernajs.io/)[^lerna-package-lock]:" +msgstr "" + +msgid "Good job `npm ci` :)" +msgstr "" + +msgid "" +"#6 and #9 take some time to run (21 seconds in my machine), but this " +"specific use case isn't performance sensitive. The slowest step is computing" +" the hash of each individual file." +msgstr "" + +msgid "Conclusion" +msgstr "" + +msgid "`npm ci` really \"generates identical trees\"." +msgstr "" + +msgid "" +"I'm not aware of any other existing solution for verifying the hash " +"signature of a directory. If you know any I'd [like to know](mailto:{{ " +"site.author.email }})." +msgstr "" + +msgid "*Edit*" +msgstr "" + +msgid "" +"[documentation](https://docs.npmjs.com/cli/install#description) claims `npm " +"install` is driven by the existing `package-lock.json`, but that's actually " +"[a little bit " +"tricky](https://github.com/npm/npm/issues/17979#issuecomment-332701215)." +msgstr "" + +msgid "" +"[^lerna-package-lock]: Finding a big known repo that actually committed the " +"`package-lock.json` file was harder than I expected." +msgstr "" + +msgid "" +"merkle-tree () {\n" +" dirname=\"${1-.}\"\n" +" pushd \"$dirname\"\n" +" find . -type f | \\\n" +" sort | \\\n" +" xargs -I{} sha256sum \"{}\" | \\\n" +" sha256sum | \\\n" +" awk '{print $1}'\n" +" popd\n" +"}\n" +msgstr "" + +msgid "" +"mkdir /tmp/merkle-tree-test/\n" +"cd /tmp/merkle-tree-test/\n" +"mkdir -p a/b/ a/c/ d/\n" +"echo \"one\" > a/b/one.txt\n" +"echo \"two\" > a/c/two.txt\n" +"echo \"three\" > d/three.txt\n" +"merkle-tree . # output is be343bb01fe00aeb8fef14a3e16b1c3d1dccbf86d7e41b4753e6ccb7dc3a57c3\n" +"merkle-tree . # output still is be343bb01fe00aeb8fef14a3e16b1c3d1dccbf86d7e41b4753e6ccb7dc3a57c3\n" +"echo \"four\" > d/four.txt\n" +"merkle-tree . # output is now b5464b958969ed81815641ace96b33f7fd52c20db71a7fccc45a36b3a2ae4d4c\n" +"rm d/four.txt\n" +"merkle-tree . # output back to be343bb01fe00aeb8fef14a3e16b1c3d1dccbf86d7e41b4753e6ccb7dc3a57c3\n" +"echo \"hidden-five\" > a/b/one.txt\n" +"merkle-tree . # output changed 471fae0d074947e4955e9ac53e95b56e4bc08d263d89d82003fb58a0ffba66f5\n" +msgstr "" + +msgid "" +"cd /tmp/\n" +"git clone https://github.com/lerna/lerna.git\n" +"cd lerna/\n" +"git checkout 57ff865c0839df75dbe1974971d7310f235e1109\n" +"npm ci\n" +"merkle-tree node_modules/ # outputs 11e218c4ac32fac8a9607a8da644fe870a25c99821167d21b607af45699afafa\n" +"rm -rf node_modules/\n" +"npm ci\n" +"merkle-tree node_modules/ # outputs 11e218c4ac32fac8a9607a8da644fe870a25c99821167d21b607af45699afafa\n" +"npm ci # test if it also works with an existing node_modules/ folder\n" +"merkle-tree node_modules/ # outputs 11e218c4ac32fac8a9607a8da644fe870a25c99821167d21b607af45699afafa\n" +msgstr "" + +msgid "2019-05-22: Fix spelling." +msgstr "" + +#~ msgid "2019/05/22: Fix spelling." +#~ msgstr "" |