Add all generated .po files

1 files changed, 169 insertions, 0 deletions

diff --git a/locale/pt/LC_MESSAGES/_articles/2018-08-01-verifying-npm-ci-reproducibility.po b/locale/pt/LC_MESSAGES/_articles/2018-08-01-verifying-npm-ci-reproducibility.po
new file mode 100644
index 0000000..e1097b7
--- /dev/null
+++ b/locale/pt/LC_MESSAGES/_articles/2018-08-01-verifying-npm-ci-reproducibility.po
@@ -0,0 +1,169 @@
+#
+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 "2019/05/22: Fix spelling."
+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 ""