docs/adrs/0279-hashFiles-expression-function.md
Date: 2019-09-30
Status: Accepted
First party action actions/cache needs a input which is an explicit key used for restoring and saving the cache. For packages caching, the most common key might be the hash result of contents from all package-lock.json under node_modules folder.
There are serval different ways to get the hash key input for actions/cache action.
key themselves from a different action, customer won't like this since it needs extra step for using cache feature steps:
- run: |
hash=some_linux_hash_method(file1, file2, file3)
echo ::set-output name=hash::$hash
id: createHash
- uses: actions/cache@v1
with:
key: ${{ steps.createHash.outputs.hash }}
key input of actions/cache follow certain convention to calculate hash, this limited the key input to a certain format customer may not want. steps:
- uses: actions/cache@v1
with:
key: ${{ runner.os }}|${{ github.workspace }}|**/package-lock.json
hashFiles() will only allow on runner side since it needs to read files on disk, using hashFiles() on any server side evaluated expression will cause runtime errors.
hashFiles() will only support hashing files under the $GITHUB_WORKSPACE since the expression evaluated on the runner, if customer use job container or container action, the runner won't have access to file system inside the container.
hashFiles() will only take 1 parameters:
hashFiles('**/package-lock.json') // Search files under $GITHUB_WORKSPACE and calculate a hash for themQuestion: Do we need to support more than one match patterns?
Ex: hashFiles('**/package-lock.json', '!toolkit/core/package-lock.json', '!toolkit/io/package-lock.json')
Answer: Only support single match pattern for GA, we can always add later.
This will help customer has better experience with the actions/cache action's input.
steps:
- uses: actions/cache@v1
with:
key: ${{hashFiles('**/package-lock.json')}}-${{github.ref}}-${{runner.os}}
For search pattern, we will use basic globbing (*, ?, and []) and globstar (**).
Additional pattern details:
github.workspace (the main repo)* match files that start with .\ or / path separators on WindowsHashing logic:
$GITHUB_WORKSPACE.Question: Should we include the folder structure info into the hash?
Answer: No