fix(ci): Fix for the Actions failing on Windows Runner

[Zaid-maker]

⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

• I have read and understand the pull request rules.

Description

Adds a --force flag which fixes CI failing source

Seems like there is node-gyp issue due to drop of support of Node 14 which is preventing the CI to install global NPM version, removing the npm i -g npm@9 fix the ci and seems OK Bumping to Node 16 fixes the issue

Tested the same method on my Repo CI it seems to run OK not the issue with NPM or Actions, i cannot figure out the issue.

Type of change

Please delete any options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)

Checklist

• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have performed a self-review of my own code and tested it
• I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
• My changes generates no new warnings
• My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

Please do not use any external image service. Instead, just paste in or drag and drop the image here, and it will be uploaded automatically.

[chakflying]

I wonder if there is a way to avoid having to touch the global npm version.

[Zaid-maker]

I wonder if there is a way to avoid having to touch the global npm version.

I guess we have to remove the npm i -g npm@9 step that's the only fix, i pushed lets see what happened

[Zaid-maker]

yeah removing that fix

[CommanderStorm]

I wonder if there is a way to avoid having to touch the global npm version

npm versions dependent on the node version.
While this may be changing with corepack, I see this somewhat unlikely.

Do you have a clue why this was added?

• npm@latest -> npm@9 in Lock to npm@9 #3670
• Added in Add arm runners to this repo #3326

Having a look at the node-gyp-releasees, they have dropped node 14.
Could bumping to node 16 solve this issue?

[Zaid-maker]

We could see by bumping to Node 16 for testing if everything goes correct then we should adopt that

Could bumping to node 16 solve this issue?

yes bumping to node.js 16 fix

[Zaid-maker]

So this change can stay?

[CommanderStorm]

As you noted above both

• dropping npm i -g npm@9 and
• bumping node to v16 works for resolving this issue.

I would vote for changing the node version to >=v16.
The rationale is that we will have to do that anyway due to #4414
@chakflying @louislam any objections?

Another option would be bumping node to >=v18, which would allow for bugfixes like croner@8.0.0 for AKDT timezones not triggering.
I don't know how our decision in #3747 figures into this.

However, bumping to node >= v16 this requires more files to be changed:

• see Drop Node.js 14 and 16 #3747 and
• our wiki needs to be slightly updated

[chakflying]

I have no objection to moving to >=16.

But also, it's a bit funny that a failing CI on Windows is the last straw on the camel's back for dropping 14.

[Zaid-maker]

Only bumping to Node 16 resolves this issue, the npm i -g npm@9 still there.

And maybe we can keep open this and wait for 2.0.x release and give a instructions on release we drop 14, 16..etc and here's the guide on how to upgrade which i think make a significant improvement in Security and other aspects.

Still upgrading means more bugfixes and happyy Users, decision is on Louis now

[louislam]

Um... Maybe I have to rethink to drop Node.js 14 and 16 in 2.0.0, because these weird issues I believe will eventually happen again and again.

I just feel Node.js' LTS versions are somehow too short. 18 is going to reach eol next year.

[Zaid-maker]

I just feel Node.js' LTS versions are somehow too short. 18 is going to reach eol next year.

yes you are right

[chakflying]

Can we have an interim fix by dropping npm i -g npm@9 such that CIs can be passing again?

[Zaid-maker]

Can we have an interim fix by dropping npm i -g npm@9 such that CIs can be passing again?

Yes but on windows runner needs to be on node 16 other runners works fine.

Node-gyp has issue on node 14 on windows runner

[chakflying]

If this is the only way to get it working then we should adopt it, and merge to master ASAP. I don't think we should get use to CI checks failing on PRs and commits.

[Zaid-maker]

If this is the only way to get it working then we should adopt it, and merge to master ASAP. I don't think we should get use to CI checks failing on PRs and commits.

Yup you are right.

[CommanderStorm]

Maybe I have to rethink to drop Node.js 14 and 16 in 2.0.0

I think we should merge #3747 instead.
I have updated said PR to make it mergable into master

I don't think merging this (half-baked) migration to node 16 is a good idea ^^

[chakflying]

My perspective is that fixing the CI should have a higher priority than the discussion of dropping v14/16. But if #3747 is functionally equivalent except the documentation change, I'm willing to go with that instead.

[louislam]

I merge this first