ChristopherHX / runner.server

An unofficial Local GitHub Actions and Azure Pipelines Emulator
MIT License
181 stars 17 forks source link

Issue with Global Caching using actions/cache on Windows #285

Open oilrich25 opened 11 months ago

oilrich25 commented 11 months ago

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 with ChristopherHX/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.

- name: Cache toolchains
  uses: actions/cache@v3
  with:
    path: |
      src/gn/
      /c/github/home/.cargo/bin/
      /c/github/home/bin/ninja.exe
      ~/.cargo/bin/
      ~/bin/ninja.exe

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.

oilrich25 commented 11 months ago

Global cache is used for builds within Windows containers.

ChristopherHX commented 11 months ago

/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

oilrich25 commented 11 months ago

~/.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   
ChristopherHX commented 11 months ago

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.

oilrich25 commented 11 months ago

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.

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

oilrich25 commented 11 months ago

Currently tested ~\.cargo\bin\sccache.exe cannot be cached.

oilrich25 commented 11 months ago

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:

https://github.com/ChristopherHX/runner.server/blob/main/testworkflows/windows-container-test1/.github/workflows/exec-action.yml#L10-L14

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?