Cache restore fails on Windows worker on 'Github Actions'

[MarcFehling]

Dear community,

with the help of the oneapi-src/oneapi-ci repository I managed to install Intel oneAPI ifort, mkl, and intelmpi on a Windows worker within "Github Actions" with this workflow script.

I initialize the Intel oneAPI environment with the batch script located in "C:\Program Files (x86)\Intel\oneAPI\setvars.bat" and compile my code successfully. See this workflow execution (prepare cache).

Now, I want to go one step further and enable caching the whole folder "C:\Program Files (x86)\Intel\oneAPI" to save time in subsequent workflows. I tried to enable cache restore, but for some reason the "setvars.bat" script fails to initialize the Intel oneAPI environment correctly. See this workflow execution (cache restore fails).

I suspect that it is not enough to simply call the "setvars.bat" script in case of restoring the oneAPI folder. Any help towards getting cache restore to work would be highly appreciated.

Best,
Marc

[ArpanB_Intel]

Hi Marc, are you compiling your code using ifort, mkl or intelmpi? Could you confirm that with us?

We would like to know.

[MarcFehling]

We compile the code with the Intel Fortran Compiler (ifort) and link it against the Intel Math Kernel Library (mkl) and the Intel Message Passing Interface (intelmpi).

What I am asking above is how to get the Intel oneAPI environment set up correctly after restoring the Intel oneAPI installation from cache during 'Github Actions', i.e. extracting the installation from a tarball.

I couldn't find a dedicated forum with respect to Cloud Continuous Integration, so I hoped this one is suitable.

[ArpanB_Intel]

Marc, thank you for the update.

We will move your query to the respective forum for further support on the performance issues you are encountering.

[VarshaS_Intel]

Hi,

Thanks for posting in Intel Communities.

Could you please provide us with the complete steps you have followed to reproduce the issue at our end?

And also, could you please provide us with the OS, CPU details, and Intel oneAPI you are using? If you are using any docker file, please provide us with it.

Thanks & Regards,

Varsha

[MarcFehling · Accepted solution]

I got in touch with one of the maintainers of the oneapi-src/oneapi-ci repository.

Apparently, "Github Actions" does not cache symbolic links on Windows, so all information about the "latest" folders is lost. You need to specify the version of all oneAPI components manually.

See also: https://www.intel.com/content/www/us/en/develop/documentation/oneapi-programming-guide/top/oneapi-development-environment-setup/use-the-setvars-script-with-windows/use-a-config-file-for-setvars-bat-on-windows.html

Best,
Marc

[VarshaS_Intel]

Hi,

Glad to know that your issue is resolved. Thanks for sharing the solution with us. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.

Thanks & Regards,

Varsha

[Alvaro_Mathis]

When restoring the cache on a Windows worker in Github Actions, there are a few things you can check to try to resolve the issue:

1. Make sure you're using the correct cache key. The cache key should be unique for each job or set of jobs that use the same cache. If you're using the wrong cache key, the restore will fail.

2. Check that the cache actually exists. You can do this by running the cache action with the get command, like this:

   1. This will check if the cache exists and print a message indicating whether it was found or not. If the cache doesn't exist, you'll need to create it first by running the cache action with the save command.

   2. Check the permissions on the cache directory. If the cache directory doesn't have the correct permissions, the restore will fail. Make sure the directory is readable and writable by the user running the job.

   3. Check the size of the cache. Github Actions has a limit on the size of the cache, so if your cache is too large, the restore will fail. Make sure the cache is within the size limit.
      
      

If none of these steps resolve the issue, you can try running the job with debugging enabled to get more information about the error. You can do this by setting the ACTIONS_STEP_DEBUG environment variable to true,