ci: node pipelines now setup node version depending on lockfileVersion
#230
Conversation
derberg
requested review from
quetzalliwrites,
fmvilas,
KhudaDad414 and
asyncapi-bot-eve
as code owners
|
@KhudaDad414 wdyt? @smoya fyi @jonaslagoni fyi, this is finally no going to be annoying anymore |
| case 3: | ||
| nodeVersion = '18' | ||
| break; | ||
| default: |
There was a problem hiding this comment.
In which cases the default will apply?
Do you know if there is a case when there is no lockfileVersion in the package-lock.json?
If there is not, it will mean the version is >3, so I would say then the default should be the greatest version of node?
There was a problem hiding this comment.
it is hard to predict lockfile version evolution and what is latest node version. So in case 4 we set 16 and if it works, all fine, if it fails, it is actually good, we learn that there is a new version and we can fix it super fast here in the composite action
this default is only for projects that do not have package-lock, which is possible, by mistake, but possible
| @@ -50,11 +50,15 @@ jobs: | |||
| id: packagejson | |||
| run: test -e ./package.json && echo "exists=true" >> $GITHUB_OUTPUT || echo "exists=false" >> $GITHUB_OUTPUT | |||
| shell: bash | |||
| - if: steps.packagejson.outputs.exists == 'true' | |||
| name: Check package-lock version | |||
| uses: asyncapi/.github/.github/actions/get-node-version-from-package-lock@master | |||
There was a problem hiding this comment.
Question: Is this being cached? It will fetch latest action when updated in master branch?
There was a problem hiding this comment.
yup, taking latest from master, which is good, there are no issues with it, as it is in .github repo, so if we anyway change something to this composite action and it will be breaking, we will anyway update dependent workflows.
if there is a workflow that is not managed it .github repo and would like to use this composite action, this is fine, but then they need to use commitId and not branch name
Co-authored-by: Sergio Moya <[email protected]>
|
/rtm |
This is related to very annoying thing about current pipelines, that they are set to Node 14 and in many projects package-lock v2 and even v3 is used, for newer versions of Node. As a result, many times happens that installation of project fail because of inconsistent support between old npm and new package lock structure.
more in #187
so what is this PR introducing:
This PR was tested in:
derberg/.github-asyncapi/.github/actions/get-node-version-from-package-lock@d3d8d7452fa3cd5c9970fbb2114e4bafa8a6dabd