Open oilrich25 opened 11 months ago
Global cache is used for builds within Windows containers.
/c/github/home/bin/ninja.exe
That might be a mingw / cygwin path, but certainly not a win32 path for c:/github/home/bin/ninja.exe
/ c:\github/home/bin/ninja.exe
~/.cargo/bin/ and ~/bin/ninja.exe still cannot cache the global cache.
name: Build
on:
push:
defaults:
run:
shell: bash
working-directory: src
jobs:
cache-toolchains-win:
runs-on: windows-2019
container:
image: oilrich25/runner-images:windows-2019-builds
options: --cpus=10
steps:
- uses: actions/checkout@v4
- name: Cache toolchains
uses: actions/cache@v3
with:
path: |
src/gn/
~/.cargo/bin/
~/bin/ninja.exe
The paths inside the container might be confusing, but I have no problem cacheing absolute win32 paths (mingw, cygwin or msys, wsl paths won't work). The https://github.com/actions/cache
action applies tar to the specified files after using it's glob, only after that happend it is sent for save in the cache service.
So %HOME%
is c:/github/home
(usually a non existing variable for windows) ( see https://github.com/ChristopherHX/runner.server/actions/runs/7078047462/job/19263363469#step:9:801
)
%USERPROFILE%
(aka ~
in actions/cache) is C:\Users\ContainerAdministrator
(see https://github.com/ChristopherHX/runner.server/actions/runs/7078047462/job/19263363469#step:9:1597
)
For windows containers only posix HOME
is overridden (follows Actions linux containers closely) and shared between containers, not USERPROFILE
.
on: push
jobs:
_:
runs-on: windows
steps:
- uses: actions/cache@v3
with:
path: |
c:/github/home/bin/ninja.exe
# ~\AppData\Local\test.txt
# ~\AppData\Local\test2.txt
key: test6
In pure windows is c:/github/home/bin/ninja.exe
cachable, due to the fact that actions/cache runs via node in the windows container it should work there as well.
Cacheing ~\AppData\Local\test.txt
aka C:\Users\ContainerAdministrator\AppData\Local\test.txt
should also work in a container.
BTW there is no GitHub Action spec for Windows Containers, they are basically non existent. If you would create windows container docker actions they would only work here.
Add that secret ACTIONS_STEP_DEBUG=true, this will help to you to find the problems.
The paths inside the container might be confusing, but I have no problem cacheing absolute win32 paths (mingw, cygwin or msys, wsl paths won't work). The
https://github.com/actions/cache
action applies tar to the specified files after using it's glob, only after that happend it is sent for save in the cache service.So
%HOME%
isc:/github/home
(usually a non existing variable for windows) ( seehttps://github.com/ChristopherHX/runner.server/actions/runs/7078047462/job/19263363469#step:9:801
)
%USERPROFILE%
(aka~
in actions/cache) isC:\Users\ContainerAdministrator
(seehttps://github.com/ChristopherHX/runner.server/actions/runs/7078047462/job/19263363469#step:9:1597
)For windows containers only posix
HOME
is overridden (follows Actions linux containers closely) and shared between containers, notUSERPROFILE
.on: push jobs: _: runs-on: windows steps: - uses: actions/cache@v3 with: path: | c:/github/home/bin/ninja.exe # ~\AppData\Local\test.txt # ~\AppData\Local\test2.txt key: test6
In pure windows is
c:/github/home/bin/ninja.exe
cachable, due to the fact that actions/cache runs via node in the windows container it should work there as well.Cacheing
~\AppData\Local\test.txt
akaC:\Users\ContainerAdministrator\AppData\Local\test.txt
should also work in a container.BTW there is no GitHub Action spec for Windows Containers, they are basically non existent. If you would create windows container docker actions they would only work here.
Add that secret ACTIONS_STEP_DEBUG=true, this will help to you to find the problems.
Thanks to @ChristopherHX for the detailed answer. c:/github/home/bin/ninja.exe
is cached normally after setting it. At the same time, I also tested the writing method ~\.cargo\bin\sccache.exe
, but found that it ended up being /c/github/home/.cargo/bin/sccache.exe
instead of C:\Users \ContainerAdministrator\.cargo\bin\sccache.exe
Currently tested ~\.cargo\bin\sccache.exe
cannot be cached.
I would like to ask a question. I found that mcr.microsoft.com/windows/servercore:ltsc2022
in windows-container-test1/.github/workflows/exec-action.yml
actually does not contain git
. How can I do that? Ensure that - uses: actions/checkout@v2
operates normally? I found that in my tests, if the container is directly specified as mcr.microsoft.com/windows/servercore:ltsc2022
, the following error will occur:
jobs:
windows:
container:
image: mcr.microsoft.com/windows/servercore:ltsc2019
steps:
- uses: actions/checkout@v4
The repository will be downloaded using the GitHub REST API
To create a local Git repository instead, add Git 2.18 or higher to the PATH
Downloading the archive
Not found.
Waiting 18 seconds before trying again
Downloading the archive
Not found.
Waiting 16 seconds before trying again
Downloading the archive
##[error]Not found.\n
However, I found that there is no error indicating that there is no nodejs
. Maybe actions-runner-win-x64-3.9.2\externals
already contains the nodejs binary, so there is no error? So does it mean that git can be placed in actions-runner-win-x64-3.9.2\externals
and then loaded when starting the mcr.microsoft.com/windows/servercore:ltsc2019
container?
If so, how to proceed?
Issue ### Description:
There is an issue with global caching using
actions/cache
on Windows operating systems. Currently, caching is limited to specific paths within the project, and attempts to cache global paths such as/c/github/home/
or~/.cargo/bin/
are unsuccessful.In practice, GitHub Actions does support caching global paths. However, when using
ChristopherHX/gitea-action-runner
in conjunction withChristopherHX/runner.server
, caching is currently restricted to paths within the project.Specifically, in the example below, only the src/gn/ path is cached. Global paths like
/c/github/home/.cargo/bin/
,/c/github/home/bin/ninja.exe
,~/.cargo/bin/
,~/bin/ninja.exe
, and similar paths are not cached as expected.Expected ### Behavior:
The expectation is that on Windows operating systems, global paths should be supported for caching. This means that paths like
/c/github/home/
and~/.cargo/bin/
should be successfully cached, not limited to paths within the project.