That feature would be great 👍

@robin We already have the build docs function of CI/CD

It needs documentation, and I did say I was going to look into it, but I have not found the time because of personal work which I have had to do.

@cooperspencer I am against this, as it would be too centralised, the current undocumented feature is more than useful, being able to pick any documentation server you like, whether it is mkdocs or docusaurus, and then a CI/CD task to deploy them to a wiki endpoint is far more powerful than having a dedicated wiki tab.

It is one of the main complaints I have against Github wikis, is that you can not properly contribute to them, and they are quite closed off and can't be rehosted elsewhere.

I like to be able to locally view documentation, which is why I maintain the onedev-docs AUR package, which allows me to view the documentation offline, I have poor mobile data so it helps a lot!

@polarian I get where you are comong from but do not share this opinion. I like to have everything in one place and not host many different services. Also I have no bandwidth issues whatsoever

@polarian I get where you are comong from but do not share this opinion. I like to have everything in one place and not host many different services. Also I have no bandwidth issues whatsoever

Well then, that is problematic.

I guess if the wiki feature has the ability to be disabled, then I am more than happy to see it introduced, but if it is forced on the userbase, then I would be severely disappointed, as I do not feel we should be locked into using a single platform.

Git was designed to have multiple upstreams, we should not lock the userbase into a single instance.

Also if you add the wiki feature, at least make it "better" than github/gitlab by pushing it to a special directory within the repository allowing others to submit PR's related to the wiki, it could be called something like .docs (hidden directory would be more useful so it can be ignored by most code editors)

I guess this feature would not be hard to implement, you already have markdown parsing, you just need to parse wiki related markdown and serve it a as a subpage of a repository.

@polarian that's an awesome idea for a wiki imho. Having something like a .docs dir gives more portability for documentation in comparison to the other git hosting tools

@polarian that's an awesome idea for a wiki imho. Having something like a .docs dir gives more portability for documentation in comparison to the other git hosting tools

@robin what do you think about this?

Agree with your guys here. I don't like GitHub/GitLab way of implicit wiki repository. Either a special directory like .docs or link to a specific user specified docs project, for sake of easy contribution, and can make sure of all facilities provided by OneDev.

Agree with your guys here. I don't like GitHub/GitLab way of implicit wiki repository. Either a special directory like .docs or link to a specific user specified docs project, for sake of easy contribution, and can make sure of all facilities provided by OneDev.

@robin First of all, thanks for the great work on OneDev.

I agree with using an explicit .docs or .wiki directory approach.

At the same time, I'd like to propose enhancing the Markdown rendering — or adopting a flat-file design similar to PukiWiki — to build a simple, lightweight wiki system using plain text.

This approach doesn't need to pursue full feature completeness. A basic wiki would be good enough.

It could also avoid the complexity of database design, and instead extend the existing Markdown renderer to implement the wiki functionality.

The way I've implemented this is with a separate docs branch. When the branch changes, a build job runs which renders the wiki to HTML, and publishes the content to the repo site. Could just add a separate wiki site, in addition to the main site, so that they both can be pushed to independently without overwriting the content of the other site.

(Or, a bit extra, allow publishing to a custom user-defined site so you can have as many sites as you want; this would also mean you can easily have docs for each release of a project by simply changing the name of the site. But this is kinda out of scope of this issue.)

Implementing a wiki with built-in functionality could be done via adding a simple markdown parser build step. You'd still have to set up the build job if you want the wiki, but it should be very straightforward to do so with this design, and it fits in well to the existing OneDev ecosystem and design. Users could then edit the wiki files directly from OneDev, and saving them would make a commit which could trigger the build job.

I also like the idea of using a completely separate project, in case it makes more sense to do it that way.

A wiki button on the sidebar could point to either a wiki site, or to a site from a different project.

State changed as build OD-8401 (16.6.0) is successful