specify bee (incremental) build cache directory environment variable

[js-9]

specify bee (incremental) build cache directory environment variable for windows docker run command and cache to Library directory
This PR can be considered as an initial proposal. I'd be happy to add an option for the unity-builder action to specify the directory in the parameters, it's just that I had a really hard time understanding how the windows runner directory layout works, and couldn't find the directory in the path that is supposed to be the default on windows.

Changes

• specify bee cache directory in windows docker command

Related Issues

• document and enable caching of incremental build artifacts #716 - this addresses the question about the location of the incremental build artifacts on windows runners

Related PRs

ø

Successful Workflow Run Link

PRs don't have access to secrets so you will need to provide a link to a successful run of the workflows from your own
repo.

• ...

Checklist

• Read the contribution guide and accept the
  code of conduct
• Docs (If new inputs or outputs have been added or changes to behavior that should be documented. Please make a PR
  in the documentation repo)
• Readme (updated or not needed)
• Tests (added, updated or not needed)

Summary by CodeRabbit

• New Features

  • Added support for the BEE_CACHE_DIRECTORY environment variable in the Docker run command on Windows.

• Style

  • ESLint environment updated to include ES2020.

• Tests

  • Minor non-functional comment added in a test setup (no behavior changes).

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a BEE_CACHE_DIRECTORY environment variable to the Windows Docker run command; updates ESLint environments to include es2020; and adds an ESLint directive comment in a cloud-runner test. No exported/public signatures or runtime control flow logic changed.

Changes

Cohort / File(s)	Change Summary
Docker command src/model/docker.ts	Inserted BEE_CACHE_DIRECTORY environment variable (set to c:${dockerWorkspacePath}/Library/bee_cache) into the Windows Docker run command generated by getWindowsCommand.
Lint config .eslintrc.json	Added es2020 to the ESLint env alongside existing entries (e.g., jest/globals). No rules changed.
Tests (comment) src/model/cloud-runner/tests/cloud-runner-github-checks.test.ts	Added an ESLint directive comment before a mocked function in test setup. No behavioral changes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested labels

codex

Suggested reviewers

• cloudymax

Poem

A rabbit hops in bits and bytes,
I plant a var where cache alights.
ESLint nods, a comment sings,
Small changes sprout attentive things.
🐇✨

Pre-merge checks and finishing touches

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The PR title "specify bee (incremental) build cache directory environment variable" directly and accurately reflects the main change in the pull request, which is adding a new BEE_CACHE_DIRECTORY environment variable to the Windows Docker run command. The title is concise, specific, and clearly conveys the primary purpose of the changeset. A team member reviewing the commit history would immediately understand that this PR addresses configuring the bee cache directory for Windows Docker operations.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b0da2cf and 6f7e56a.

⛔ Files ignored due to path filters (2)

• dist/index.js is excluded by !**/dist/**
• dist/index.js.map is excluded by !**/dist/**, !**/*.map

📒 Files selected for processing (2)

• .eslintrc.json (1 hunks)
• src/model/cloud-runner/tests/cloud-runner-github-checks.test.ts (1 hunks)

✅ Files skipped from review due to trivial changes (2)

• src/model/cloud-runner/tests/cloud-runner-github-checks.test.ts
• .eslintrc.json

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 38.34%. Comparing base (ab64768) to head (6f7e56a).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff            @@
##             main     #717    +/-   ##
========================================
  Coverage   38.34%   38.34%            
========================================
  Files          78       78            
  Lines        3169     3169            
  Branches      663      663            
========================================
  Hits         1215     1215            
- Misses       1809     1954   +145     
+ Partials      145        0   -145     

Files with missing lines	Coverage Δ
src/model/docker.ts	10.20% <ø> (ø)

... and 36 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[davidmfinol]

I'm not understanding the goal of this PR. It looks like the bee cache directory is inside the Library. We always recommend caching the entire library folder. Why focus on this one subfolder?

[js-9]

I'm not understanding the goal of this PR. It looks like the bee cache directory is inside the Library. We always recommend caching the entire library folder. Why focus on this one subfolder?

Definitely! This is not quite about github actions cache as much as it is about specifying the incremental build cache location so that it can then be cached in github actions if/when somebody wants to.

[davidmfinol]

Can you share some performance metrics for this?
What do build times look like with this caching enabled vs what the build times look without this?

[js-9]

Can you share some performance metrics for this? What do build times look like with this caching enabled vs what the build times look without this?

There is a dramatic speedup for mono builds. About 2x. Unfortunately, because IL2CPP build time is defined by linking, which is not cached and not parallel, the speedup for an IL2CPP build was from about 1 hour 10 minutes to about 50 minutes, which isn't negligeable but not huge. Larger projects might benefit more, though.
(I'm comparing incremental build cache-enabled build vs. builds with only Library caching enabled.)

[davidmfinol]

We should be able to merge if you resolve the merge conflicts by pulling from main and rebuilding the dist folder.