6 ms·

Beautifying our UI: Giving Gitlab build features a fresh look

89 points by mikece 3y ago

deleted 3y ago
[deleted]
hanniabu 3y ago
From the images it seems they removed the "latest" tags yet no comment on it in the post
- richbell 3y ago
  In general it seems like they removed information and made the UI more dense. While the "before" pipeline header did have a lot of wasted space, the "after" makes it harder to visually differentiate things, imo.
  - hanniabu 3y ago
    Agreed, I hate when UX is ruined just for the sake of design. It blows my mind how these decisions are made. I mean, Gitlab has to have a product team, right? They must not be technical or have experience using the product. Either that or they need to find a new UX researcher to conduct better user interviews earlier in the development process.
    - verdverm 3y ago
      This, to me, seems like an example of a larger trend... GitHub is guilty too Designers aiming to impress their peers over basic UX principles. They all need to go back and (re)read "Don't Make Me Think"
    - RedShift1 3y ago
      That's just how it is these days, designers that don't use the product making decisions for those that do.
    - robertlagrant 3y ago
      The whole blog post is written as though a major engineering effort has taken place, which a) might have happened, but that would be odd from what is shown in the screenshots, or b) hasn't happened, but is the sort of major transformational change that UX consultancies churn 'em out to speak about. And, as you say, almost all of seem almost entirely focused on UI design.
  - dnsmichi 3y ago
    GitLab team member here. Thanks for your feedback. I have copied it into the feedback issue https://gitlab.com/gitlab-org/gitlab/-/issues/414756#note_1458839621 https://gitlab.com/gitlab-org/gitlab/-/issues/414756#note_14... (also linked in the blog post). Feel free to add more details and thoughts. Thanks!
- dnsmichi 3y ago
  GitLab team member here. Thanks for the feedback. The picture in the blog post needs an update. I just checked a running pipeline that shows the green `latest` label. Added a screenshot of the pipeline, and the update suggestions for our teams into https://gitlab.com/gitlab-org/gitlab/-/issues/414756#note_1458858853 https://gitlab.com/gitlab-org/gitlab/-/issues/414756#note_14...
  - sugaroverflow 3y ago
    Another GitLab team member here :) Thanks again for the feedback! We've updated the image in the blog post: https://about.gitlab.com/blog/2023/07/05/beautifying-of-our-ui/ https://about.gitlab.com/blog/2023/07/05/beautifying-of-our-....
seanlaff 3y ago
Im surprised there's still no "trace" view of pipeline execution, especially with how prevalent DAG pipelines have become. Somewhere on the internet I found this handy jq oneliner that will convert a pipeline into a format you can drag and drop into chrome://tracing/ to figure out where your bottlenecks are curl "https://${GITLAB_URL}/api/v4/projects/${GITLAB_PROJECT}/pipelines/${GITLAB_PIPELINE}/jobs?per_page=100&private_token=${GITLAB_TOKEN}" | jq 'map([select(.started_at and .finished_at) | {name: (.stage + ": " + .name), cat: "PERF", ph: "B", pid: .pipeline.id, tid: .id, ts: (.started_at | sub("\\.[0-9]+Z$"; "Z") | fromdate \* 10e5)}, {name: (.stage + ": " + .name), cat: "PERF", ph: "E", pid: .pipeline.id, tid: .id, ts: (.finished_at | sub("\\.[0-9]+Z$"; "Z") | fromdate \* 10e5)}]) | flatten(1) | .[]' | jq -s > "${GITLAB_PIPELINE}-trace.txt"
- dnsmichi 3y ago
  Wow, thanks a lot for sharing. GitLab team member here. Would it be ok for you if I add that command snippet into a blog post I am currently writing about Observability for Efficient DevSecOps Pipelines? Draft MR is in https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/34296 https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/34296 Thanks! Regarding pipeline visibility and traces: I would love to see the same :-) I tested tracepusher with OpenTelemetry this week, and the timeline for CI/CD traces is a great start in Jaeger. Added a suggestion into https://gitlab.com/groups/gitlab-org/-/epics/5071#note_1458202771 https://gitlab.com/groups/gitlab-org/-/epics/5071#note_14582... where CI/CD Visibility is being worked on, with an update on GitLab support for traces in https://gitlab.com/groups/gitlab-org/-/epics/5071#note_1458453909 https://gitlab.com/groups/gitlab-org/-/epics/5071#note_14584...
  - saurik 3y ago
    FWIW, they had said that they didn't write it originally and had found it "somewhere on the Internet". Searching for "pid: .pipeline.id, tid: .id, ts" has turned up this, which might be the original source (if it is in fact the same script as I am on a phone and didn't 100% check): https://gitlab.com/gitlab-org/gitlab/-/issues/236018#note_398910317 https://gitlab.com/gitlab-org/gitlab/-/issues/236018#note_39...
