It looks very nice. The UI is very intuitive. It's very intelligent to search commits or symbols with the help of dropdown wizard everywhere, cool!
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.
I do not have that plan yet, as product definition for cloud-based and on-premises is very different. To my opinion it is hard to create easy-to-use product for both use cases
As an old school java dev, love seeing it used here! If you’d like to talk about cloud vs on-prem design, hit me up at the email in my profile. I’ve thought about it a lot.
I give it a bonus point too for being written in Java on my personal, biased, scoring.
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).
* 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.
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:
https://code.onedev.io/projects/linux/blob
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?
It is on my radar. With a built-in binary repository, I can analyze dependencies more easily to test downstream projects using artifacts of a certain project
Please take into consideration that there is a need for nested docker repos (one additional level is enough like GitLab has per project). The overall ECR/Azure/GitHub registry stuff is so crazily limited it’s borderline unusable: you have to pop up projects/registries just to have a different image name, and tags are limited to 128 chars, within [A-Za-z0-9-_] (so, no slash), so you need to spawn repos like crazy (which means different creds or setup or project settings) and/or suffer unreadable mangled tag names.
FWIW Google Container Registry (GCR) allows arbitrarily nested paths.
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 put some common libraries into a private artifactory as I want to reduce the whole build time. The reason I am using Maven build instead of Gradle is that I can use M2E in Eclipse which can compile the project incrementally very fast while I am editing files.
It's not advisable to split code like this. The better way is to use gradle and make it a multi-module build.
First time will take time , but each time it will only compile incrementally. Blazing fast and good management.
My main concern is that gradle might not work as well as M2E in Eclipse which makes incremental compiling blazing fast (less than 1 sec for editing and compiling)
Thanks for willing to contribute. I will write some guideline for that later. Also it is possible to develop in IntelliJ, just that you need to run "mvn compile" from command line every time you changes the dependencies. While in Eclipse, it is fully automated with help of M2E.
No worries. For some reason I personally prefer NetBeans and Eclipse to IntelliJ, that's why I appreciate that you stick with plain Java and Maven instead of Kotlin and Gradle :-)
gradle works on commandline. Gradle has nothing to do with intellij.
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.
This looks really great, what do you use to generate all the feature gifs on the front page? I love when I see features visualized out like this, so easy to comprehend
On Linux systems you might want to have a look at Peek [1]. It can even make (optional) use of gifski [2], a library that is great at reaching top optimization of the limited GIF color palette.
I'm just playing with it on desktop (including the breakpoints) and agree that the UI feels thoughtful.
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.
What, that's not true, is it? I think GitHub turns those into images, if I'm wrong. Could you link a example where someone embeds SVG with CSS animations?
I'll try to remember to answer when I'm home. I have this working in a private repo so I'll make it public. Just checked it on my iPhone where it doesn't seem to work in Safari though so it's possible the support is not stellar. For sure worked in Firefox on my desktop though.
GitHub sanitizes SVG animations by removing e.g. embedded JS code but SVG animated with CSS is supported in Markdown files. See for example [1] which contains [2].
Great work, congratulations! Will definitely give it a try. Having said that, this project needs data import/export functionality (certainly for GitLab and GitHub; perhaps, also for less popular options, e.g., Bitbucket, Gitea and Gogs). Re: "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" -- I'm not sure whether it makes sense to spend time on this, unless you plan on adding enterprise features and building a business around it (technical support, etc.).
I see. This certainly could be used by SMB companies, which do not require (some or many) enterprise features, but still have sizeable codebases, teams and levels of activity. My point was that it is probably a good idea to spend time on performance (beyond some foundational metrics) as a linear function of gradual addition of enterprise features. I hope that it makes sense.
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.
GitLab engineer here, I'm curious what you're thinking of exactly. Right now you could commit your Dockerfile, use it in CI to generate an image, and push it to the registry where you can pull it from. Do you mean some convenience features to automate these steps without requiring an explicit CI setup?
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.
I'm not sure I follow, typical gitlab ci runs in the branch? So there's eg a .gitlab-ci.yml and a ./Dockerfile in branch "new-feature", and one in "old-story".
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?
Hm, ok. We build containers using ci, but I see how you might want to have a container for running tests. Depends a bit on the language/framework i suppose.
I use gitbucket, for my own private repositories. Using this would be awesome because the one thing I'm really missing is the ability to run CI-jobs in an integrated fashion.
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.)
Wow, this is seriously impressive, and rammed with features!
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)
I'm actually using it now! However, I'm now working on my own git viewer. RC is nice but the way it renders Markdown is hideous.
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?
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?
A container registry feature request is in place. Please submit feature request for npm/nuget registry.
As to kanban boards, I am not very familiar with it yet. Can you please try OneDev board and let me know what points you feel missing compared to Kanban? You may also file feature request so that discussion can happen there easier.
The OneDev board is great, definitely replaces trello. However, I was thinking something more in line with azure devops.
I would love to be able to create sprints epics and what not. Or maybe is that out of scope for this project?
95 comments
[ 4.6 ms ] story [ 135 ms ] threadI'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.
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).
The repository is mirrored to GitHub
Impressive!
Some questions:
* 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: https://code.onedev.io/projects/linux/blob
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?
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.
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
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.
https://github.com/eclipse/buildship
you will be pleasantly surprised.
https://www.vogella.com/tutorials/EclipseGradle/article.html
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
https://www.screentogif.com/
[1]: https://github.com/phw/peek
[2]: https://gif.ski/
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.
[1] https://github.com/nbedos/termtosvg/blob/develop/README.md
[2] https://github.com/nbedos/termtosvg/blob/develop/docs/exampl...
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.
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.)
I'd switch to whichever was first to support a built-in CI system in a heartbeat though.
Keep up your great work :)
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)
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 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?
I will definitely use this! Is there any plan on kanban boards and/or an container/npm/nuget registry?
Keep up the good work!