[snyk workflow] make path to node version file configurable

[jacobwinch]

What does this change?

Follow-up to #11. In order to use this in my project I need to be able to configure the path to the .nvmrc file.

How to test

I've tested this with Amigo: guardian/amigo#698.

How can we measure success?

More projects can benefit from this shared workflow.

Have we considered potential risks?

I don't think this PR introduces any new risks.

[jacobwinch]

I've followed the existing convention here (MY_INPUT), but in my experience GitHub Actions inputs are typically defined as my-input (see examples) - I wonder if we should make that change now before too many people pick this up.

[akash1810]

Does this mean we're able to use different node versions within the same repo? To provide a simple example against this: we've seen a few lambdas with a node 12 runtime, but build with node 14. That's pretty confusing IMO.

Are there any reasons one would want to use a different node version within a single repository?

[jacobwinch]

I guess there are a few reasons that we might want to specify the path to the node version file rather than using a hardcoded default:

1. The repo uses a single node version (defined in .nvmrc), but the file is not at the project root (this is my use case - cdk projects typically seem to include this file under /cdk).
2. The repo uses a single node version, but it uses .node-version (rather than .nvmrc) to manage the node version.
3. The repo uses multiple node versions e.g. version A for cdk and version B for application code. I'm not 100% sure if this is desirable/acceptable and I'm not convinced it'd work properly with this workflow!

[akash1810]

1. The repo uses a single node version (defined in .nvmrc), but the file is not at the project root (this is my use case - cdk projects typically seem to include this file under /cdk).

I think GuCDK is wrong here - it should place this file at the root (possibly tricky if it already exists).

2. The repo uses a single node version, but it uses .node-version (rather than .nvmrc) to manage the node version.

Not sure we do this (rough GH search), but a fair point.

3. The repo uses multiple node versions e.g. version A for cdk and version B for application code. I'm not 100% sure if this is desirable/acceptable and I'm not convinced it'd work properly with this workflow!

See 1. I think we should do everything we can to avoid this as it's pretty confusing!

[jacobwinch]

I've merged this PR as I think it's still sensible to allow users to configure this if it's necessary, but I agree with:

it should place this file at the root (possibly tricky if it already exists).

so I'll see if it can be easily moved for AMIgo.

[jfsoul]

I've followed the existing convention here (MY_INPUT), but in my experience GitHub Actions inputs are typically defined as my-input (see examples) - I wonder if we should make that change now before too many people pick this up.

Definitely think we should do this sooner rather than later!