As a customer, I love the integrated CI and how easily I can now run tests for each commit and show pass/fail and coverage information right on the commit. We used to use Stash and Jenkins, but it was pretty hard to get the integration to work reliably.
Another thing I love is the gitlab-runner, which lets me spin up a machine and have another server to run tests on.
What I really don't love is how limited issues feel compared to JIRA. Namely, the following workflow is so hard it might as well be impossible:
* Issue gets opened by a user/assigned to a developer.
* Developer has a view that's only issues that they haven't worked on or that they're working on.
* After the issue has been worked on, the developer can assign it back to QA.
* QA retests and closes.
This was very well served with JIRA's open -> in progress -> resolved -> closed pipeline, as well as with the views that could filter things like "show me issues assigned to me or nobody, that are not resolved or closed, ordered by priority".
We tried to do something similar with labels and the board, but it's really inconvenient, because we can't filter for "show me issues that are NOT <something>". We used a "new" label instead, but the board doesn't know that "new" is the backlog and that that label should be removed when the issue moves out of the former.
In general, we've been having problems with issues, although the milestone view is pretty fantastic.
> show me issues assigned to me or nobody, that are not resolved or closed, ordered by priority
Right now, GitLab orders by priority out of the box on the board. You can filter for yourself or assigned to nobody. Not both, but we're working on improving the filters (including the option to do "NOT X OR Y". [0]
> We used a "new" label instead, but the board doesn't know that "new" is the backlog and that that label should be removed when the issue moves out of the former.
Just create a list with the 'new' label and you should be good, right?
We're thinking about having different types of lists in Boards, such as 'Milestone boards' and 'Status boards'. Something like that could solve some of your requests as well.
> Just create a list with the 'new' label and you should be good, right?
Yes, but then you have a "backlog" and a "new" list, which are no different, and yet distinct :/
> Not both, but we're working on improving the filters (including the option to do "NOT X OR Y". [0]
That's fantastic, logical operators would be a great feature.
> We're thinking about having different types of lists in Boards, such as 'Milestone boards' and 'Status boards'. Something like that could solve some of your requests as well.
I think that, if you have powerful filtering functionality, then everything could just be a filter. E.g. a board would be a list of filters with two actions or an associated label (i.e. "show me all issues that are X AND Y (OR NOT Z)", and assign label B when an issue is added here and unassign it when removed). Issue lists could similarly just be a filter view ("show me the issues with assignee=me or assignee=none and status=new or not status=closed"), etc.
There are so many good things that it would be time consuming to make a list, but your general attitude and philosophy percolates through the product.
What could be better? Time management and planning (which is different from deadlines).
We're dreaming of some sort of "automatic milestones" (we use weeks) that allow us to put issues in "next time unit of work" (and eventually "subsequent time units of work") at the beginning of the week. Currently we create (and close) "%year-%week"-numbered milestones each week, for each relevant project, and that's extremely heavyweight to manage.
Such a workflow where you fill buckets by eyeballing tasks allows us to have a coarse grained estimate of when will things be done (weeks are quite a natural unit for that esp. when communicating to upper management or customers in a language they speak: "we don't have room for week 36 so this'll be done by week 37") as well as a bird's eye view with the cross-project milestones.
A very interesting idea! Feel free to suggest a minimal implementation for this and we'd be happy to look into building it. I shy away from introducing too many new variables, so something that could leverage milestones would be probably the best.
Not closely related, but you hit the keyword 'Time', we're planning to build time tracking for GitLab soon [0].
> Feel free to suggest a minimal implementation for this and we'd be happy to look into building it. I shy away from introducing too many new variables, so something that could leverage milestones would be probably the best.
Agreed. I may look into it but I've got an unending backlog of FOSS things (with a couple pertaining to GitLab[0]) and while this is of high interest internally work on this is restricted by policy, so that's solely on my spare time.
> Not closely related, but you hit the keyword 'Time', we're planning to build time tracking for GitLab soon
The fact that I can use the CI in one tab to build docker images in another tab and host them right next to the repository in another tab was absolutely killer.
Also, GitLab community is free (!) and imports very well from GitHub.
I love that I can just to this in .gitlab-ci.yml before pushing:
One middle-to-major annoyance I still have with gitlab though, is that merge requests across forks aren't visible from any automation via the destination repo. That is, if a bot account has access to the prod repo to perform CI builds, and somebody opens a MR from a private fork, the bot can't see it.
This has made us adjust our workflow for pretty much all prod repos to push branches to be reviewed under a review/* branch on the destination repo, which is cumbersome and requires additional permissions.
GitHub makes all pull requests available as branches on the destination repo via the refs/pulls/* namespace, and that's been really useful. It'd be awesome if gitlab had this too!
~~Ah this is a good improvement that we should definitely pick up on the short term. I've added it to [0] for now, but I'll look into this more later, I'm sure that we've thought / planned about this before.~~
