The repository is mirrored to GitHub
* How long did it take you to build OneDev (e.g. in hours time invested)?
* Do you expect it to scale, e.g. to large repos, large histories, many issues?
* I see you have a "code comments" feature with which people can make comments in the actual code tree, as opposed to the commits (https://code.onedev.io/projects/onedev-server/codecomments). I implemented this for Google Code Search, nice to see it in more tools! Do your comments survive changes to the file?
And one feature I noticed missing: Pressing "Y" to get a commit-pinned permalink, like Github, Gitlab, and the other tools do.
Keep it up!
I take a lot of time optimizing the performance, and it can easily handle large amount of issues, projects and large repositories at company scale. For large repository, please check the linux demo here:
The code comments can live through file changes, even file renames.
As to commit-pinned permalink, I tried to press Y on GitHub and it does not have any effect. Can you please shed more light on this?
For starters, the README is actually displayed on mobile unlike certain other Git UIs (ahem GitHub).
I noticed a handful of small things to pick on (and if I'm good I'll go file issues...), but I like the broad strokes--particularly its use of space (at all sizes). I also see a lot of small+thoughtful UI/X features and decisions.
Installation of onedev, on a scratch host, was painless. But I think there are a few things missing before I could use it for real. At the very least I have to use username/password for repository access. I see nowhere in the user-settings, or system-settings, for adding an SSH key.
That's a basic thing which is an immediate dealbreaker, although the other things look amazing. (Role based access control, integrated CI, code-comments, etc.)
Keep up your great work :)
I'd switch to whichever was first to support a built-in CI system in a heartbeat though.
Gitlab is a nice product and the open governance is interesting, but I prefer to minimize the time invested in ruby/ror based applications.
Regarding me, it's either Python or Java, because of the support and R&D put into these. Plus it's easier to reuse parts of Java/Python projects in other projects (as they are often written in Java or Python too).
Do you have any plans to monetise, perhaps by providing a hosted version? (altho I guess that would be hard, given the free build time offered by the incumbents)
It would be interesting to see this project auto-converted to kotlin and reduction in code size (Intellij can do this automatically)
Not sure why.
I'm using latest Idea.
mvn clean package
Any particular reason why you have structured this way ? could you not pull all your source code in a single build process ?
gradle will make the builds very effective - extremely performant on modular builds
All of android now uses this, so this is not new
you will be pleasantly surprised.
But more importantly, i do request you would create a single source repo. your private dependency system is bit hard to work with. Even if you use mvn
I'm also happy that it is plain Java as it means I can contribute without learning IntelliJ or anything special.
Gradle supports modular building and other cool things that improves productivity. And a gradle build file is like 1/10th of a POM.XML file. Try it sometime.
What I meant was that if author had switched to Kotlin it would have been hard to contribute without IntelliJ.
I'm very interested in the built-in CI system, especially you mentioned that no yaml files to write. Actually, it's very painful for me to write yaml files for GitLab. Just want to know is there any plan to build a cloud based service like GitHub or GitLab? We just don't want to manage the instance ourselves.
Question: is it possible to describe the build environment inside a project with your approach? Bonus question: Is it possible to generate the build environment within a project? Because this is a totally missing feature for me, to the point I might add it one day to gitlab or Jenkins. As a developer, you should not be forced to repeat yourself in any way. And you should be able to replicate your build everywhere, including your local machine. Hence I consider it important to put the dockerfiles, etc. Inside the repo. I would be fine with having a script that generates the Jenkins pipeline, gitlab ci, or whatever on demand, but I do not want to keep the same information in sync everywhere.
Here is the typical use case. Dev A wants to upgrade a dependency, say the boost library for a C++ project. This requires some adaption. So they create a changeset/pull request. Inside that pull request they adapt the Dockerfile to use the latest boost library version.
The same day, developer B finishes a story and uses some legacy boost features. They also submit a pull request. That change does not build with the newer library but works fine with the older one.
The CI system now should be able to run the tests with both changesets independently, using the Dockerfile from each branch.
When B's work is merged first, A needs to rebase and vice-versa.
Right now we implement this by running CI outside docker and creating and entering a container with a script provided by the project, but that is a home-grown solution. I would love to see gitlab allow each branch to create its container automatically, when needed.
They would both run OK in your scenario. If "new-feature" is merged first, "old-branch" would have to merge with (new) master and fix ci before being able to pass ci and be allowedtto merge?
Personally I use branch + git tag name as the image tag, but you can use a commit hash or whatever.
I browsed the documentation on Builds an found this:
> echo "##onedev[SetBuildVersion '@params:buildVersion@']"
this resembles Azure's way of setting build variables. I admit I think it is crappy for Microsoft as a producer of operating systems to handle it this way, instead of e.g. creating a special device.
What were your considerations for using the same style in OneDev?
Please comment if you have any other requirements.
Part of the difficulty though is that the Docker Registry V2 API more or less assumes the two-level namespacing. Technically GCR might be considered to be in violation of the spec. I just wish everyone was.
I used it in hg times.
Going from Gitlab > Gitea > trying and failing to get cgit and auth working > RhodeCode made me realize I'm always going to have issues with how the SCM looks. So, why not make my own?
I think it's almost in pair on how Github renders markdown.
EDIT: I will say that RC is my favorite of the git viewers I've used thus far. I'd love a way to completely style the UI with CSS.
I will definitely use this!
Is there any plan on kanban boards and/or an container/npm/nuget registry?
Keep up the good work!