Lock Antora dependencies

[ppkarwasz]

We use npm-shrinkwrap.json to publish a locked list of dependency versions.

Other repositories will use this file to download a locked list of dependencies.

[vy]

@ppkarwasz, mind sharing the motivation for this feature, please? I mean, what do we fix? If we don't fix anything, but improve something, what is that we improve and why do we want this improvement?

[ppkarwasz]

There are several advantages of locking the versions of the Antora dependencies:

1. The first one is certainly security: transitive NPM dependencies will be upgraded only by Dependabot, when we release a new version.
2. We can also save time on caching, since we can reuse an NPM workflow. This is also suggested in the deploy-site-reusable workflow:
   

   logging-parent/.github/workflows/deploy-site-reusable.yaml

   Lines 81 to 95 in 9206282

   	# We should be calculating the cache key using `package-lock.json` instead!
   	# See https://stackoverflow.com/a/48524475/1278899
   	# For that, `package-lock.json` needs to be committed into the repository – right now it is `.gitignore`d.
   	# Once it is there, we should ideally switch from `npm i` to `npm ci`.
   	# For that, we need to configure `dependabot` to update hundreds of dependencies listed in `package-lock.json`.
   	# That translates to a never ending rain of `dependabot` PRs.
   	# I doubt if the wasted CPU cycles worth the gain.
   	key: ${{ runner.os }}-nodejs-cache-${{ hashFiles('node', 'node_modules') }}
   	# `actions/cache` doesn't recommend caching `node_modules`.
   	# Though none of its recipes fit our bill, since we install Node.js using `frontend-maven-plugin`.
   	# See https://github.com/actions/cache/blob/main/examples.md#node---npm
   	# We settle for this quick-n-dirty solution for the time being.
   	path: |
   	node
   	node_modules

   
   Note: I think that there is currently a bug in the workflow since ${{ hashFiles('node', 'node_modules') }} is used before those folders are created in the mvn site step.

[vy]

transitive NPM dependencies will be upgraded only by Dependabot

Does this mean Dependabot will try to upgrade hundreds of dependencies listed in npm-shrinkwrap.json?

This is also suggested in the deploy-site-reusable workflow

Doesn't this warrant a correction on deploy-site-reusable.yaml in this PR?

[ppkarwasz]

transitive NPM dependencies will be upgraded only by Dependabot

Does this mean Dependabot will try to upgrade hundreds of dependencies listed in npm-shrinkwrap.json?

Yes, Dependabot will upgrade about a hundred NPM dependencies, but only once a month using a single PR.
See c1134f8.

This is also suggested in the deploy-site-reusable workflow

Doesn't this warrant a correction on deploy-site-reusable.yaml in this PR?

I modified the key used for the Antora cache, so that only one cache per logging-parent version is used. We don't need more caches, since node_modules should only contain JavaScript files and the node folder does not need to be cached (Node is stored in the Maven local repository).
See b1f15b1

[ppkarwasz]

I modified the way node_modules are cached: since running a second actions/checkout in the same workflow deletes node_modules, the folder must be restored at the end of the workflow.

Caution

Remove the temporary entries marked with FIXME from deploy-site.yaml before merging and remove the test-site-stg-out branch.