ellisd 3y ago
Dear Gitlab... please focus on finishing out your parent/child pipeline concepts. I'm very disappointed to see basic CI capabilities missing in 2023. None of the shiny AI things matter if CI isn't solid. Today parent pipelines cannot consume any test report from the child pipeline using the Gitlab CI DSL: https://gitlab.com/groups/gitlab-org/-/epics/8205 https://gitlab.com/groups/gitlab-org/-/epics/8205 We would effectively need to roll up the child pipeline's results manually in the parent pipeline by calling APIs ourselves.
- klysm 3y ago
  AI fomo takes priority sorry
- andy_ppp 3y ago
  Gitlab CI is so weird man, depending on where you are workflow/rules and so on seems to have very different effects. The obsession it is has making jobs === VMs is also mind bending, why so many virtual machines for one pipeline! You can't consolidate child pipeline reporting up to a higher level - all the data is there in the UI but hidden. There were loads of other things. Github Actions which is largely free (if you use your own runners) is much better.
  - CameronNemo 3y ago
    What do you mean by jobs == VMs? I thought gitlab ci was mostly containers.
    - hhh 3y ago
      You choose what you want it to be. https://docs.gitlab.com/runner/executors/ https://docs.gitlab.com/runner/executors/
      - CameronNemo 3y ago
        Sure, but the hosted runners use the docker executor IIRC and container-based executors are quite common.
SebastianKra 3y ago
This (and GitLabs UI in general) does not compare well to GitHub. The most obvious difference is GitHubs better sense of visual hierarchy due to smart usage of shadows, shaded backgrounds, and colors. But GitHub also understands which information to emphasise, and what to hide. In contrast, GitLabs UI often feels like they scattered as much information as they could, with no thought to placement and grouping. For example, in the before, why is the number of jobs displayed next to the MR, and then the MR is displayed again further down? They're also often unnecessarily explicit: spelling out "3 minutes, 12 seconds" instead of "3m 12s" and using full sentences instead of definition lists.
- chaxor 3y ago
  GitHub has been getting far more clunky IMO. It takes a very long time to load almost every time I try to go to any GitHub page. Why does it take 2 mins to show what amounts to an 'ls' command? My guess is the ever increasing feature creep of the web.
- viiralvx 3y ago
  From what I see, it highlights a difference in design cultures between the organizations. GitHub has an amazing Product Design organization who have really evolved the product from the early days to what it is today. When I look at GitLab's UI, I get a feeling that it's a UI that feels designed by an engineer without much thought about these design principles you mentioned. It would take a huge overhaul of their design team, culture, and code for GitLab to bring their UI up to par.
- cschmatzler 3y ago
  Using GitLab EE at work and GitHub for side projects, the difference is genuinely shocking. I love tinkering with CI usually but using GitLab I actively try to avoid it.
  - andrewstuart2 3y ago
    I mean, CI is probably not where you want people to be getting their dopamine hits. I've found that the absolute simplest CI pipeline is the best CI pipeline. Sometimes just a single make command with the right tools preinstalled into a container image is the best. But the more you feel like you've learned something new or accomplished something complex, the more challenging it's going to be to work with your project in local dev and in CICD, and the more work it'll be to maintain in the future as dependency additions necessitate build changes.
pavon 3y ago
Is it just coincidence that all the builds in the "after" screenshot for the pipeline lists are MR builds, or have the details of whether a build is for a tag, branch or MR been removed? That is the main thing I look at when skimming that list to determine whether I care about a failed build.
- dnsmichi 3y ago
  GitLab team member here. Apologies, that is a bug in the screenshots, I checked the latest pipeline tag working in https://news.ycombinator.com/item?id=36605418 https://news.ycombinator.com/item?id=36605418 and let our teams know to update the blog post.
chaxor 3y ago
Gitlab is great. In terms of UI, I would love to see more adoption of TUIs similar to soft-serve. https://github.com/charmbracelet/ https://github.com/charmbracelet/
- brodock 3y ago
  That looks awesome. You could try https://gitlab.com/gitlab-org/cli https://gitlab.com/gitlab-org/cli, not near as good, but allow you to avoid the web UI for most things.
andy_ppp 3y ago
Gitlab seem to be a company obsessed with feature parity with others rather than making their software make sense and actually work. I wish they would stop following others and parroting features, instead a few conversations with your customers and they would happily tell you where things are not working well!
- merb 3y ago
  yeah , they chase future after future instead of focusing on their core stuff
  - apple4ever 3y ago
    Ya they have a lot of bugs and issues that they should focus on instead. I get new features can bring new users, but bugs drives away old users. They should do an even/odd bug fix/new feature release cadence.
  - VectorLock 3y ago
    You can see a trail of half-baked and forgotten features, like Runbooks.
