Fix gh-pages deployment workflow

[vivalareda]

The workflow currently requires a cach dependancy which is useless because most of the time it's just the root and it can just default back to that if it's not provided like it is currently doing for some of the other inputs

[rngadam]

I'm unsure why you're fixing it by disabling this instead of creating a package-lock.json so that caching can work properly?

https://github.com/actions/setup-node

   # Used to specify the path to a dependency file: package-lock.json, yarn.lock, etc. 
    # It will generate hash from the target file for primary key. It works only If cache is specified.  
    # Supports wildcards or a list of file names for caching multiple dependencies.
    # Default: ''
    cache-dependency-path: ''

Caching is to speed up the build process. Have you compared the build time before and after caching is enabled? and before and after cache-dependency-path is properly specified?

[vivalareda]

I'm not sure I understand the question or if you misunderstood my description, I am not disabling anything, all I am doing is assigning a default value to the variable

[rngadam]

I'm saying that we may want to look into whether this caching work. Caching should be based on the packages definition, most likely a file such as package-lock.json.

why caching?

looking up and installing dependencies is an expensive network/disk operation. by caching dependencies, we accelerate build time. after the first caching step, subsequent calls should be faster.

what should be the value of cache-dependency-path?

looking at the source for setup-node, we have this:

https://github.com/actions/setup-node/blob/5ef044f9d09786428e6e895be6be17937becee3a/src/cache-restore.ts#L25

  const cachePaths = await getCacheDirectories(

which is implemented here:it

https://github.com/actions/setup-node/blob/5ef044f9d09786428e6e895be6be17937becee3a/src/cache-utils.ts#L211

and only uses cacheDependencyPath if the package manager is yarn, which we don't use (we decided on npm)

this means that cacheDependencyPath = ''

and default should not be '.' but ''; probably leftover from when we switched from yarn

what does caching neeed?

it needs a lock file for the dependencies:

https://github.com/actions/setup-node/blob/5ef044f9d09786428e6e895be6be17937becee3a/src/cache-utils.ts#L23

lockFilePatterns: ['package-lock.json', 'npm-shrinkwrap.json', 'yarn.lock'],

what is package-lock.json and how do we use it?

• https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json
• https://medium.com/helpshift-engineering/package-lock-json-the-complete-guide-2ae40175ebdd

do we have package-lock.json in our projects?

• https://github.com/ai-cfia/finesse-frontend
  • has a package-lock.json, but it is older than package.json by a month which is not supposed to because package-lock.json should be generated from package.json
• https://github.com/ai-cfia/nachet-frontend
  • has an updated package-lock.json

[vivalareda]

I'm saying that we may want to look into whether this caching work. Caching should be based on the packages definition, most likely a file such as package-lock.json.

why caching?

looking up and installing dependencies is an expensive network/disk operation. by caching dependencies, we accelerate build time. after the first caching step, subsequent calls should be faster.

what should be the value of cache-dependency-path?

looking at the source for setup-node, we have this:

https://github.com/actions/setup-node/blob/5ef044f9d09786428e6e895be6be17937becee3a/src/cache-restore.ts#L25

  const cachePaths = await getCacheDirectories(

which is implemented here:it

https://github.com/actions/setup-node/blob/5ef044f9d09786428e6e895be6be17937becee3a/src/cache-utils.ts#L211

and only uses cacheDependencyPath if the package manager is yarn, which we don't use (we decided on npm)

this means that cacheDependencyPath = ''

and default should not be '.' but ''; probably leftover from when we switched from yarn

what does caching neeed?

it needs a lock file for the dependencies:

https://github.com/actions/setup-node/blob/5ef044f9d09786428e6e895be6be17937becee3a/src/cache-utils.ts#L23

lockFilePatterns: ['package-lock.json', 'npm-shrinkwrap.json', 'yarn.lock'],

what is package-lock.json and how do we use it?

• https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json
• https://medium.com/helpshift-engineering/package-lock-json-the-complete-guide-2ae40175ebdd

do we have package-lock.json in our projects?

• https://github.com/ai-cfia/finesse-frontend

  • has a package-lock.json, but it is older than package.json by a month which is not supposed to because package-lock.json should be generated from package.json

• https://github.com/ai-cfia/nachet-frontend

  • has an updated package-lock.json

well I added it because of docusaurus when I deployed it I was getting issues because the package wasn't at the root of the project at the time

[ThomasCardin]

Won't do. We are now using kubernetes to deploy our solution

[rngadam]

@ThomasCardin ok to close this, but there's also a discussion about caching during in #36 (comment) that I would like to have followed up as we want to accelerate build time of our dockers