5

I am trying to cache the npm dependencies in pipeline and below is the yaml code

jobs:
- job: Cypress_e2e_tests
  pool:
    vmImage: 'windows-latest'
  variables:
     npm_config_cache: C:\Users\VssAdministrator\AppData\Local\npm-cache  


  steps:
    - task: NodeTool@0
      inputs:
        versionSpec: '10.x'
    - task: CacheBeta@1
      inputs:
        key: npm | $(Agent.OS) | package-lock.json
        path: $(npm_config_cache)
        restoreKeys: npm | $(Agent.OS) | package-lock.json
      displayName: Cache NPM packages  

- task: CacheBeta@1
  inputs:
    key: 'cypress | $(Agent.OS) | package-lock.json'
    path: 'C:\Users\VssAdministrator\AppData\Local\Cypress'
    restoreKeys: 'cypress | $(Agent.OS) | package-lock.json'
  displayName: Cache cypress binary

- script: npm cache verify
  displayName: 'NPM verify'

- script: npm ci
  displayName: 'Install NPM dependencies'

- script: npm run cy:verify
  displayName: 'Cypress verify'

- script: |
    npx cypress run --browser chrome
  displayName: 'Run Cypress tests' 
  workingDirectory: $(System.DefaultWorkingDirectory)


- task: PublishPipelineArtifact@0
  displayName: 'Publish Screenshots (Cypress)'
  condition: failed()
  inputs:
      artifactName: 'screenshots'
      targetPath: '$(Build.SourcesDirectory)/cypress/screenshots'

- task: PublishPipelineArtifact@0
  displayName: 'Publish Videos (Cypress)'
  condition: failed()
  inputs:
      artifactName: 'videos'
      targetPath: '$(Build.SourcesDirectory)/cypress/videos'


- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '*.xml'
    failTaskOnFailedTests: true
    testRunTitle: 'Cypress Test Results'
    publishRunAttachments: true
  condition: succeededOrFailed()

But in the second run, I am getting the below information and seems like the cache is not working as expected,

Information, There is a cache miss.

riQQ
  • 9,878
  • 7
  • 49
  • 66
Kesiya Abraham
  • 753
  • 3
  • 10
  • 24
  • Does these 2 builds built on 2 different branches? Or same branch? For me, it is all work fine if it based on the same branch. Could you update with the complete cache log? – Mengdi Liang Dec 26 '19 at 13:52
  • Yes, this is for the same branch. Do you think we can point to AppData of windows in the YAML without using the above-hardcoded value? – Kesiya Abraham Dec 26 '19 at 14:40
  • Nope. It's all fine if you hardcode it with a absolute value. But I'd more recommend you to use dynamic value. Did you compare the key value of these 2 builds? Are they same? – Mengdi Liang Dec 26 '19 at 15:59
  • Just wanted to check in after the weekend what the status on this issue was? Does below explanation can solve what's your puzzle? – Mengdi Liang Dec 30 '19 at 08:52
  • Seems like it is working fine now. But in between, I saw two runs using the same fingerprints but still showing cache miss. But I checked today and it is working now and restoring the cache files instead of downloading everything from the scratch. Thanks for the answer and I will get back to you if I get the same scenario again where the restore operation shows cache miss even though those are using the same fingerprints. – Kesiya Abraham Dec 30 '19 at 11:28
  • sure. just at me in comment and share me the screenshots of those keys:-) – Mengdi Liang Dec 30 '19 at 11:32

1 Answers1

2

Information, There is a cache miss.

As the design, the caching finish and meanwhile, it also generate the corresponding Key(fingerprint) for this cache after you build the Cache at first time.

This key is a uniquely identify which based on the file content: Hash the file contents which identified by the file path/file pattern, and then produce the corresponding key.

The contents of any file identified by a file path or file pattern is hashed to produce a dynamic cache key. This is useful when your project has file(s) that uniquely identify what is being cached.

So, according to the message There is a cache miss, the second build should did not using the fingerprint that the first build generated.

If these 2 builds are all built based on one same branch, the only possible of this is, there has some changes on the file that identified by the file pattern.

For example, if this identified file is package-lock.json, and I did some modify onto it after the first build finished.

At this time, the YAML pipeline will be triggerred automatically(second build) -> recache -> re-generated one new key for it: because the hash of the file has recalculated because of file content updated.

As normal, in this scenario, you could find the fingerprint of cache is not the same one.

So, because of the fingerprint is not same at the second build, the message of There is a cache miss is the expected action. This is by design because we use hash to represent the contents of the cache which unique for contents and not be affected by anything.

You could join into this 2 issue talked: #1, #2

Mengdi Liang
  • 17,577
  • 2
  • 28
  • 35