beardedman 3y ago
I would love to know how dev resources are being spent there. Feels like every blog article these days is touting some small enhancement as some big feature. Meanwhile GitHub is pushing out actual new features.
- sugaroverflow 3y ago
  Hey, GitLab team member here. We have a high level roadmap for FY24 in our handbook[1] and our OKRs are listed publicly[2] so you can see our vision for the product and what we're working on. [1] https://about.gitlab.com/direction/#fy24-roadmap https://about.gitlab.com/direction/#fy24-roadmap [2] https://about.gitlab.com/company/okrs/fy24-q2/#okrs https://about.gitlab.com/company/okrs/fy24-q2/#okrs
  - beardedman 3y ago
    Appreciate the comment, but just genuinely curious. You guys seem to be clamping down on freemium, but not really landing any valuable "hooks" (product-wise). Would something like a better overall project management experience not be more urgent than a command pallete? Not to be nitpicky, but GH now has a scheduler component on top of custom fields - not amazing, but adds a ton of flexibility.
smcleod 3y ago
I really wish I was working on Gitlab every day rather than GitHub / Actions. Gitlab’s UI / UX is so much less hostile to the user. It’s a real shame that Gitlab’s pricing went up so much. I have no doubt that many of the clients I work with that are wasting countless hours trying to add core functionality and reliability to GitHub Actions would be on Gitlab.
- pyrophane 3y ago
  Could you elaborate a bit on what you don't like about GH Actions? Just curious as I have a lot of experience with Gitlab CI and relatively less with GH Actions.
  - smcleod 3y ago
    Oh gosh where do I even start. Actually, I was recently writing up a list of issues that the teams I work with have with it the other day. I'll share it here however I'll have to post an update to later as it's missing one of my sources. Github is aware of (and somewhat accepts) every one of these items. -There are frequent outages (several times a week, sometimes daily) to Github Actions APIs that result in people having to retry workflows that are stuck, slow or fail due to some upstream Github issue. - There's no way to manage the settings of repos in code (e.g. protected branches, status checks, etc) - this is a huge pain point for us as we have to manually set these things up for each repo and branch. - If someone makes a comment on a PR and the author pushes new changes to the PR the conversation doesn't show in the PRs diff, nor do other peoples unresolved comments - but they are all still required to be resolved/closed before a merge can occur - this is not at all obvious to the reviewer or the author. - There's no deployments dashboard to see what is deployed where and what the status of those deployments are. - There's no concept of application health as part of a repo, the code is very disconnected from what is actually deployed. - Notifications are a mess - you can't easily see what notifications you have set up and for what repos. You can't manage them in code. There's so much noise in the notifications that it's hard to see what's important - almost all of them end up getting missed. - There's no way to manage the secrets in code - you have to manually set them up for each repo. - Linting Github Actions workflows is unreliable even using Github/Microsoft's own VSCode and Github Actions plugins. - There is no easy to use way of testing Actions locally or on a branch. - Scheduled workflows only ever run from the default branch. - There's no internal or private Actions marketplace. - Reusing code is an absolute mess, Composite Actions vs Reusable Workflows vs Actions - all slightly different with different edge cases and limitations. (See https://smcleod.net/2022/11/github-not-so-reusable-actions/ https://smcleod.net/2022/11/github-not-so-reusable-actions/) - Standard YAML anchors aren't supported. - There's no way to manage the status checks that must pass across a given set of repos for a team, you have to do them all one by one for each branch that is protected.... - There's no concept of grouping repositories for a project, team or product. - "The console log (which is a critical part of any CI system) is incredibly buggy - often sitting there blank for 10 mins with no output. - Not easy to audit who has made changes or version control settings in the UI. - Retrying a job that failed on an upstream action/workflow after it has been fixed - results in the previous version being used again silently without warning and no option to use latest version. - Custom roles locked down to org admins. - No ability for engineers to update / replace secrets without granting them full blown admin access. - You can't set per-workflow timeouts. - If you're investigating an issue in the console output and the run ends the output is collapsed and you lose what you're looking at and have to find it again. There’s a lot more I can add later.
