geido commented on code in PR #45909:
URL: https://github.com/apache/superset/pull/45909#discussion_r4444377405


##########
.github/workflows/pre-commit.yml:
##########
@@ -174,8 +174,22 @@ jobs:
         uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # 
v7.1.0
         with:
           node-version-file: "superset-frontend/.nvmrc"
-          cache: "npm"
-          cache-dependency-path: "superset-frontend/package-lock.json"
+
+      # Not setup-node's built-in `cache: npm`: it keys on the exact
+      # package-lock.json hash with no fallback, so every lockfile change
+      # makes npm ci re-download every tarball (including xlsx from
+      # cdn.sheetjs.com), exposing the install to any registry/CDN outage
+      # at that moment, which is how runs 40649064300 and 40679638770
+      # failed. Restoring from the prefix instead cuts the downloads to the
+      # changed packages.
+      - name: Cache npm
+        if: steps.changed_files.outputs.needs_node == 'true'
+        uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
+        with:
+          path: ~/.npm

Review Comment:
   On the poisoning concern, IIUC this doesn't add a new cache consumer, since 
setup-node's `cache: npm` already restored `~/.npm` in this step. What changes 
is that a planted `npm-v1-` entry could get restored without evicting the exact 
key first, and would carry over across lockfile changes. Not sure that adds 
much on top of the `prek-v1` restore below, which already runs hook envs from 
cache.



##########
.github/workflows/pre-commit.yml:
##########
@@ -174,8 +174,22 @@ jobs:
         uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # 
v7.1.0
         with:
           node-version-file: "superset-frontend/.nvmrc"
-          cache: "npm"
-          cache-dependency-path: "superset-frontend/package-lock.json"
+
+      # Not setup-node's built-in `cache: npm`: it keys on the exact
+      # package-lock.json hash with no fallback, so every lockfile change
+      # makes npm ci re-download every tarball (including xlsx from
+      # cdn.sheetjs.com), exposing the install to any registry/CDN outage
+      # at that moment, which is how runs 40649064300 and 40679638770
+      # failed. Restoring from the prefix instead cuts the downloads to the
+      # changed packages.
+      - name: Cache npm
+        if: steps.changed_files.outputs.needs_node == 'true'
+        uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
+        with:
+          path: ~/.npm
+          key: npm-v1-${{ runner.os }}-${{ 
hashFiles('superset-frontend/package-lock.json') }}
+          restore-keys: |
+            npm-v1-${{ runner.os }}-

Review Comment:
   I know the description says this only grows, but replaying the last 90 days 
of lockfile commits I get roughly 400MB going to 1.2GB. It also sits next to 
the `node-cache-…` entry e2e and translations still save, with the repo's 
caches already over 10GB. Would a month in the key and prefix make sense, so it 
resets on its own?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

  • [PR] fix(ci... sadpandajoe (via GitHub) via notifications
    • Re: [P... netlify[bot] (via GitHub) via notifications
    • Re: [P... codeant-ai-for-open-source[bot] (via GitHub) via notifications
    • Re: [P... codeant-ai-for-open-source[bot] (via GitHub) via notifications
    • Re: [P... hainenber (via GitHub) via notifications
    • Re: [P... sadpandajoe (via GitHub) via notifications
    • Re: [P... geido (via GitHub) via notifications
    • Re: [P... hainenber (via GitHub) via notifications
    • Re: [P... codeant-ai-for-open-source[bot] (via GitHub) via notifications
    • Re: [P... sadpandajoe (via GitHub) via notifications
    • Re: [P... sadpandajoe (via GitHub) via notifications

Reply via email to