
GitLab 9.2 Released with Multiple Assignees for Issues and Pipeline Schedules - digitalnalogika
https://about.gitlab.com/2017/05/22/gitlab-9-2-released/
======
tiffanyh
If you're starting a company _today_ , would you use Gitlab over it's
competitors (Atlassian, GitHub)?

And keep in mind, I'm not talking about specifically using GitLab for "git". I
mean, what technology stack would you use for:

\- Issue tracking

\- VCS

\- Developer Chat

\- CI/CD

\- Project Boards / Project Management

I actually just asked this question today [1] but didn't get much of a
response.

I know Atlassian is not properly but for a fully stack software development
experience, it seems like my only true options are either GitLab or Atlassian
(not GitHub).

[1]
[https://news.ycombinator.com/item?id=14394123](https://news.ycombinator.com/item?id=14394123)

~~~
merb
I used both. While Atlassian didn't included everything by default and misses
lots of features (due to their plugin system which means that they don't
necessary think they need to implement stuff) and Atlassian uses more resource
and does not support git:// urls only the ugly ssh:// once. If I think back I
should've never switched from Jira+Stash+Jenkins, however we did the Switch to
GitLab and somehow I'm not 100% happy. It's way way slower a lot of things in
CE are just missing and the costs for our < 10 user company would be way
higher with gitlab ee. gitlab is easy to upgrade and the maintance feels a
little bit more easy since jira/stash backup is way more complicated. however
the jira is way better at managing issues (even the lightweight version of the
boards is more simple and easier to use) and stash is extremly fast compared
to anything on gitlab. at the end everything has their tradeoffs, but I would
prefer the Atlassian Stack since it never broke anything, while on GitLab we
often run into issues (especially CI related)

~~~
sytse
Thanks for the feedback.

What do you need in GitLab to manage issues better?

Sorry to hear you ran into problems with your self hosted GitLab. What CI
problem was the most disruptive?

~~~
merb
Well to not write a wall of text, this were the most "disruptive" things: \-
compared to JIRA Agile the issue board is a joke (it's hard to actually
describe the differences, but basically we can't use the gitlab issue board
since it either doesn't work correctly when closing issues via push or it just
isn't as understandable as the jira versions) \- docker and the ci is a
horrible experience (we had a jenkins build before, which always worked,
however even the ssh way of gitlab ci sometimes fails randomly or can't be
canceled or whatever)

Positive thinks about gitlab: \- your at least listening (while atlassian is
not, they mostly care for their big customers) however stability and
performance should be your number one priority and not adding more stuff that
might make that stuff worse. sometimes it's good to not add more stuff in some
versions.

~~~
cmatija
Hiya,

Thanks for sharing this feedback.

* Closing issues via push

Automatic issue closing (e.g. via push or MR) should work (I just tried it out
on a test repo) - see the docs[1]. Did you use the correct keyword? Maybe
something went awry, but it's definitely supported. Or did I misunderstand you
and closing them via push works, but the issue is something related to the
issue board instead? Could you share a bit more info? We'd love to get that
sorted out if it's a bug or problem.

* Issue Board usability

We'd like to make the issue board as best as it can be. Which part of it was
confusing to you? Maybe we can open an issue about it and ping the UX team?

* CI

Could you detail the experiences you had with our CI? Were you using
GitLab.com or a self-hosted instance? And if you were using GitLab.com, were
you using your own or our shared runners?

You can definitely cancel jobs, strange that you had problems with it.

What failed in your job?

* Stability & Performance

With each release we're adding stability and performance improvements, see
[2]. And as always, our infra team works hard to improve the same on
GitLab.com, see [3]

[1] -
[https://docs.gitlab.com/ee/user/project/issues/automatic_iss...](https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html)

[2] - [https://gitlab.com/gitlab-org/gitlab-
ce/issues/?scope=all&ut...](https://gitlab.com/gitlab-org/gitlab-
ce/issues/?scope=all&utf8=&state=opened&label_name\[\]=performance)

[3] - [https://gitlab.com/gitlab-
com/infrastructure/issues?scope=al...](https://gitlab.com/gitlab-
com/infrastructure/issues?scope=all&utf8=&state=opened&label_name\[\]=performance)

------
mrmondo
Thanks for all your amazing hard work guys and gals, really truly appreciate
all the effort that's been going into making GitLab releases faster, reliable
and all the new features that have been coming out, especially around Issues
and CI.

I upgraded our dev and then prod environments not after the announcement
without a hitch.

Keep up the good work!

~~~
sytse
Thanks Mr Mondo!

------
mgbmtl
One of the things I like most about Gitlab, is the steady releases and
improvements by small doses, making it easy to auto-upgrade and adapt as we go
(with the occasional internal announcement: "hey, you can now do X in Gitlab,
have fun"). I've used JIRA/Atlassian, Github and Redmine a lot, and by far, I
like Gitlab the most.

My only point of friction, which is being worked on, but will presumably take
some time: no internationalization of the user interface (UI translation). I
manage two instances of Gitlab: one for our shop (where we communicate with
clients), another for a large-ish free software project (with hundreds of
people from all skills and all languages). We (obviously) try to take any step
we can do to remove friction with tools, but language is an important factor
that we often under-estimate.

~~~
sytse
Thanks for the kind words. As mentioned in the release post we
Internationalized Cycle Analytics. More translations are forthcoming.

------
CiPHPerCoder
I'm seriously considering switching to Gitlab. Multiple assignees makes sense
for large projects.

~~~
charlietuna
GitHub's had multiple assignees since last year:
[https://github.com/blog/2178-multiple-assignees-on-issues-
an...](https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-
requests)

I mean, switch if you want to switch. But I hope that that is not your main
reason.

~~~
CiPHPerCoder
I've had other reasons to want to switch. It's still not enough to pull the
trigger though.

~~~
sytse
What would make you switch?

~~~
dman
For me getting something done for => [https://gitlab.com/gitlab-org/gitlab-
ee/issues/1020](https://gitlab.com/gitlab-org/gitlab-ee/issues/1020)

Patiently waiting for this since I reported this request to you in
[https://news.ycombinator.com/item?id=11092066](https://news.ycombinator.com/item?id=11092066)
:)

Unfortunately somewhere along the way this was turned into an enterprise
edition ticket. Would be nice to have this available for my personal install
as well.

~~~
joshlambert
We are looking at the performance metrics over time now, based on the
monitoring work we are doing.

What tools are you using to do your testing now?

~~~
dman
Append to a sqlite database and have some adhoc queries on top of it.

------
orf
Very excited about official gitlab Helm charts! Awesome work.

Just tried it out and was hit by the `gitlab` service not starting due to:
"PersistentVolumeClaim is not bound, which was unexpected."

Shame, I'll try it in a few releases and see if it's improved.

~~~
joshlambert
Hi orf,

Thanks for giving our Helm charts a try! That is actually a temporary error,
because the pod is waiting on the underlying storage to provision.

If you wait a few minutes, the underlying PVC will finish provisioning and the
pod will automatically retry starting. At that point it should succeed.

We will update our documentation to include this, sorry for the confusion.

~~~
orf
Hey Josh, I'm running it on Minikube though and the storage had provisioned
without error. Perhaps I needed to allocate more disk space to my minikube
instance (the default is only 20g), it would be good to include that in the
documentation as well!

Minikube will be the gateway to most people trying this I assume. As such,
you'd need to increase the default CPU/RAM/Disk for Minikube:

minikube start --disk-size 80g --cpus 4 --memory 4080

~~~
joshlambert
Thanks orf, you are exactly right. The requirements exceed the minikube
defaults, we will add this to the documentation as well.

~~~
sytse
This was done in [https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/11624](https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/11624)

~~~
orf
Thanks for the quick turnaround! I'm not sure this is the issue though:

[https://gitlab.com/gitlab-org/gitlab-
ce/issues/32773](https://gitlab.com/gitlab-org/gitlab-ce/issues/32773)

