But one change that I did not like was the the removal of the side panel which could be pinned. Navigation required fewer steps, but now an extra click is required to bring up the options.
There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV...
And the git access timings are a sea of red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTz...
Git access will be improved now that we have Gitaly as part of this release. In GitLab 9.1 we want to move git access from the application server to the file server. That should greatly reduce the latency.
My query being you can effectively use the native pre-receive hooks & wrap the git shell to allow consensus without needing to replace git with an RPC system like Gitaly.
There's lots of discussion there. We went with a design that leans on getting out of your way and recovers some screen real-estate. We do recognize the one additional click required though. And we are actively listening to feedback and will continue to iterate.
We're working hard to improve usability and navigation in general. In addition to this sidebar change, we've made many nav updates: https://gitlab.com/gitlab-org/gitlab-ce/issues/26348.
I find that this is more intuative to use than a hard on/off only.
Ideally this should be an option. I get that 'modern UX' is all about more screen space and whatnot, but I'm not a fan of that trend personally. It seems that all that's been gained from that change is more empty space at the side of pages. Personally, I'm the type that would rather have more information and convenience on the page than extra space.
Would it be that hard to add an option to enable the side bar if people want it? That's what I like about GitLab, that it's very configurable.
9 months ago we went through a very similar version of this: https://gitlab.com/gitlab-org/gitlab-ce/issues/18542
Can we just all agree to keep the damn sidebar available - if UX wants to remove it, fine, as long as users have the ability to easily permanently pin it back open if they wish to do so.
By now GitLab UX should realize that enough developers find great utility in that sidebar.
It felt like without the side bar there is wasted screen realestate that could have project related options or navigation in the side bar.
As resolutions and screens get larger I'm a strong believer that as long as you don't over complicate or make the interface too busy, you shouldn't waste ⅔ of a web site with white space.
Regardless, very happy with 9.0 otherwise, another fantastic release from the team and contributors.
I am still waiting on the ability to view issues on a board across a group (or now, a subgroup). Since Gitlab projects are repo-centric, I have hard time tracking issues across many repositories in a single place. A board that is visible at a group-level would solve this problem.
I believe this is a feature that's coming soon, though. I am looking forward to it.
This seems to be the huge blind spot on gitlab product design. Everything is tied to git repo's while in the real world installs, users want global views of things which go across git-repos. I suspect this comes from starting off as a github clone, which has it's own constraints as a product (and it's public face).
Currently we are considering bringing all the issues of all projects (that are in the same group) into one location, i.e the group-level board, exactly as you describe it.
Team-first/team-based collaboration is something we are now highly interested in, with subgroups being a big feature in 9.0 in this direction. Our next step will be to tie that with issue boards. Thanks for the feedback!
I've seen too many npm messes where people obsess over putting every button, dropdown, heading, and dumb image component in its own company-specific repo. Then they put the whole thing in a "UI kit" which realistically they will never reuse.
But there are advantages to multi-repos, especially if you're trying to share with clients and/or open source. You can have your cake and eat it too: we use https://github.com/splitsh/lite to update our micro-repos on every commit to our monorepo.
We're working on it! We were holding off until subgroups shipped so we can make sure group-level boards work well with it. It's on the shortlist for one of the next releases. Our PM for this, Victor, might provide more detail here later.
Issue for this: https://gitlab.com/gitlab-org/gitlab-ee/issues/928
The lack of custom fields, that you find in all other bugtrackers except github, and the lack of dependent issues are really blocking us to move full to gitlab.
And the biggest issue is that they're discussing to do it, but only in the non-open-source version, which we cannot use...
I can't promise anything regarding these features. Especially custom fields are a typical EE feature in our perspective. The dependent issues feature proposal https://gitlab.com/gitlab-org/gitlab-ce/issues/4058#note_249... is still on the CE tracker but I'm not sure what it's future is.
It's just that I really want to quit using trac, who is slow and not integrated with the rest of the infrastructure.
Both of these features are not scheduled for development yet. We scope work out month to month, so we can't promise anything regarding those at this time. But we are discussing them as you see in the issues and considering how they would fit into our product as we recognize they are important features for many teams.
For relations between issues, we are considering various designs, such as: https://gitlab.com/gitlab-org/gitlab-ee/issues/1941 and https://gitlab.com/gitlab-org/gitlab-ce/issues/29444.
It has a best-in-class code review tool and a bug tracker with custom fields, permissions, templates, dependencies and more.
Its code review is built on a patch workflow (like the email-based one that the Linux kernel uses) and works very well, especially for large teams. Merge requests are clunky in comparison.
Many large open source projects moved to it, including Blender, Wikimedia, FreeBSD, Haskell, LLVM and more.
I'm using it in production, am glad to answer any questions.
The development team is dog-fooding it: https://secure.phabricator.com/
Example review: https://secure.phabricator.com/D17538 (just picked one at random, there are better examples probably)
Example task: https://secure.phabricator.com/T8783
Wikimedia instance: https://phabricator.wikimedia.org/
Mockups: https://phabricator.wikimedia.org/pholio/
Workboard: https://phabricator.wikimedia.org/project/view/171/
And much more!
The developers (especially epriestley and chad) are very professional and have a lot of experience managing large projects at scale.
Large essay about the workflow: https://secure.phabricator.com/phame/post/view/766/write_rev...
is it a function of cost, or otherwise?
The massively insanely popular VLC project somehow has no money to pay for it's version control? How did it come down to this?
It's difficult being compared with GitHub and bucketed with them from a UI perspective, but GitLab really are holding their own and seem up to it
To get an idea what our UX team is working on please see their update from this Monday:
Video https://www.youtube.com/watch?v=TMdw-plNfDQ
Slides https://docs.google.com/presentation/d/1LM6wHxGVRwHwQvGJiXwF...
This is the issue where we discussed the sidebar change. Feel free to see what contributed to the decision. https://gitlab.com/gitlab-org/gitlab-ce/issues/26200
This is the ongoing issue to discuss the change and any future iterations: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835
We are working hard to improve UX and navigation specifically at GitLab. Our UX team is focused on design and user research. Here's some work on the research end: https://gitlab.com/gitlab-org/ux-research/issues/3.
https://gitlab.com/gitlab-org/gitlab-ce/issues/29667
We need to do something about this very soon, so please keep an eye on that issue.
We're going to be doing some more work on settings pages, hopefully in 9.2 and make them a lot better.
I will subscribe to those issues and hopefully it will improve. As of now, though, that is a complete non-starter for us.
Oftentimes a week of work that's bundled in our develop->master RC merge will have more than 100 commits. Gitlab _only_ displays 100, and doesn't let you see the rest; since I like to skim down the commit messages to make release notes for the RC, this is pretty inconvenient.
If we have it profiled we can give it the right priority.
@zegerjan made a ticket for it, but it's already been closed by Stan because it is being tracked by some general performance ticket. https://gitlab.com/gitlab-org/gitlab-ce/issues/29861
Also stubborn coworkers who don't want to monkey with git settings.
Which is a shame, I really like gitlab and would love to replace gitolite :/
gitrepo.mycompany.com/product.git --> reverse proxy to git.mycompany.com/gitrepo/product.git
Should be straight forward in nginx
On the other hand, I found it absurdly difficult to get feedback or action from Gitlab on an MR. There was an MR that fixed a critical problem in the virtualbox runner, and it sat there for about 5 months with no response to either the original submitter or my emails to gitlab/gitlab ci maintainers. About a month ago I finally decided to abuse your customer support addy to ask if somebody could force the maintainer to respond before the code rots. By that time the original submitter (who in comparison turned out to be easy to contact and collaborate with) was long gone. And another user had already announced a separate script they developed and maintained to work around the lack of merging this fix.
I'm glad it finally got merged, but it was only after deciding to use my free time and treat the process as a kind of game to be beaten. But that's a one-off game I won't play again. Plus I doubt the original submitter, a Go developer, will be making another merge request.
Anyhow, I made a list on the relevant issue tracker of the work it took to get the maintainer to eventually click the "merge" button: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_r...
As Kamil already wrote, the number of notifications, issues and merge requests that we follow is enormous and sometimes something may be missed. I'm doing my best to have eye on everything but this is not always possible.
From my side I can only say that I'm very sorry that your work and work of all people engaged in this merge request was noticed so late. We're working on improving responsiveness in GitLab Runner project so hopefully we will avoid such delays in the future.
Tomasz, developer at GitLab, GitLab Runner project maintainer
Thanks for writing that comment and making us aware of that case. I'm very sorry that it did that long to get reviewed and merged. The number of issues and merge requests that pass our hands is just crazy and sometimes it happens that some of them are oversight and not properly scheduled. Having people to be persistent, like you, makes them finally to be merged and be part of the product. Thank you for doing that! From our side, we will try our best to make this process to be more efficient.
Kamil, CI/CD Lead at GitLab
One point may not have been clear-- this isn't just a matter of a single bugfix being available to the userbase sooner rather than later. Rather, it is that multiple iterations through a development cycle were missed. From my rough recollection:
1. There was a problem setting up an OSX guest to work with virtualbox runner on OSX with passwords. We worked around this using pubkey-based auth between guest and host.
2. There was also a timeout issue mentioned on the tracker for which Sam found the relevant code and suggested (but did not create) a fix.
3. Sam seemed to think a snapshot-reuse approach was too complex and likely to hang or fail. I didn't agree and was trying to explore ways in which they could run reliably as it cut CI time in half for my use case.
4. For uploading artifacts, the OSX guest's gitlab-runner binary had the wrong name requiring the user to manually create a symlink with the correct name. (I think this is fixed in 9.0, but not sure since I still have the symlink there and it's still working.)
At the time my CI builds (and probably Sam's) weren't working at all, so we both ate the cost of learning how the CI build system worked in order to debug it. If there had been feedback saying that his MR was the right (or wrong) approach I would have been happy to apply my knowledge gained at the time to the related problems mentioned above in order to debug and eventually fix them.
But now that knowledge is gone. The cost for me to regain it outweighs the benefits of small improvements to what is atm a working if imperfect system.
Edit: formatting
Can GitLab have a hands-on demo at the upcoming DataOps Summit in Boston? https://www.dataopssummit.com/
They are selling what one might call an "Omakase" experience for the whole SDLC. They call it "Idea to Production".
We don't see any reason for you not to do so. GitLab should be the easiest place to get started. If that means logging in with GitHub, we're happy to make that possible.
I had forgotten about that, thanks for the reminder.
I'll be moving all my stuff over this weekend once I curate out the things I don't actually use over on Github...
Anyway it makes importing projects easier.
We have this demo from our most recent summit where we put together an entire GitLab instance in ~20 minutes on a Kubernetes cluster, though I'm not sure that's exactly what you want? https://about.gitlab.com/2017/01/23/video-tutorial-idea-to-p...
We also have some documentation on integrating with Kubernetes here: https://docs.gitlab.com/ee/user/project/integrations/kuberne...
``` Running with gitlab-ci-multi-runner 9.0.0[...] Cloning repository... Cloning into '/builds/xxxxxxx'... warning: You appear to have cloned an empty repository. Checking out xxxxxxx as master... fatal: reference is not a tree: xxxxxx ```
The problem is tracked in https://gitlab.com/gitlab-org/gitlab-ce/issues/29855
What do people use to keep up to date with all the non-stop Gitlab releases? I used to use sandstorm but their port is very outdated by now (same goes for bitnami). I switched to cloudron and it has served me well but I am always on the look out for other solutions. On a side note, if you use the omnibus packages, are you a full time (or even part-time) sysadmin?
At present it looks like it hasn't been updated since 2015.
So, keep that in mind.
When you removed the sidebar last time - users of GitLab lobbied you hard to get that pin in there so they could keep that sidebar open at all times.
These kind of changes make me feel like you're not understanding (respecting) your customers' needs (desires).
If you don't want to use GitLab.com to host your code you can install GitLab yourself or use the mirroring function in GitLab to deploy code hosted elsewhere.
Will wait it out for Gitlab 9.1 :) Thank you for the amazing work.
https://gitlab.com/gitlab-org/gitlab-omnibus-builder/issues/...
Edit: more info in the issue you've posted.
Having said that, every time a new gitlab release comes around, I always looks for updates in one area expectantly but mostly left unsatisfied. And that is, separation of the concept of Project from "one git repo"
E.g., I want to manage a project that ties in issues from various different git repositories. It's pretty common. Almost no actual "project" in a real life business is limited to just one git repo.
I want a system-wide wiki that collects knowledge about the entire operations. The idea that each wiki is tied to a particular git-repo is.. just... wrong.
Heck, even the new search feature across projects somehow doesn't include wiki's. How did that decision get made?
And so on and so forth.
That means CI that spans multiple projects [0], higher abstraction of issue management [1], formal relationships between issues [2] and more.
Having a global wiki or higher level wiki should also be part of that [3], I think.
[0]: https://gitlab.com/gitlab-org/gitlab-ee/issues/933
[1]: https://gitlab.com/gitlab-org/gitlab-ee/issues/928
I run my fleet of runners in pre-emptible instances on GCP (they die after 24h).
I forgot to pin the version in my startup script, so all it did was a simple apt-get install gitlab-ci-multi-runner.
For some reason, version 9 of the gitlab runner cannot connect to our Gitlab (it fires a 404 on register).
Anyways, look like 9 is a cool release, but we won't be upgrading until the sidebar comes back (did a little poll in the team and it 100% was in favour of the sidebar)
The reason is that in 9.0 we've prepared a new API for Runner requests (as part of new v4 version of API) and Runner 9.0 is using only this version.
Version v1 of the CI API is still supported by Runner 1.10.X and 1.11.X. On GitLab's side it will be supported until August 2017 and until then we will also support Runner 1.11.X.
https://about.gitlab.com/images/9_0/9_0-cover-image.jpeg
https://www.google.ca/search?q=queenstown+new+zealand&source...
