Thanks for the pr. Please note that npm install failed on arm64/armv7 due to the native build issue.

CONTRIBUTING.md

Easy to install for non-Docker users, no native build dependency is needed (for x86_64/armv7/arm64)

Thanks for the pr.

You're very welcome 😉

Please note that npm install failed on arm64/armv7 due to the native build issue.

Yeah, I've noticed 😕

Unfortunately, it seems that the only IBM DB2 node module that's available, is based on a native build dependency: https://www.npmjs.com/package/ibm_db

After some research, it seems there's not a pure JS module to interface with DB2, and there probably won't ever be one, due to licensing questions...😞

CONTRIBUTING.md

Easy to install for non-Docker users, no native build dependency is needed (for x86_64/armv7/arm64)

I understand your point, after all, native dependencies are quite a fuss. Besides that, I don't think this ibm_db module even works on arm at all (at least I haven't been able to make it work on arm v8 x64). 😢

Yet, it works quite well on x64, and I was able to test it using the new Codespace Environment that you set up. without any change at all 😄

IMHO, for ease of usage, Docker should be the way to go. Yet, I understand it's not really acceptable to constrain the usage of the app for non docker users...

I wonder if it would be possible to use this ibm_db as an optional dependency of sorts, and prepare the frontend/backend to somehow deal with it like it's described here:

try {
  var foo = require('foo')
  var fooVersion = require('foo/package.json').version
} catch (er) {
  foo = null
}
if ( notGoodFooVersion(fooVersion) ) {
  foo = null
}
// .. then later in your program ..
if (foo) {
  foo.doFooThings()
}

This way, it would still be compatible with all the required versions, but this db2 monitor functionality would only be available for the compatible architectures. What do you think about this @louislam?

Thank you

@louislam, hi, could you please check my question about the next steps? #3439 (comment)
Thank you

I am going to close this PR as support for non-Docker (armv7/arm64) users without native dependencies is a hard requirement for monitors in uptime kuma.
If IBM changes their mind and offers a package which does not require this, we can reopen this issue.
We would like to have such a monitor, but are not willing to accept the current drawbacks this would incur.

As it stands, I don't see how keeping this issue open and hoping that IBM changes their mind will get anywhere.

We would like to encourage a second option, developing an agent:

Uptime Kuma <-> Agent <-> Oracle DB

Agent = An HTTP Server with an entry point that allows to make a request with a connection string and a query
Uptime Kuma = Make a http request to the Agent

If somebody develops an agent, we can include this in the unofficial/experimental section of our installation guide.

Hello @CommanderStorm,

Thank you for your reply 😄

So, from what I understand, you're not really keen on this approach either #3439 (comment) right?

Regarding the Agent approach, it does seem to be an interesting idea 👍
I have one question though, assuming the agent is created and running somewhere, how do you see this being configured in Kuma?

Because, in terms of DB Monitor configuration, I do like the existing setup where you can input the Connection String and Query. That said, would it be acceptable for me to create a new DB2 Monitor "external agent edition", that besides the Connection String and Query, would also receive the URL for the agent? What are your thoughts on that?

Thank you once again

Running on armv7/arm64 is a hard requirement, sorry
I don't see how #3439 (comment) does support armv7/arm64.
npm install ibm_db would just error out => hard-bricking armv7/arm64

Such code would be a mess to test, and I don't see us having the capacity currently to do that, sorry.
If we had tests such as discussed in #4451 this might not be such a big issue.

As stated above:
If IBM changes their mind about supporting this platform, we can reopen this issue