As far as I can tell the example depends on cache-files-dir and the composer.lock files found, so it should work out of the box already.

Even if there is additional vendors, the downloaded files are cached in the same directory: be it from a global dependency, your project one or a composer-bin-plugin one

hmm I guess you are right, since the composer-bin-plugin does only change the working directory and composer.json but not the cache-files-dir

after a few more tests I can see that it is not enough to configure the regular caching.

e.g. for php-cs-fixer you need something like

    - name: Cache php-cs-fixer big dependency tree	
      uses: actions/cache@v1	
      with:	
        path: vendor-bin/php-cs-fixer/vendor/	
        key: ${{ runner.os }}-php-cs-fixer-${{ hashFiles('**/composer.lock') }}-${{ hashFiles('vendor-bin/php-cs-fixer/composer.json') }}	
        restore-keys: ${{ runner.os }}-php-cs-fixer-

why is the nested composer.json necessary if you capture the lock one?

because I dont have a composer.lock committed within vendor-bin/

oh then yes, you need at least the json then :)

If you think that helps I'll welcome a PR to the doc to clarify that point :)

the main point is, that we need a lot more caching then just caching the regular composer vendor/.

you also need to cache the vendor-bin/$my-tool/vendor

It depends by what you want to cache. Traditionally, at least that is what I was doing in Travis and GitLab CI, I cache the Composer downloaded artefacts, not the vendor itself. In this sense it doesn't matter which vendor (be it a bin one or not) it is. The hash keys also matters less: I don't need to invalidate that cache (although I still can), Composer handles that for me.

If you cache the vendor directories then it's another story entirely. But IMO it's making things more complicated than necessary

let me be more precise:

composer bin php-cs-fixer install --no-progress within a github actions triggers

  - Installing symfony/polyfill-php70 (v1.15.0): Downloading (100%)
  - Installing symfony/options-resolver (v3.4.38): Downloading (100%)
  - Installing symfony/finder (v3.4.38): Downloading (100%)
  - Installing symfony/polyfill-ctype (v1.15.0): Downloading (100%)
  - Installing symfony/filesystem (v3.4.38): Downloading (100%)
  - Installing symfony/event-dispatcher (v3.4.38): Downloading (100%)
  - Installing symfony/polyfill-mbstring (v1.15.0): Downloading (100%)
  - Installing psr/log (1.1.3): Downloading (100%)
  - Installing symfony/debug (v3.4.38): Downloading (100%)
  - Installing symfony/console (v3.4.38): Downloading (100%)
  - Installing php-cs-fixer/diff (v1.3.0): Downloading (100%)
  - Installing doctrine/lexer (1.0.2): Downloading (100%)
  - Installing doctrine/annotations (v1.4.0): Downloading (100%)
  - Installing composer/xdebug-handler (1.4.1): Downloading (100%)
  - Installing composer/semver (1.5.1): Downloading (100%)
  - Installing friendsofphp/php-cs-fixer (v2.16.1): Downloading (100%)
paragonie/random_compat suggests installing ext-libsodium (Provides a modern crypto API that can be used to generate random bytes.)
symfony/event-dispatcher suggests installing symfony/dependency-injection
symfony/event-dispatcher suggests installing symfony/http-kernel
symfony/console suggests installing symfony/lock
friendsofphp/php-cs-fixer suggests installing php-cs-fixer/phpunit-constraint-isidenticalstring (For IsIdenticalString constraint.)
friendsofphp/php-cs-fixer suggests installing php-cs-fixer/phpunit-constraint-xmlmatchesxsd (For XmlMatchesXsd constraint.)
Writing lock file

when only using the regular composer caching like described in https://github.com/shivammathur/setup-php#cache-composer-dependencies

Can you double check the value of composer config cache-files-dir? Because locally it points to $HOME/.composer/cache/files and it's the same on Travis. If it points to a directory local to the project though, it might be that the bin one is using a different directory as well

I dont thinks thats relevant, because the example from shivammathur/setup-php uses a variable for that path:

    - name: Get composer cache directory
      id: composer-cache
      run: echo "::set-output name=dir::$(composer config cache-files-dir)"

    - name: Cache dependencies
      uses: actions/cache@v1
      with:
        path: ${{ steps.composer-cache.outputs.dir }}
        key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
        restore-keys: ${{ runner.os }}-composer-

however, the value is /home/runner/.composer/cache/files in a github action

just to be sure we are on the same page.

regular project dependencies get installed into
/home/runner/.composer/cache/files
when using composer-bin-plugin with a tool called php-cs-fixer, the vendors of it will be installed into
/home/runner/work/my-github-org/my-project/vendor-bin/php-cs-fixer/vendor

@staabm the vendors should be installed in /home/runner/work/my-github-org/my-project/vendor-bin/php-cs-fixer/vendor but stored in /home/runner/.composer/cache/files, so unless something has been updated in-between or that the resolved version is different, the files to download should already be there.

Also just in case: I remember on Travis it needed to land on the master branch first before seeing the effects in the PR. Might be the same here