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.

[Nikolas-Lehto]

Could you elaborate on these changes? I was reading the diffs to try to understand them with my very limited frontend skills and didn't understand how these are related to subdirectories in any way.

[mskyttner]

Sorry for jumping in, great tool, thanks! I just wanted to share that the first thing I wanted to do when learning about and starting to deploy kuma was to deploy the app with the context path set not to the root dir but to a prefix dir in order to deal with the "subfolder problem".

I saw here that a configurable URL Base is in the works, nice! It would be great to easily being able to avoid to give up the web root context for the subdomain entirely to kuma, but having it co-exist alongside other services under the same subdomain.

I found the nginx config which is great but also rather extensive and possibly prone to breaking (by becoming obsolete quickly as the app changes or potentially from clashing with other services running on the same subdomain). I will try that solution/workaround out but it would be so nice if the app could be deployed in a subdir by setting the URL Base.

With the contribution from #1092 (comment) getting configurable URL Base seems to progress nicely, but there are concerns about the need to avoid working with a "fat image" with too many dev deps bundled.

I'd therefore just like to share that I have had good experiences from using multi stage builds (see https://v2.vuejs.org/v2/cookbook/dockerize-vuejs-app.html?redirect=true#Real-World-Example) which essentially makes it possible to have a build with a full dev environment from a base layer and in a subsequent step (in the same Containerfile or Dockerfile) use the outputs in a slimmed down production image which I believe could alleviate the concerns raised.

So just a suggestion that maybe using a multi stage Containerfile/Dockerfile may allow to achive the equivalence of being able to "run a npm run build after Docker pull process" without significant disruption of the existing procedures and without introducing new tooling?