georgekin 3y ago
A problem I've run into with GitLab is that it's quite annoying to view the variables of multiple projects and environments in one place. Projects inherit the variables of their parents, which means that getting a view of which variables apply to a particular project in an environment requires spelunking around the UI and working it out. I figured I'd build my own UI to solve that, so I did. It's here: https://geevee.netlify.app/ https://geevee.netlify.app/. A benefit it has over a native GitLab UI is that it downloads and caches the project/group hierarchy in local storage (it's entirely client side), and can be refreshed on demand. It groups variables by environment mask and gives you a view of the entire variable hierarchy for a project. Maybe some others might find it useful :)
- matrixagent 3y ago
  Do you have an example screenshot somewhere? I'm wondering what exactly this does that GitLab doesn't, because inherited variables are shown within GitLab UI directly – fairly barebones, though, so I'm curious to see your UI in action. (I work at GitLab, but not on this – just a big CI fan myself.)
  - georgekin 3y ago
    Thanks for the interest - I created some groups and uploaded a demo to the repository (https://github.com/gkinsman/GeeVee/blob/main/README.md https://github.com/gkinsman/GeeVee/blob/main/README.md). Unfortunately environment scopes are only available on premium so I can't demonstrate that, but it solves one of the major issues with the existing UI in that it doesn't give you an environment-centric variable view. Also, it looks like it's only possible to view inherited variables when viewing the vars for a project. Group's don't show the inherited variables for their parents. I also much prefer the project tree view to clicking around the gitlab UI so much, and when you're configuring a pipeline its quite tedious.
    - matrixagent 3y ago
      Thanks, sorry for the late response – busy week. Good point, wasn't even aware that the inherited variable view is only shown in projects but not subgroups. On a quick glance I couldn't find an existing feature proposal to add it at the subgroup level as well… but that might be because the search terms aren't terribly unique. I'll show your demo to the team handling CI secrets, thanks again for sharing! :)
octopoc 3y ago
GitHub and GitLab have so many features, it's kind of unfortunate they you have to pick one or the other. I would prefer a world where these tools were built with the Unix mindset--one tool for each task, that does that task well. That way I could pick, say, GitLab's PRs with GitHub's issues, etc. In the meantime, I am more than thankful for an alternative to the GitHubiverse, and I am progressively trying to wean myself off it onto GitLabia. I just wish I could have both.
physicsguy 3y ago
I struggle to see why they’d focus on things like this when missing features like this [1] go unresolved for years and prevent big enterprise customers from migrating… [1] https://gitlab.com/gitlab-org/gitlab/-/issues/29674 https://gitlab.com/gitlab-org/gitlab/-/issues/29674
timetraveller26 3y ago
Lipstick on a pig
whoopsie 3y ago
“… completely redesign the…” “This work was substantial…” I struggled to spot the differences between the before and after. In my company, “complete redesign” has a totally different meaning.
Banditoz 3y ago
Is anyone using Gitea or Forgejo? (the latter is a fork, I believe) They both seem like interesting/lightweight alternatives to GitHub/Gitlab. https://about.gitea.com/ https://about.gitea.com/ https://forgejo.org/ https://forgejo.org/
2h 3y ago
all I want, is the number of contributions in the last year, like GitHub has: https://gitlab.com/gitlab-org/gitlab/-/issues/22578 https://gitlab.com/gitlab-org/gitlab/-/issues/22578 its just one number, I just wish they could add this one little thing so I could move away from GitHub once and for all. even CodeBerg has it: https://codeberg.org/teddit?tab=activity https://codeberg.org/teddit?tab=activity
exabrial 3y ago
We're forever in a race to refresh looks.
deng 3y ago
And yet, you still cannot filter jobs by name. It's frankly ridiculous by now. https://gitlab.com/gitlab-org/gitlab/-/issues/22027 https://gitlab.com/gitlab-org/gitlab/-/issues/22027
- dnsmichi 3y ago
  GitLab team member here. Thanks for your feedback. I have added a note into the issue https://gitlab.com/gitlab-org/gitlab/-/issues/22027#note_1460046587 https://gitlab.com/gitlab-org/gitlab/-/issues/22027#note_146... and pinged our teams.
  - deng 3y ago
    Thanks. This was also requested for the UI 7 years ago https://gitlab.com/gitlab-org/gitlab-foss/-/issues/12776 https://gitlab.com/gitlab-org/gitlab-foss/-/issues/12776 and then closed with the claim that this was implemented, when in fact, it was not.
- apple4ever 3y ago
  Their search is pretty bad, agreed (and coming from a GitLab lover that is telling you something). For example, searching MRs doesn't let you search multiple fields.
- jakub_g 3y ago
  FWIW if you use Datadog, the "CI Visibility" product allows to query GitLab jobs by name, status, duration etc. (as well as set up alerting on all this). (One current limitation though is that only finished pipelines show up, no ongoing ones).
penguin_booze 3y ago
At $WORK, someone upstairs decided to ditch Bitbucket to go for Gitlab. Boy do we curse every single day! In comparison, Gitlab UI is way too cluttered, and focuses on being fancy rather than productive. It's even buggy here and there: lines don't line up with line numbers, source lines displayed wrongly indented when they're not, fails to save comments, to list a few. One thing we particuarly miss from the Bitbuket days is the ability to link to multiple ranges of lines. Gitlab can only do a single range, as if it's doing charity. If you ask me, they'd have to pay me pretty heavy sum to use their product.

