Skip to content

test: add tmpfs cache-target mount to validate PLT-3439 fix#232

Draft
kb-typeform wants to merge 1 commit intomainfrom
test-tmpfs-cache-extract
Draft

test: add tmpfs cache-target mount to validate PLT-3439 fix#232
kb-typeform wants to merge 1 commit intomainfrom
test-tmpfs-cache-extract

Conversation

@kb-typeform
Copy link
Copy Markdown
Contributor

Adds an opt-in tmpfs mount step to the setup-node-with-cache composite action. When use-tmpfs=true, mounts RAM-backed volumes at the paths that actions/cache will extract to:

  • ~/.asdf/installs (2 GB)
  • ~/.asdf/plugins (200 MB)
  • node_modules (3 GB) - when cache-mode is full or node_modules-only
  • ~/.cache/yarn (1 GB) - when cache-mode is full or yarn-cache-only

Expected effect from PLT-3439 analysis:

  • Bypasses the shared ephemeral storage that's IOPS-throttled at the cgroup level and pegged at 93-100% %util during extracts.
  • Bypasses memcg-aware dirty-page accounting (kernel 6.12) that caps per-pod dirty pages at ~1 GB on these runners. Our extracts accumulate 3+ GB of dirty pages, which is the root cause of the ~13-55 s post-extract idle gaps we measured.
  • Projected "Setup Node with Cache" drop from 82-134 s to ~30-40 s.

Graceful fallback: if sudo mount fails (e.g., no CAP_SYS_ADMIN), the step logs a warning and continues with disk-backed storage.

Default is off. Plumbed through frontend-pr-workflow.yml and sonarcloud-scan.yml as use-tmpfs inputs so callers can opt in without touching the composite action. setup-node-with-cache references in both workflows repointed to this branch so the test can be validated from a single consumer (Chief) without landing changes on @v1.

Do not merge. Remove this branch once the real implementation ticket lands under the PLT-3439 epic.

Note: Please do not use this repository for new internal shared workflows and actions. Use https://github.com/Typeform/.github-private instead!

Please check that your contribution applies to one of these cases below. If this is not the case, please contribute to https://github.com/Typeform/.github-private instead.

  • This PR only changes an existing workflow.
  • This PR adds a new workflow that is needed in a public Typeform repository.

Adds an opt-in tmpfs mount step to the setup-node-with-cache composite
action. When use-tmpfs=true, mounts RAM-backed volumes at the paths that
actions/cache will extract to:
  - ~/.asdf/installs  (2 GB)
  - ~/.asdf/plugins   (200 MB)
  - node_modules      (3 GB) - when cache-mode is full or node_modules-only
  - ~/.cache/yarn     (1 GB) - when cache-mode is full or yarn-cache-only

Expected effect from PLT-3439 analysis:
  - Bypasses the shared ephemeral storage that's IOPS-throttled at the
    cgroup level and pegged at 93-100% %util during extracts.
  - Bypasses memcg-aware dirty-page accounting (kernel 6.12) that caps
    per-pod dirty pages at ~1 GB on these runners. Our extracts
    accumulate 3+ GB of dirty pages, which is the root cause of the
    ~13-55 s post-extract idle gaps we measured.
  - Projected "Setup Node with Cache" drop from 82-134 s to ~30-40 s.

Graceful fallback: if `sudo mount` fails (e.g., no CAP_SYS_ADMIN), the
step logs a warning and continues with disk-backed storage.

Default is off. Plumbed through frontend-pr-workflow.yml and
sonarcloud-scan.yml as `use-tmpfs` inputs so callers can opt in without
touching the composite action. setup-node-with-cache references in both
workflows repointed to this branch so the test can be validated from a
single consumer (Chief) without landing changes on @v1.

Do not merge. Remove this branch once the real implementation ticket
lands under the PLT-3439 epic.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@sonarqubecloud
Copy link
Copy Markdown

❌ The last analysis has failed.

See analysis details on SonarQube Cloud

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant