[HN Gopher] Beautifying our UI: Giving Gitlab build features a f...
___________________________________________________________________
Beautifying our UI: Giving Gitlab build features a fresh look
Author : mikece
Score : 65 points
Date : 2023-07-05 17:50 UTC (5 hours ago)
(HTM) web link (about.gitlab.com)
(TXT) w3m dump (about.gitlab.com)
| seanlaff wrote:
| 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}/pip
| elines/${GITLAB_PIPELINE}/jobs?per_page=100&private_token=${GITLA
| B_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"
| stabbles wrote:
| I think you have to remove escaping: `\\*` should be `*`
| dnsmichi wrote:
| 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
| 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_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_14584...
| saurik wrote:
| 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_39...
| dnsmichi wrote:
| Oh, thanks, I read it wrong. Thanks for digging up the
| source, I want to be sure to give attribution where due.
|
| Fantastic insights in the issue, next to the scripts. One
| could write a script that generates Mermaid charts in
| Markdown, and document the CI/CD infrastructure
| automatically - with CI/CD pipelines itself. Hmmm :)
| seanlaff wrote:
| Ah yup, looks like @saurik pin-pointed my original source
| (iirc I slightly tweaked the jq, but you get the idea).
| Please do spread the idea- I would love capability native
| like this in gitlab.
| michaelmior wrote:
| Note that for non-Chrome users, you can also view traces at
| https://ui.perfetto.dev/.
| ellisd wrote:
| 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
|
| We would effectively need to roll up the child pipeline's results
| manually in the parent pipeline by calling APIs ourselves.
| andy_ppp wrote:
| 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 wrote:
| What do you mean by jobs == VMs?
|
| I thought gitlab ci was mostly containers.
| hhh wrote:
| You choose what you want it to be.
|
| https://docs.gitlab.com/runner/executors/
| CameronNemo wrote:
| Sure, but the hosted runners use the docker executor IIRC
| and container-based executors are quite common.
| klysm wrote:
| AI fomo takes priority sorry
| Sayrus wrote:
| I've been following that Epic and the issue it is based on
| since 2021 (which is how I found your comment). It's been a
| roller-coaster which grew from small issues to a giant epic. A
| few times a week, I get an email about it hoping it's finally a
| patch for the artifact type I'm using. In the end, I manually
| roll up all artifacts to the parent pipeline and have a MRs
| ready in case the feature is released.
|
| There are quite a few issues I follow, sometimes they are very
| small, sometimes they are huge epics. While I love GitLab and
| GitLab CI, I find myself hitting some of these frustrating
| issues nearly every time I do something uncommon.
|
| They usually end up being delivered and well done, which is to
| the credit of the awesome folks at GitLab, but they rarely take
| less than a few years.
| kyrofa wrote:
| Yeah I finally just stopped watching that issue. I would get a
| few emails a week that is just some gitlab sales person saying
| "another customer interested in this" over and over. It's
| become pretty obvious that it has lost its internal champion,
| whoever that was. Parent/child was very close to a very cool
| feature.
| octopoc wrote:
| 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.
| georgekin wrote:
| 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/.
|
| 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 :)
| physicsguy wrote:
| 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
| chaxor wrote:
| Gitlab is great.
|
| In terms of UI, I would love to see more adoption of TUIs similar
| to soft-serve.
|
| https://github.com/charmbracelet/
| SebastianKra wrote:
| 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.
| cschmatzler wrote:
| 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.
| smcleod wrote:
| GitHub has gotten so much worse over the last few years.
| Actions feels like it was thrown together with little to no
| thought as to the user or product journey.
| chaxor wrote:
| 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 wrote:
| 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.
| beardedman wrote:
| 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 wrote:
| 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 [2]
| https://about.gitlab.com/company/okrs/fy24-q2/#okrs
| beardedman wrote:
| 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.
| andy_ppp wrote:
| 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 wrote:
| yeah , they chase future after future instead of focusing on
| their core stuff
| hanniabu wrote:
| From the images it seems they removed the "latest" tags yet no
| comment on it in the post
| richbell wrote:
| 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.
| dnsmichi wrote:
| 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_14... (also linked in the
| blog post). Feel free to add more details and thoughts.
| Thanks!
| hanniabu wrote:
| 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.
| robertlagrant wrote:
| 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.
| RedShift1 wrote:
| That's just how it is these days, designers that don't use
| the product making decisions for those that do.
| verdverm wrote:
| 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"
| dnsmichi wrote:
| 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_14...
| sugaroverflow wrote:
| 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-....
| smcleod wrote:
| 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 wrote:
| 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 wrote:
| 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/)
|
| - 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.
| pavon wrote:
| 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 wrote:
| 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 and let our teams
| know to update the blog post.
___________________________________________________________________
(page generated 2023-07-05 23:01 UTC)