89 points by mikece 3y ago

deleted 3y ago

[deleted]

hanniabu 3y ago

From the images it seems they removed the "latest" tags yet no comment on it in the post

richbell 3y ago
In general it seems like they removed information and made the UI more dense. While the "before" pipeline header did have a lot of wasted space, the "after" makes it harder to visually differentiate things, imo.
- hanniabu 3y ago
  Agreed, I hate when UX is ruined just for the sake of design. It blows my mind how these decisions are made. I mean, Gitlab has to have a product team, right? They must not be technical or have experience using the product. Either that or they need to find a new UX researcher to conduct better user interviews earlier in the development process.
  - verdverm 3y ago
    This, to me, seems like an example of a larger trend... GitHub is guilty too Designers aiming to impress their peers over basic UX principles. They all need to go back and (re)read "Don't Make Me Think"
  - RedShift1 3y ago
    That's just how it is these days, designers that don't use the product making decisions for those that do.
  - robertlagrant 3y ago
    The whole blog post is written as though a major engineering effort has taken place, which a) might have happened, but that would be odd from what is shown in the screenshots, or b) hasn't happened, but is the sort of major transformational change that UX consultancies churn 'em out to speak about. And, as you say, almost all of seem almost entirely focused on UI design.
- dnsmichi 3y ago
  GitLab team member here. Thanks for your feedback. I have copied it into the feedback issue https://gitlab.com/gitlab-org/gitlab/-/issues/414756#note_1458839621 https://gitlab.com/gitlab-org/gitlab/-/issues/414756#note_14... (also linked in the blog post). Feel free to add more details and thoughts. Thanks!
dnsmichi 3y ago
GitLab team member here. Thanks for the feedback. The picture in the blog post needs an update. I just checked a running pipeline that shows the green `latest` label. Added a screenshot of the pipeline, and the update suggestions for our teams into https://gitlab.com/gitlab-org/gitlab/-/issues/414756#note_1458858853 https://gitlab.com/gitlab-org/gitlab/-/issues/414756#note_14...
- sugaroverflow 3y ago
  Another GitLab team member here :) Thanks again for the feedback! We've updated the image in the blog post: https://about.gitlab.com/blog/2023/07/05/beautifying-of-our-ui/ https://about.gitlab.com/blog/2023/07/05/beautifying-of-our-....

seanlaff 3y ago

Im surprised there's still no "trace" view of pipeline execution, especially with how prevalent DAG pipelines have become. Somewhere on the internet I found this handy jq oneliner that will convert a pipeline into a format you can drag and drop into chrome://tracing/ to figure out where your bottlenecks are curl "https://${GITLAB_URL}/api/v4/projects/${GITLAB_PROJECT}/pipelines/${GITLAB_PIPELINE}/jobs?per_page=100&private_token=${GITLAB_TOKEN}" | jq 'map([select(.started_at and .finished_at) | {name: (.stage + ": " + .name), cat: "PERF", ph: "B", pid: .pipeline.id, tid: .id, ts: (.started_at | sub("\\.[0-9]+Z$"; "Z") | fromdate \* 10e5)}, {name: (.stage + ": " + .name), cat: "PERF", ph: "E", pid: .pipeline.id, tid: .id, ts: (.finished_at | sub("\\.[0-9]+Z$"; "Z") | fromdate \* 10e5)}]) | flatten(1) | .[]' | jq -s > "${GITLAB_PIPELINE}-trace.txt"

dnsmichi 3y ago
Wow, thanks a lot for sharing. GitLab team member here. Would it be ok for you if I add that command snippet into a blog post I am currently writing about Observability for Efficient DevSecOps Pipelines? Draft MR is in https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/34296 https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/34296 Thanks! Regarding pipeline visibility and traces: I would love to see the same :-) I tested tracepusher with OpenTelemetry this week, and the timeline for CI/CD traces is a great start in Jaeger. Added a suggestion into https://gitlab.com/groups/gitlab-org/-/epics/5071#note_1458202771 https://gitlab.com/groups/gitlab-org/-/epics/5071#note_14582... where CI/CD Visibility is being worked on, with an update on GitLab support for traces in https://gitlab.com/groups/gitlab-org/-/epics/5071#note_1458453909 https://gitlab.com/groups/gitlab-org/-/epics/5071#note_14584...
- saurik 3y ago
  FWIW, they had said that they didn't write it originally and had found it "somewhere on the Internet". Searching for "pid: .pipeline.id, tid: .id, ts" has turned up this, which might be the original source (if it is in fact the same script as I am on a phone and didn't 100% check): https://gitlab.com/gitlab-org/gitlab/-/issues/236018#note_398910317 https://gitlab.com/gitlab-org/gitlab/-/issues/236018#note_39...

