Subdirectory deployment

[trogper]

Description

This adds support for Kuma deployment in http path subfolder. I have added two environment variables, UPTIME_KUMA_BASE_PATH and BASE_PATH. The value should start and end with /, but there is sanitization, which will add them.
I have changed relevant paths in vue and html from absolute to relative and added html base tag, which is used byt the browser to build absolute paths from relative. Then I made express mount the former root to the specified BASE_PATH. Additionally I have fixed a few <a> tags in vue to proper <router-link>
Socket.io does not support base tag by itself (it builds the connection url manually), so we have to prepend the basePath manually.

Fixes #147

TODO

There are a few things I would like someone to help me with:

• where is the proper place to put basePath calculation/variable? Currently it is in
  

  uptime-kuma/src/mixins/socket.js

  Lines 116 to 120 in 812b4ad

  	const basePath = document.querySelector("head base").getAttribute("href");
  	socket = io(url, {
  	path: basePath + "socket.io",
  	});

  
  

  uptime-kuma/src/components/settings/General.vue

  Lines 268 to 271 in 812b4ad

  	autoGetPrimaryBaseURL() {
  	const basePath = document.querySelector("head base").getAttribute("href");
  	this.settings.primaryBaseURL = location.protocol + "//" + location.host + basePath;
  	},

• create tests for it
• test it manually on their server/deployment (I have deployed it on mine already)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

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 test it
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• My code needed automated testing. I have added them (this is optional task)

[trogper]

@louislam can you please help me with the implementation details? I have a few questions in TODO in the first comment.

[ckocyigit]

I have merged this PR in my fork and experienced a strange behaviour.

When pressing the Edit Button on an already existing Notification it redirects me to the Status page.

I wanted to open a Issue to Kuma directly when it occurred to me that I have this probably "not fully tested" PR in my fork.

Maybe @trogper can you check if this happens on your site too?

[ckocyigit]

This is helpful, but It seems that this Pull Request in its current state is not compatible with current master as your Dockerfile describes.

[trogper]

Yes, the are minor conflicts. I'll solve them when I get some time for it

[zacharlie]

@ckocyigit That is true. At the time I posted there were no conflicts. If you need it immediately I do have an older version on dockerhub you can use in the interim: https://hub.docker.com/r/zacharlie/dbstack-monitor

[zacharlie]

@trogper just a heads up I also tested and noticed the issue described above with notification editing when merging this

[trogper]

Thanks, I know about the issue already

[Ionys320]

Question to @CommanderStorm or @louislam: could we run a npm run build after Docker pull process? Let me explain: for the moment, we don't really use Vite base path as it is supposed to work. Therefore, we lost a lot of functionalities who would simplify this PR. By being capable to run npm run buid after Docker pull, we could build the frontend using Vite by providing it the right base path, based on the ENV variable BASE_PATH.

I'm checking on my side, and it seems I only need to change a few files (including the times I change a tag to router-link tag to let Vite take care of it, and adding import.meta.env.BASE_URL), it appears I woudln't need to change more than 15 files. I of course need to do more tests and I can optimize some stuff, but I think this solution would be more maintainable than the one @trogper is working on, mainly because it gets around the problem without using the tools normally used for (Not a critic @trogper ofc, your work is awesome regarding the contrainst you got).

Here is my WIP branch about how we could use Vite base: https://github.com/Ionys320/uptime-kuma/tree/feat/subpath. Matching commit: Ionys320@8ccbbee

[louislam]

could we run a npm run build after Docker pull process

Cannot, unless the docker image includes all dev dependencies / build tools which probably is more complicated and I don't want to.