Conversation
6080382 to
6be088d
Compare
There was a problem hiding this comment.
Pull request overview
This PR introduces a feature-flagged optimization to reduce I/O when installing cached action repositories by symlinking an already-unpacked action directory from the runner’s action archive cache into the workspace, instead of copying/unpacking each time.
Changes:
- Add a new feature flag (
actions_symlink_cached_actions) to enable symlinking cached, unpacked actions. - Implement a symlink fast-path in
ActionManager.DownloadRepositoryActionAsyncwhen an unpacked cache directory is present.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
src/Runner.Worker/ActionManager.cs |
Adds the symlink-from-unpacked-cache fast-path before falling back to the existing archive-cache/copy/extract logic. |
src/Runner.Common/Constants.cs |
Declares the new feature flag string constant used to gate the behavior. |
| if (!string.IsNullOrEmpty(actionArchiveCacheDir) && | ||
| Directory.Exists(actionArchiveCacheDir)) | ||
| { | ||
| var symlinkCachedActions = executionContext.Global.Variables.GetBoolean(Constants.Runner.Features.SymlinkCachedActions) ?? false; |
There was a problem hiding this comment.
do we want to also check an ENV that only set by hosted runner? I am to make sure the new code path won't get used by self-hosted runner.
There was a problem hiding this comment.
@TingluoHuang What are your concerns here? That something gets accidentally broken or it is security related (cache poisoning, etc)? Normally self-hosted runner would not see those directories and will execute the original code path
Presently we do bunch of IOPS to install 1st-party actions from archive that could be expensive for small VM SKU runners:
With this change unpacked tarballs (if available) are symlinked into the workspace upon starting up the job.
NOTE: this change requires reactive work in the image