ellisd 3y ago

Dear Gitlab... please focus on finishing out your parent/child pipeline concepts. I'm very disappointed to see basic CI capabilities missing in 2023. None of the shiny AI things matter if CI isn't solid. Today parent pipelines cannot consume any test report from the child pipeline using the Gitlab CI DSL: https://gitlab.com/groups/gitlab-org/-/epics/8205 https://gitlab.com/groups/gitlab-org/-/epics/8205 We would effectively need to roll up the child pipeline's results manually in the parent pipeline by calling APIs ourselves.

klysm 3y ago
AI fomo takes priority sorry
andy_ppp 3y ago
Gitlab CI is so weird man, depending on where you are workflow/rules and so on seems to have very different effects. The obsession it is has making jobs === VMs is also mind bending, why so many virtual machines for one pipeline! You can't consolidate child pipeline reporting up to a higher level - all the data is there in the UI but hidden. There were loads of other things. Github Actions which is largely free (if you use your own runners) is much better.
- CameronNemo 3y ago
  What do you mean by jobs == VMs? I thought gitlab ci was mostly containers.
  - hhh 3y ago
    You choose what you want it to be. https://docs.gitlab.com/runner/executors/ https://docs.gitlab.com/runner/executors/
    - CameronNemo 3y ago
      Sure, but the hosted runners use the docker executor IIRC and container-based executors are quite common.

SebastianKra 3y ago

This (and GitLabs UI in general) does not compare well to GitHub. The most obvious difference is GitHubs better sense of visual hierarchy due to smart usage of shadows, shaded backgrounds, and colors. But GitHub also understands which information to emphasise, and what to hide. In contrast, GitLabs UI often feels like they scattered as much information as they could, with no thought to placement and grouping. For example, in the before, why is the number of jobs displayed next to the MR, and then the MR is displayed again further down? They're also often unnecessarily explicit: spelling out "3 minutes, 12 seconds" instead of "3m 12s" and using full sentences instead of definition lists.

chaxor 3y ago
GitHub has been getting far more clunky IMO. It takes a very long time to load almost every time I try to go to any GitHub page. Why does it take 2 mins to show what amounts to an 'ls' command? My guess is the ever increasing feature creep of the web.
viiralvx 3y ago
From what I see, it highlights a difference in design cultures between the organizations. GitHub has an amazing Product Design organization who have really evolved the product from the early days to what it is today. When I look at GitLab's UI, I get a feeling that it's a UI that feels designed by an engineer without much thought about these design principles you mentioned. It would take a huge overhaul of their design team, culture, and code for GitLab to bring their UI up to par.
cschmatzler 3y ago
Using GitLab EE at work and GitHub for side projects, the difference is genuinely shocking. I love tinkering with CI usually but using GitLab I actively try to avoid it.
- andrewstuart2 3y ago
  I mean, CI is probably not where you want people to be getting their dopamine hits. I've found that the absolute simplest CI pipeline is the best CI pipeline. Sometimes just a single make command with the right tools preinstalled into a container image is the best. But the more you feel like you've learned something new or accomplished something complex, the more challenging it's going to be to work with your project in local dev and in CICD, and the more work it'll be to maintain in the future as dependency additions necessitate build changes.

pavon 3y ago

Is it just coincidence that all the builds in the "after" screenshot for the pipeline lists are MR builds, or have the details of whether a build is for a tag, branch or MR been removed? That is the main thing I look at when skimming that list to determine whether I care about a failed build.

dnsmichi 3y ago
GitLab team member here. Apologies, that is a bug in the screenshots, I checked the latest pipeline tag working in https://news.ycombinator.com/item?id=36605418 https://news.ycombinator.com/item?id=36605418 and let our teams know to update the blog post.

chaxor 3y ago

Gitlab is great. In terms of UI, I would love to see more adoption of TUIs similar to soft-serve. https://github.com/charmbracelet/ https://github.com/charmbracelet/

brodock 3y ago
That looks awesome. You could try https://gitlab.com/gitlab-org/cli https://gitlab.com/gitlab-org/cli, not near as good, but allow you to avoid the web UI for most things.

andy_ppp 3y ago

Gitlab seem to be a company obsessed with feature parity with others rather than making their software make sense and actually work. I wish they would stop following others and parroting features, instead a few conversations with your customers and they would happily tell you where things are not working well!

merb 3y ago
yeah , they chase future after future instead of focusing on their core stuff
- apple4ever 3y ago
  Ya they have a lot of bugs and issues that they should focus on instead. I get new features can bring new users, but bugs drives away old users. They should do an even/odd bug fix/new feature release cadence.
- VectorLock 3y ago
  You can see a trail of half-baked and forgotten features, like Runbooks.

