Cached commit ref shared for several projects

Hello, I have several projects sharing a single monorepository:

  • d0rich-me.netlify.app
  • design-d0rich-me.netlify.app
  • d0xigen-d0rich-me.netlify.app
  • dog-d0rich-me.netlify.app

And they use imports from master ignore build script, which looks like that:

import { execSync } from 'child_process'

console.info('Running ignore script')

const cachedCommitRef =
  process.env.CACHED_COMMIT_REF || 'd06423d365fa9cf3ef99a8653abbf1a83fe7d3bb'
const commitRef = process.env.COMMIT_REF || 'HEAD'

console.info('Cached commit ref:', cachedCommitRef)
console.info('Commit ref:', commitRef)
console.info('Running from: ', process.cwd())

const changesList = execSync(
  `git diff --name-only ${cachedCommitRef} ${commitRef}`
).toString()

console.info('Changes list:')
console.info(changesList)

class Changed {
  constructor({ src = false, deps = false }) {
    this.src = src
    this.deps = deps
  }

  get any() {
    return this.src || this.deps
  }
}

// Packages
const espritDesignChange = new Changed({
  src: changesList.includes('packages/esprit-design'),
  deps: false
})

const nuxtDesignSystemChange = new Changed({
  src: changesList.includes('packages/nuxt-design-system'),
  deps: espritDesignChange.any
})

const nuxtContentMermaidChange = new Changed({
  src: changesList.includes('packages/nuxt-content-mermaid'),
  deps: false
})

const d0xigenChange = new Changed({
  src: changesList.includes('packages/d0xigen'),
  deps: nuxtDesignSystemChange.any || nuxtContentMermaidChange.any
})

// Apps
const d0richMeChange = new Changed({
  src: changesList.includes('apps/d0rich.me'),
  deps: nuxtDesignSystemChange.any || nuxtContentMermaidChange.any
})
const d0xigenD0richMeChange = new Changed({
  src: changesList.includes('apps/d0xigen.d0rich.me'),
  deps: d0xigenChange.any
})
const designD0richMeChange = new Changed({
  src: changesList.includes('apps/design.d0rich.me'),
  deps: nuxtDesignSystemChange.any
})
const dogD0richMeChange = new Changed({
  src: changesList.includes('apps/dog.d0rich.me'),
  deps: d0xigenChange.any
})

export const ignoreD0richMeBuild = !d0richMeChange.any
export const ignoreD0xigenD0richMeBuild = !d0xigenD0richMeChange.any
export const ignoreDesignD0richMeBuild = !designD0richMeChange.any
export const ignoreDogD0richMeBuild = !dogD0richMeChange.any

I’ve noticed, that during the builds from the same commit, only one website gets a relevant value of CACHED_COMMIT_REF, the first one. All the following websites builds get CACHED_COMMIT_REF equal to COMMIT_REF, what leads to unnecessary skip of builds.

Is this expected behavior? How can I get relevant value of CACHED_COMMIT_REF?

Hi, @d0rich. The most frequent reason for this is that the build cache either does not exist or could not be fetched for some reason. Here is an example of that below:

https://app.netlify.com/sites/design-d0rich-me/deploys/674edde552a7c30009b22344

Because not build cache was downloaded there is no cached commit and the value used for that environment variable is the current commit.

Could it be that the first website build clears the old cache for the others websites using the same monorepo? In this case, it is unexpected behavior for my website build.

Is it possible to make some workaround here or use a more suitable approach?

Each site has a distinct build cache. Actions performed on one site cannot impact the build cache for other sites, even if they are on the same team.

One solution would be to always run the build when the commit refs match. This solution would likely mean that sometimes a build would occur that is unnecessary but it would be much simpler to write that code than some of the other solutions below.

Another solution would be to query the Netlify API for the deploys for the same site, branch, and context to programmatically determine the cached commit ref for the previous deploy, within the build ignore command itself.

You could also just use Git itself and if the two refs match set the cached commit to HEAD^.

Finally, we can enter a feature request at Netlify to change this behavior. However, as the current behavior has existed for a long time, it is very likely someone is depending on the current behavior, ideal or not. This makes it very hard for us to change the behavior because, while it would be an improvement for your case, it may break other people’s workflows.

If there are further questions or if you want us to file a feature request for this, please let us know.