cache is used even when cached=false

[rebeccamccabe]

I have a self hosted runner with the following workflow:

name: CI

on:
  push:
  workflow_dispatch:

jobs:
  build:
    runs-on: self-hosted

    steps:
      - name: Checkout branch
        uses: actions/checkout@v4
        if: always()
        with:
          path: MDOcean

      - name: Set up MATLAB
        uses: matlab-actions/setup-matlab@v2
        if: always()
        with:
            products: >
                Parallel_Computing_Toolbox
                Global_Optimization_Toolbox
                Optimization_Toolbox
                Statistics_and_Machine_Learning_Toolbox
                MATLAB_Report_Generator
                Simulink
                Simscape
                Simscape_Multibody

      - name: Run tests and generate artifacts
        uses: matlab-actions/run-command@v2
        if: always()
        with:
          command: cd("MDOcean"), addpath("tests"), run_tests

and I observe that setup-matlab finds a cache of matlab in the _work folder, even though cache is false:

Run matlab-actions/setup-matlab@v2
  with:
    products: Parallel_Computing_Toolbox Global_Optimization_Toolbox Optimization_Toolbox Statistics_and_Machine_Learning_Toolbox MATLAB_Report_Generator Simulink Simscape Simscape_Multibody
  
    release: latest
    cache: false
Setting up MATLAB
  Found MATLAB r2025a in cache at /home/becca/Documents/git/actions-runner/_work/_tool/MATLAB/2025.1.999/x64.
  /usr/bin/chmod +x /home/becca/Documents/git/actions-runner/_work/_tool/matlab-batch/v1/x64/matlab-batch

This is creating an issue where the subsequent run command hangs indefinitely until the action times out, perhaps because it isn't able to locate the right version of matlab on the path. This also only started becoming an issue for me sometime between 7/17/25 and 7/28/25, and my workflow hasn't been modified in that time.

[davidbuzinski]

Hi @rebeccamccabe

The cache option for the setup-matlab action determines if the action will cache MATLAB using dependency caching. This option is mostly for improving install time on GitHub hosted runners.

For self-hosted runners, like you have, we use the on-disk tool cache provided by the runner. This behavior is always on in is consistent with the other setup-* actions. It finds the already installed version of the tool and adds it to path.

The hanging is certainly concerning. Do you have any workflow logs you can share? I think based on the dates you provided, this may have been around when R2025a became the default "latest" release for MATLAB in CI workflows. Something worth trying could be explicitly setting the release input of the action back to R2024b to see if it's related to some changes in R2025.

Thanks,
David

[rebeccamccabe]

hi David, thanks for your reply. Thanks for clarifying that using the existing installation even when cache=false is the expected behavior for self hosted runners. If I wanted to use a new install each time on a self hosted runner for the sake of replication, how would I do it?

The hanging was indeed caused by the change from R2024b to R2025a. Changing back to R2024b allows matlab to run normally. There is evidently something wrong with my R2025a install, since R2025a on a github hosted runner works fine. I have already posted my logs to this issue: #154 (comment).

[rebeccamccabe]

I will also add that setup-matlab identifies a R2025a release that is incorrect (confirmed because manually invoking that matlab on the command line of my runner gives an error that it does not have a working license). It identifies /home/becca/Documents/git/actions-runner/_work/_tool/MATLAB/2025.1.999/x64 (which I did not install, presumably setup-matlab installed it). I guess this is because the setup-matlab auto-license only works on github-hosted, not self-hosted, runners. But, I do have a correctly licensed install of R2025a at /usr/local/MATLAB/R2025a/bin that setup-matlab fails to detect.

My current workaround is to have a step in the workflow that manually adds my working matlab to path, echo "/usr/local/MATLAB/R2025a/bin" >> $GITHUB_PATH, but this seems like something that should be handled by setup-matlab.

[davidbuzinski]

Hi @rebeccamccabe ,

Thank you for the additional context. I think there are a few options that can work well for your use-case.

It sounds like you currently have a self-hosted machine that already has MATLAB and all required toolboxes installed. In that case, running echo "/usr/local/MATLAB/R2025a/bin" >> $GITHUB_PATH is the recommended workflow. It will always use your self-managed MATLAB installation and you can have many versions of MATLAB on the machine managed in this way. The setup-matlab action is intended to manage its own installations of MATLAB in the tool cache, similar to the other setup-* actions that are published by the GitHub team, so it does not include this workflow.

If you would like to use an installation of MATLAB that is managed by setup-matlab, it will use the version of MATLAB found in the tool cache. This will be the fastest and most reliable way to use the setup-matlab action, and it is consistent with all of the other setup-* actions.

If you would like to use setup-matlab action on a self-hosted runner but would like to install MATLAB each time there are a few options, but it will slowdown your executions quite a bit. The easiest way would be to remove any previously installed MATLAB versions from the tool cache. Here is example yaml for such a workflow:

jobs:
  build:
    name: Run MATLAB Build
    runs-on: self-hosted
    steps:
      - name: Check out repository
        uses: actions/checkout@v4
      - name: Clear tool cache
        run: rm -rf $RUNNER_TOOL_CACHE/MATLAB
      - name: Set up MATLAB
        uses: matlab-actions/setup-matlab@v2
      - name: Run command
        uses: matlab-actions/run-command@v2
        with:
          command: ver

Note that this workaround could be problematic if multiple jobs are using the same MATLAB installation concurrently.