beardedman 3y ago

I would love to know how dev resources are being spent there. Feels like every blog article these days is touting some small enhancement as some big feature. Meanwhile GitHub is pushing out actual new features.

sugaroverflow 3y ago
Hey, GitLab team member here. We have a high level roadmap for FY24 in our handbook[1] and our OKRs are listed publicly[2] so you can see our vision for the product and what we're working on. [1] https://about.gitlab.com/direction/#fy24-roadmap https://about.gitlab.com/direction/#fy24-roadmap [2] https://about.gitlab.com/company/okrs/fy24-q2/#okrs https://about.gitlab.com/company/okrs/fy24-q2/#okrs
- beardedman 3y ago
  Appreciate the comment, but just genuinely curious. You guys seem to be clamping down on freemium, but not really landing any valuable "hooks" (product-wise). Would something like a better overall project management experience not be more urgent than a command pallete? Not to be nitpicky, but GH now has a scheduler component on top of custom fields - not amazing, but adds a ton of flexibility.

smcleod 3y ago

I really wish I was working on Gitlab every day rather than GitHub / Actions. Gitlab’s UI / UX is so much less hostile to the user. It’s a real shame that Gitlab’s pricing went up so much. I have no doubt that many of the clients I work with that are wasting countless hours trying to add core functionality and reliability to GitHub Actions would be on Gitlab.

pyrophane 3y ago
Could you elaborate a bit on what you don't like about GH Actions? Just curious as I have a lot of experience with Gitlab CI and relatively less with GH Actions.
- smcleod 3y ago
  Oh gosh where do I even start. Actually, I was recently writing up a list of issues that the teams I work with have with it the other day. I'll share it here however I'll have to post an update to later as it's missing one of my sources. Github is aware of (and somewhat accepts) every one of these items. -There are frequent outages (several times a week, sometimes daily) to Github Actions APIs that result in people having to retry workflows that are stuck, slow or fail due to some upstream Github issue. - There's no way to manage the settings of repos in code (e.g. protected branches, status checks, etc) - this is a huge pain point for us as we have to manually set these things up for each repo and branch. - If someone makes a comment on a PR and the author pushes new changes to the PR the conversation doesn't show in the PRs diff, nor do other peoples unresolved comments - but they are all still required to be resolved/closed before a merge can occur - this is not at all obvious to the reviewer or the author. - There's no deployments dashboard to see what is deployed where and what the status of those deployments are. - There's no concept of application health as part of a repo, the code is very disconnected from what is actually deployed. - Notifications are a mess - you can't easily see what notifications you have set up and for what repos. You can't manage them in code. There's so much noise in the notifications that it's hard to see what's important - almost all of them end up getting missed. - There's no way to manage the secrets in code - you have to manually set them up for each repo. - Linting Github Actions workflows is unreliable even using Github/Microsoft's own VSCode and Github Actions plugins. - There is no easy to use way of testing Actions locally or on a branch. - Scheduled workflows only ever run from the default branch. - There's no internal or private Actions marketplace. - Reusing code is an absolute mess, Composite Actions vs Reusable Workflows vs Actions - all slightly different with different edge cases and limitations. (See https://smcleod.net/2022/11/github-not-so-reusable-actions/ https://smcleod.net/2022/11/github-not-so-reusable-actions/) - Standard YAML anchors aren't supported. - There's no way to manage the status checks that must pass across a given set of repos for a team, you have to do them all one by one for each branch that is protected.... - There's no concept of grouping repositories for a project, team or product. - "The console log (which is a critical part of any CI system) is incredibly buggy - often sitting there blank for 10 mins with no output. - Not easy to audit who has made changes or version control settings in the UI. - Retrying a job that failed on an upstream action/workflow after it has been fixed - results in the previous version being used again silently without warning and no option to use latest version. - Custom roles locked down to org admins. - No ability for engineers to update / replace secrets without granting them full blown admin access. - You can't set per-workflow timeouts. - If you're investigating an issue in the console output and the run ends the output is collapsed and you lose what you're looking at and have to find it again. There’s a lot more I can add later.

georgekin 3y ago

A problem I've run into with GitLab is that it's quite annoying to view the variables of multiple projects and environments in one place. Projects inherit the variables of their parents, which means that getting a view of which variables apply to a particular project in an environment requires spelunking around the UI and working it out. I figured I'd build my own UI to solve that, so I did. It's here: https://geevee.netlify.app/ https://geevee.netlify.app/. A benefit it has over a native GitLab UI is that it downloads and caches the project/group hierarchy in local storage (it's entirely client side), and can be refreshed on demand. It groups variables by environment mask and gives you a view of the entire variable hierarchy for a project. Maybe some others might find it useful :)

