feat: head support

[sppatel]

Turbo repo introduce support for dry-run to inspect caches and report on whether a cache entry in the local and/or remote cache exists for a given hash. In order to leverage, remote cache implementors must implement a HEAD route to check for the resource. This PR enables this.

See the following for references..

vercel/turborepo#1437
vercel/turborepo#1988

and this article for use cases on leveraging this new info reported by dry-run.

https://medium.com/@sppatel/maximizing-job-parallelization-in-ci-workflows-with-jest-and-turborepo-da86b9be0ee6

[fox1t]

Thanks for opening the PR!
One question: aren't HEAD and GET the same thing besides the VERB? If so, we can reuse the same route defined for GET and add the HEAD verb to it.
Also, would you mind adding tests?

[sppatel]

Thanks for opening the PR! One question: aren't HEAD and GET the same thing besides the VERB? If so, we can reuse the same route defined for GET and add the HEAD verb to it. Also, would you mind adding tests?

I think they are different because HEAD should not return back a response payload. So the implementation should only check for the existence of the resource and not try to retrive/return it. There would probably be performance implications as well fetching and returning a potentially a large payload that isn't used for the underlying dry run operation - hence prolonging the execution of the command. Yes - I will add tests.

[sppatel]

@fox1t I've pushed tests but none of the tests pass locally for me (mabye configuration issues but not clear how to setup my env to be able to run locally) - but looks like the actions on CI passed

[fox1t]

LGTM

[matteovivona]

@all-contributors please add @sppatel for code

[allcontributors]

@tehkapa

I've put up a pull request to add @sppatel! 🎉

[sppatel]

@tehkapa / @fox1t any chance we can cut a release for this - looking to deploy it ASAP.

[matteovivona]

@tehkapa / @fox1t any chance we can cut a release for this - looking to deploy it ASAP.

Done.