PR level check that verifies if contributed package-lock.json is created with v2

[derberg]

We need a new global workflow, with a dedicated configuration in https://github.com/asyncapi/.github/blob/master/.github/workflows/global-replicator.yml that only certain projects can opt into if they want

The goal is that it runs on a PR and it checks if the PR modifies package-lock.json and the file is created with "lockfileVersion": 2. Otherwise the check fails and we post a nice friendly comment saying "oy, sorry but we use lockfileVersion 2, so please make sure you are not using npm 6 to install dependencies in the project, thanks a 💯 " (just an example 😄 ).

Then once the fix is done, we remove the bot comment

related to asyncapi/parser-js#427

[smoya]

@derberg FYI I created an issue in every repository that still sticks to package-lock version 2.

asyncapi/spec-json-schemas#272
asyncapi/asyncapi-react#652
asyncapi/parser-js#652
asyncapi/extensions-catalog#105
asyncapi/converter-js#147
asyncapi/generator#853
asyncapi/tck#159
asyncapi/studio#449
asyncapi/html-template#380
asyncapi/markdown-template#301
asyncapi/github-action-for-cli#260
asyncapi-archived-repos/generator-hooks#98
asyncapi/vs-asyncapi-preview#129
asyncapi/shape-up-process#111
asyncapi/chatbot#69
asyncapi-archived-repos/create-glee-app#135

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[derberg]

• we need to be flexible, so if someone wan't to use package-lock v2 and not v3 that is fine. So the check that we roll out must support validation of any version
• we need a composite reusable action that checks package-lock version from the default branch, and verifies it against version coming from the PR
• now problem is that what if someone intentionally want to switch from v2 to v3? CI will always complain. So we need to make sure that maintainer of given repo can say, "yo, my package lock version for my repo is v2". I think this can be only done through GitHub repo variables:
  

wdyt?

[smoya]

Maybe we could just check, in the git diff, that the lockVersion is not being degraded? I.e. from 3 to 2.

[derberg]

we would have to assume that nobody intentionally will degrade. But I guess it is not a bad assumption 🤔

you think variables are not good? we can easily set org variable to 2 and then on repo level maintainers can override with local variable

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️