matrixagent 3y ago
Do you have an example screenshot somewhere? I'm wondering what exactly this does that GitLab doesn't, because inherited variables are shown within GitLab UI directly – fairly barebones, though, so I'm curious to see your UI in action. (I work at GitLab, but not on this – just a big CI fan myself.)
- georgekin 3y ago
  Thanks for the interest - I created some groups and uploaded a demo to the repository (https://github.com/gkinsman/GeeVee/blob/main/README.md https://github.com/gkinsman/GeeVee/blob/main/README.md). Unfortunately environment scopes are only available on premium so I can't demonstrate that, but it solves one of the major issues with the existing UI in that it doesn't give you an environment-centric variable view. Also, it looks like it's only possible to view inherited variables when viewing the vars for a project. Group's don't show the inherited variables for their parents. I also much prefer the project tree view to clicking around the gitlab UI so much, and when you're configuring a pipeline its quite tedious.
  - matrixagent 3y ago
    Thanks, sorry for the late response – busy week. Good point, wasn't even aware that the inherited variable view is only shown in projects but not subgroups. On a quick glance I couldn't find an existing feature proposal to add it at the subgroup level as well… but that might be because the search terms aren't terribly unique. I'll show your demo to the team handling CI secrets, thanks again for sharing! :)

octopoc 3y ago

GitHub and GitLab have so many features, it's kind of unfortunate they you have to pick one or the other. I would prefer a world where these tools were built with the Unix mindset--one tool for each task, that does that task well. That way I could pick, say, GitLab's PRs with GitHub's issues, etc. In the meantime, I am more than thankful for an alternative to the GitHubiverse, and I am progressively trying to wean myself off it onto GitLabia. I just wish I could have both.

physicsguy 3y ago

I struggle to see why they’d focus on things like this when missing features like this [1] go unresolved for years and prevent big enterprise customers from migrating… [1] https://gitlab.com/gitlab-org/gitlab/-/issues/29674 https://gitlab.com/gitlab-org/gitlab/-/issues/29674

timetraveller26 3y ago

Lipstick on a pig

whoopsie 3y ago

“… completely redesign the…” “This work was substantial…” I struggled to spot the differences between the before and after. In my company, “complete redesign” has a totally different meaning.

Banditoz 3y ago

Is anyone using Gitea or Forgejo? (the latter is a fork, I believe) They both seem like interesting/lightweight alternatives to GitHub/Gitlab. https://about.gitea.com/ https://about.gitea.com/ https://forgejo.org/ https://forgejo.org/

2h 3y ago

all I want, is the number of contributions in the last year, like GitHub has: https://gitlab.com/gitlab-org/gitlab/-/issues/22578 https://gitlab.com/gitlab-org/gitlab/-/issues/22578 its just one number, I just wish they could add this one little thing so I could move away from GitHub once and for all. even CodeBerg has it: https://codeberg.org/teddit?tab=activity https://codeberg.org/teddit?tab=activity

exabrial 3y ago

We're forever in a race to refresh looks.

deng 3y ago

And yet, you still cannot filter jobs by name. It's frankly ridiculous by now. https://gitlab.com/gitlab-org/gitlab/-/issues/22027 https://gitlab.com/gitlab-org/gitlab/-/issues/22027

dnsmichi 3y ago
GitLab team member here. Thanks for your feedback. I have added a note into the issue https://gitlab.com/gitlab-org/gitlab/-/issues/22027#note_1460046587 https://gitlab.com/gitlab-org/gitlab/-/issues/22027#note_146... and pinged our teams.
- deng 3y ago
  Thanks. This was also requested for the UI 7 years ago https://gitlab.com/gitlab-org/gitlab-foss/-/issues/12776 https://gitlab.com/gitlab-org/gitlab-foss/-/issues/12776 and then closed with the claim that this was implemented, when in fact, it was not.
apple4ever 3y ago
Their search is pretty bad, agreed (and coming from a GitLab lover that is telling you something). For example, searching MRs doesn't let you search multiple fields.
jakub_g 3y ago
FWIW if you use Datadog, the "CI Visibility" product allows to query GitLab jobs by name, status, duration etc. (as well as set up alerting on all this). (One current limitation though is that only finished pipelines show up, no ongoing ones).

penguin_booze 3y ago

At $WORK, someone upstairs decided to ditch Bitbucket to go for Gitlab. Boy do we curse every single day! In comparison, Gitlab UI is way too cluttered, and focuses on being fancy rather than productive. It's even buggy here and there: lines don't line up with line numbers, source lines displayed wrongly indented when they're not, fails to save comments, to list a few. One thing we particuarly miss from the Bitbuket days is the ability to link to multiple ranges of lines. Gitlab can only do a single range, as if it's doing charity. If you ask me, they'd have to pay me pretty heavy sum to use their product.