
Gitlab 11.10 Released - tpetry
https://about.gitlab.com/2019/04/22/gitlab-11-10-released/
======
jbergstroem
Can't help but feel that their focus on moving all operation insights into
gitlab itself will not be as successful as they want it to be (as far as I
read, their goal was to replace their operations and monitoring tools with
gitlab itself[1]). I've worked with the ultimate edition for a year and the
kubernetes integration is nowhere close to the insight you would get from
google, amazon or azure in terms of insight and integration with ops-land. I
wish all these hours were spent on improving the developer lifecycle instead.

I can understand how their huge success of "built-in CI" quickly leads to
"built-in XYZ", but competing with github that lets other companies solve
developer/ci problems via marketplace (and now CI via their new terraform
actions) may lead to loosing market-leader [my take on their product] position
for a code/test/review/merge ecosystem.

[1]: [https://about.gitlab.com/2018/10/01/gitlab-product-
vision/](https://about.gitlab.com/2018/10/01/gitlab-product-vision/)

~~~
dgruesso
Hi jbergstroem. GitLab PM here. thanks for the feedback. Our vision is indeed
ambitious and we recognize that not all of our categories are yet "complete"
(more on our category maturity here
[https://about.gitlab.com/handbook/product/categories/maturit...](https://about.gitlab.com/handbook/product/categories/maturity/)).
While we are aiming to make GitLab a first class application for operators, we
continue to focus on the developer lifecycle at the same time. You can see
what each of our groups is focusing on upcoming releases here
[https://about.gitlab.com/direction/configure/#upcoming-
relea...](https://about.gitlab.com/direction/configure/#upcoming-releases).
I'd love to learn what areas and level of insight you'd like to see in out
application that would make you consider using it as your daily ops-land
driver. Thanks.

------
numbsafari
GitLab has really come a long way in the past few years. The days of being a
github-alike are long gone. Very happy to see them continue to find success.

~~~
scrollaway
Amen. Gitlab is to GitHub what AWS is to DigitalOcean. GitHub is great don't
get me wrong, especially for open source general releases. But gitlab lets you
actually build pipelines and fully integrate a bunch of services. They're the
best CI/CD service around, honestly, and I think they've been playing to that
strength. On top of that they have excellent project management, which makes
them a lot more suitable than GitHub for company project's imo.

~~~
Scarbutt
Sounds accurate (AWS vs DO), the Github UI/UX is just way better IMO, just
like the DO one is better than AWS one.

~~~
scrollaway
I still have some issues with the Gitlab UX but they've improved it a _lot_ in
the past couple of years. Especially knowing that there are way more features
than a few years prior (and WAY more features than on Github), they manage
really well IMO.

~~~
sytringy05
I dont like the way the breadcrumbs work (do people still use the term
breadcrumb? I'm old) and I've got this one repo that is always on the 2nd page
of the list. That's my gripes about gitlab. I reckon it's a great product.

~~~
baroffoos
Breadcrumbs refer to the link/hierarchy list thing near the tops of pages
which goes something like "org name > project name > issues" and you can click
on one of those to go back to that level. I think you might be thinking of a
different feature.

~~~
sytringy05
no, that's what I was talking about.

------
altmind
In case somebody from Gitlab team is reading, a lot of people want to have
runner priorities in gitlab - the feature seems to be trivial, yet can save a
lot of time and money for the user for you can use less ondemand runners or
give more work for more powerful runners

[https://gitlab.com/gitlab-org/gitlab-
ce/issues/12715#note_11...](https://gitlab.com/gitlab-org/gitlab-
ce/issues/12715#note_118238957)

~~~
emilycook
You caught me, I'll pass this along to our product team. Thanks for the
feedback!

~~~
ganeshkrishnan
Love your product. It's the backbone of our distributed remote startup.

------
zmmmmm
It's amazing how good Gitlab is for a free product.

Interestingly, the fact that we need to host _some_ of our repos internally
means we have an on-site install, but _because_ of that I much prefer to host
our public / non-internal repos on gitlab.com rather than github, because I
can use a single workflow / UI / system for all our projects. So steadily all
my open source etc. is moving to gitlab.com because of this effect.

Thanks to the team at Gitlab who make all of this available for everyone to
use!

~~~
emilycook
No, thank _you_ for using GitLab! We appreciate you :)

------
vkaku
I was a Gitlab fan, until I tried Gitea. I wish they'd start shrinking Gitlab
image sizes quite a bit.

~~~
chewmieser
Saying Gitea is better because it's lighter weight is like saying a moped is
better then an SUV because it's lighter weight. Gitea / Gogs is great for
personal projects and small teams that don't need all the CI/devops/scrum/etc
features that GitLab provides, but they're not really in the same ballpark.

GitLab is definitely resource hungry, but we self-host it for under $100/mo on
AWS. This includes the cost of the CI infrastructure as well - EC2 instances
being spawned by the multi-runner with docker+executor for each unique
pipeline running.

Management of the server has been as easy as logging into the GitLab server
periodically and running a yum update... It's never gone down.

~~~
tagrun
Gitlab didn't have those extra features at early stages either (Gitea does
have CI API BTW, if not a built-in CI). And Gitea doesn't have Gitlab's
financial resources.

But the point being made is orthogonal to the feature set: Gitlab (mostly
written in Ruby) isn't using hardware resources (memory, CPU cycles,
parallelism) as efficiently as Gitea (written in Go) does.

This is well reflected to the _minimal_ system requirements, even when you
aren't using any of those additional features:
[https://docs.gitlab.com/ee/install/requirements.html](https://docs.gitlab.com/ee/install/requirements.html)
whereas you can in principle use Gitea even on a Raspberry Pi Zero for a small
group.

For example, disregarding parallelism and wasted CPU cycles and just looking
at memory usage: I have a running instance and its using 30MBs of RAM at the
moment (~10 users, ~100 repos). If I move all the repos, issues, PRs to a
Gitlab instance, I would be looking at GBs according to their minimal
requirements. This is related to the mindset in which memory and CPU are
considered as infinite resources.

------
justinrlle
To me, the biggest feature is
[https://about.gitlab.com/2019/04/22/gitlab-11-10-released/#s...](https://about.gitlab.com/2019/04/22/gitlab-11-10-released/#scoped-
labels). I've seen so many repositories imitating custom fields with labels
starting with the same prefix, having it enforced by is such a good thing.

~~~
CameronBanga
The decisions to include features based on price tier has seemed to grow
increasingly petty IMO. We are on the Bronze tier, and won't upgrade because
of a feature like this specifically. But each time I see that we don't get new
features like this, I lose a little bit of that love I've had in GitLab as a
user for over 4 years now.

~~~
diftraku
While using the free tier, I honestly can't validate a a $19/user/mo
($228/user/annum) expense based solely on a single feature, let alone why I
should move to the paid version at all if more and more features start to be
gated beyond multiple levels (a la Windows 7).

I love using Gitlab as a part of development cycle, managing issues and
handling pull/merge requests but per seat licensing is a bit steep for a
single user, even more so for a team.

The norm for pricing products and services is more and more "just for a
pint/coffee/sandwich a month" but when everyone wants their share of the cash,
the end result is a mismash of services and products that don't work together
well (if at all) and you get stuck without a pint/coffee/sandwich for the
whole month now.

~~~
ollyculverhouse
You don't think you get enough value out of Gitlab to justify the seat price?
Based on the fact it seems to power all (or majority) of your development
process it seems like it would be worth it?

------
olah_1
A really simple way to improve the UI is to just add some margins on the right
and left of the page. It's very off putting to have meaningful content butted
up against the absolute edges. Not sure why this is, but I really hate
interacting with gitlab because of it. Hope that helps.

~~~
psimyn
thanks for the feedback - it always helps. There was some discussion around
max widths of certain pages here: [https://gitlab.com/gitlab-
org/design.gitlab.com/issues/47#no...](https://gitlab.com/gitlab-
org/design.gitlab.com/issues/47#note_84593437)

We prefer 990px containers where possible, so if you're using gitlab on a
browser smaller than that it'll usually butt up against the edges.

Couple of questions about your issue:

1\. Any pages this is particularly bad for? Some dense pages (e.g. Pipelines
or side-by-side diffs) need all the width they can get

2\. what screen size do you normally use?

3\. In Settings > Preferences > Behaviour, are you using Fixed layout or
Fluid? Fixed should give you left/right margins if your window is >1280px

4\. Do you collapse the left/right sidebars? I usually keep them both
collapsed which helps reduce the crowding. But since they are expanded by
default this is not an ideal solution

~~~
olah_1
Let's look at the main page for a repo:
[https://gitlab.com/pwoolcoc/fedichat](https://gitlab.com/pwoolcoc/fedichat)

The main middle section is fine, your eye doesn't have to travel far to read
the code files and the readme because it's in your primary viewing area.

But you know what's not in your primary viewing area? All of the buttons that
do important things. They're shoved off to the side. If you want to do
anything other than read the code files, you need to be looking at the exact
leftmost edge of your screen and away from the main content. It's a disjointed
viewing experience.

But that's just about the navigation. Let's say that you find the Issues page
and go there:
[https://gitlab.com/pwoolcoc/fedichat/issues](https://gitlab.com/pwoolcoc/fedichat/issues)

Ok, now the main content AND the most important buttons (navigation) are
shoved to opposite sides of the screen. There is no max width on the main
content, so your eye has to travel a veritable mile to read all of the content
for each issue.

Even looking at the content for a specific issue has the same problem:
[https://gitlab.com/pwoolcoc/fedichat/issues/6](https://gitlab.com/pwoolcoc/fedichat/issues/6)

If I had to put my finger on the primary reason for this design, it's probably
an over-focus on the idea that you should feature some "main content" for each
page and kind of hide what you believe is "superfluous".

For example, "oh they clicked on an issue, so they really only care about the
discussion that is taking place. Let's feature the discussion text but make
all of the metadata shoved to the side and even collapsible." But the problem
with this line of thinking is that the user _does_ care about more than just
the "main content" of a page. The metadata, the navigation, it's all factored
into a typical user experience. So when you are making the decision for the
user about what they _should_ be looking at, you're forcing them to break your
flow to do what they want. Now the user has to dart their eye from the far
left to the far right just to see what they want.

I know I didn't answer your numbered questions directly, but I hope I'm
conveying this correctly. I've never made a gitlab account, so I just use the
default settings.

~~~
annabelgray
Thanks for the detailed explanation!

Our navigation was redesigned about 2 years ago ([https://gitlab.com/gitlab-
org/gitlab-ce/issues/32794](https://gitlab.com/gitlab-org/gitlab-
ce/issues/32794)), and we conducted a lot of research and user studies to
ensure we were creating the best possible experience
([https://gitlab.com/gitlab-org/gitlab-
ce/issues/34917](https://gitlab.com/gitlab-org/gitlab-ce/issues/34917)). All
the navigation items to get to different pages within a project are contained
in the left sidebar, while the buttons on the main portion of the screen are
directly related to the current page.

For the issues page, I agree; we should probably add a max-width to the list.
I've opened an issue to try it out [https://gitlab.com/gitlab-org/gitlab-
ce/issues/61046](https://gitlab.com/gitlab-org/gitlab-ce/issues/61046)

We're currently also in the process of rethinking the right sidebar. It's
getting cluttered, and there are items in there that probably aren't as
frequently used as others. I've opened an MR to test a new design idea-
[https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/27752](https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/27752). We're also conducting research to find out which
items are most frequently used/most important- [https://gitlab.com/gitlab-
org/ux-research/issues/134](https://gitlab.com/gitlab-org/ux-
research/issues/134) (the issue is private, but will be made public once the
studies have been completed).

Hopefully this addressed at least some of your points. Please feel free to
open some issues with any other ideas you have.

~~~
olah_1
There's quite a lot of issues there! So I'll just leave one more comment with
you for now.

When I look at a Merge Request ( [https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/27776](https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/27776) ), the primary thing I do is look straight at the
code changes.

It took me an embarrassingly long amount of time to find where the code
changes are in the UI. It seems like the actual content of the MR is the most
important part and should be up at the top with the title and text
description.

I think if I had to summarize my take on Gitlab UI, it would be claustrophobia
(sidebars closing in on me) and information overload (what am I looking at or
what _should_ I be looking at).

Thanks for taking the time in this interaction! :)

------
MindTooth
When GitLab starts to fully support automatic Let's Encrypt certificate
generation with GitLab Pages — just like GitHub, I would strongly consider
moving.

AFAIK it's in the pipeline to be added, but seems to not be a #1 priority[1].
Please let me know otherwise.

[1] [https://gitlab.com/gitlab-org/gitlab-
ce/issues/28996#note_15...](https://gitlab.com/gitlab-org/gitlab-
ce/issues/28996#note_159251434)

~~~
HatchedLake721
Out of literally bajillion features GitLab provides from DevOps lifecycle to
project management and everything in between, Lets Encrypt certificates is
what will make you switch? Are you serious?

~~~
MindTooth
Why would I not be? I see it as a feature that I would like to exist. And yes,
they to have many features, but atm. I don't use them to the extend that I
must switch at this second.

For future school project, I do see myself using GitLab. As you yourself said,
they have many good features. (After been forced to used Bitbucket for a
school project, I'm happy to use anything else.)

------
dsumenkovic
Overview of the three main improvements in this release:

1\. Pipelines on the Operations Dashboard The Operations Dashboard allows
users to have an overview of project information throughout the entire GitLab
instance. You add individual projects, one by one, so it’s flexible to
whichever specific projects are of interest. Also, the pipeline status
information is added to the Operations Dashboard. This should help teams view
the pipeline health of all the projects that they care about, together in a
single interface. [1]

2\. Pipelines for Merged Results When working in a feature (source) branch,
it’s normal to have it diverge over time from the target branch if you aren’t
rebasing frequently. This can result in a situation where both the source and
target branch’s pipelines are green and there are no merge conflicts, but the
combined output will result in a failed pipeline due to an incompatibility
between the changes. By having your merge request pipeline automatically
create a new ref that contains the combined merge result of the source and
target branch, then running the pipeline against that ref, GitLab can better
ensure that the combined result will be valid.Please note that if you are
using merge request pipelines (in any capacity) and you use private GitLab
runners that are version 11.8 or older, you will need to upgrade them to avoid
running into the issue described in gitlab-ee#11122. Users of GitLab’s shared
Runner fleet are not impacted. [2]

3\. Suggest changes to multiple lines Collaborating on merge requests often
involves spotting problems and suggesting a solution. In GitLab 11.6, we
introduced support for suggesting a change to a single line. With 11.10,
changes can now be suggested to multiple lines when leaving a comment on a
merge request diff, and accepted with a single click, by any user with write
permissions to the source branch. [3]

[1] -
[https://docs.gitlab.com/ee/user/operations_dashboard/](https://docs.gitlab.com/ee/user/operations_dashboard/)

[2] -
[https://docs.gitlab.com/ee/ci/merge_request_pipelines/#pipel...](https://docs.gitlab.com/ee/ci/merge_request_pipelines/#pipelines-
for-merged-results-premium)

[3] - [https://docs.gitlab.com/ee/user/discussions/#multi-line-
sugg...](https://docs.gitlab.com/ee/user/discussions/#multi-line-suggestions)

------
stefkors
One thing that always seems a but more complicated at gitlab is to get a full
overview/dashboard of my companies projects/repos. Has anyone found a better
way to deal with that?

~~~
emilycook
One option would be to add your most important stuff to the Operations
Dashboard, since the button for it is always shown up top. You can also set it
as your home page (Settings - Preferences - Default dashboard)

------
croo
We already use it and it's getting better at every release. However there is
few pain point that makes it hard to use for non-agile projects and planning.
One is the ability to set the desired start date of an issue:
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/39862](https://gitlab.com/gitlab-org/gitlab-ce/issues/39862)

~~~
emilycook
Hi! Thanks for the feedback. I see that issue hasn't been commented on by us
in a while, so I'll pass that on to our product team

------
sigi45
I like gitlab very much and i see that they improve there autodevops feature.
That looks promising that i now can include single steps.

I'm playing around with autodevops and currently it sucks. I cloned there
script and the helm chart otherwise it is not possible to just use it.

And quite frankly if you promote it as auto and enable it on default and it is
not able to build a standard spring boot application or a angular frontend,
i'm a little bit disappointed.

there is also a bug open for frontend builds: It is able to detect and build
the anguluar project but is not able to execute karma tests because the image
doesn't contain chromium. And for the backend there is another bug: autodevops
builds the spring boot application and enables/enforces postgresql ssl but the
image from gitlab for postgresql doesn't support it.

~~~
dgruesso
Hi @sigi45, GitLam PM here. Thanks, I'm glad you like GitLab and have noticed
the improvements we've been working on for Auto DevOps. I'm sorry things
didn't work out of the box for you, we've worked to cover many use cases but
we recognize we don't yet cover them all. If the particular stage in question
is not supported you have a couple of options: 1) you can disable the
particular job in question with the use of environment variables (see
[https://docs.gitlab.com/ee/topics/autodevops/#environment-
va...](https://docs.gitlab.com/ee/topics/autodevops/#environment-variables))
or you can use composable Auto DevOps to only pull in the parts that are
relevant to your project and use a customized CI script that fits your
application better. More info on composable Auto DevOps here
[https://docs.gitlab.com/ee/topics/autodevops/#using-
componen...](https://docs.gitlab.com/ee/topics/autodevops/#using-components-
of-auto-devops). Is your project public by chance? Would like to take a look
and make sure we do what we can to support it. Thanks.

~~~
sigi45
Hey,

nope its not public. But for example the ssl bug you can find here:

[https://forum.gitlab.com/t/auto-devops-postgres-database-
ssl...](https://forum.gitlab.com/t/auto-devops-postgres-database-ssl-
error/13987/4)

I personally have asumed that when you introduce autodevops, you would make
sure that the top x default stacks are working fine. Spring Boot and Angular
are very popular (i believe) but they don't work out of the box but not much
is missing.

------
svnpenn
can we please get "Number of contributions in the last year"? one of the only
things keeping me at github

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

~~~
lamby
How come this is (such) a dealbreaker for you?

------
arianvanp
My only gripe with gitlab is that gitlab-runner config is mutated by the
runner itself. This makes it extremely hard to deploy gitlab-runners reliably
and reproducibly in a declarative fashion which is kind of ironic given their
whole sales pitch is "ci/cd".

Apart from that it is great so far

------
shimms
I want to like GitLab, but the (comparative) lack of integrations is a
showstopper.

For instance in our Github, Code Climate runs against all pull requests and
adds comments on files when it detects quality issues (as a bot user).

I get this is up to companies like Code Climate to build, but having done a
bit of integration building myself, the platform and marketplace strategy at
Github is just so much more mature and thought out. The GitLab
marketplace/integrations capability feels very much like an afterthought (no
bot users for one thing).

Would love to see GitLab focus on making a broader platform & marketplace
play, and working with big ecosystem players to really enhance the GitLab
offering.

~~~
csprauve
Interesting feedback. Could you give a few more examples? For instance, if you
could build your DevOps toolchain and add any 3rd party integrations to
GitLab, what would they be?

~~~
shimms
DevOps toolchain you've got covered. Your pipelines are pretty neat.

One thing I really like about GitLab is seeing pipeline errors in the merge
request. For instance, we have rspec bubble up failures and they're right
there in the test summary on the merge request. GitLab shows us a check
failed, but we have to click through to Circle CI to see what the actual
failures were.

One thing GitHub does well is the idea of checks. The entire pipeline in
GitLab is a binary pass or fail. To see which bits failed, you have to dig
into the pipeline.

Would be great to see that (similar to test results) in the merge request, in
a similar way that GitHub checks are displayed.

Our typical DevOps set up is Jira for issues, GitHub for source and peer
reviews. The pull requests are set up to include a few things like Quality
(usually Code Climate), CI (usually Circle CI, sometimes Buildkite), a
security auditor, a dependency auditor etc. At the other end, we use a service
like Codefresh or whatnot to handle deployment to our environments.

Obviously, GitLab does all this in one ALM, which makes it closer to Azure
DevOps than GitHub for direct feature comparisons, so this is more about the
source code peer review through merge/pull requests than other aspects of the
ALM process.

In GitHub pull requests, when checks fail, we get immediate visibility right
on the pull request screen which checks failed, rather than having to go into
the pipeline to look at jobs.

From a DevOps perspective, GitLab far exceeds GitHub (obviously). From idea to
code, to review to build and publish is great. The pipelines (as I said above)
are good.

I'd just like more integration points in the merge request process for
external services to augment the functionality provided out of the box, such
as Code Climate, Hound, Dependabot, LGTM/GuardRails/Snyk etc. Whilst you can
wire these up (kinda) yourself - you could just use rubocop instead of Hound -
you don't get the deep merge request integration. When Hound finds a rubocop
violation it adds a contextual comment on the pull request at the line of code
that is offending. In GitLab with rubocop, you simply fail the pipeline and
then trawl through log output.

As I said in reply to sytse above, I think that is the main difference between
cultivating a thriving eco-system of integrations vs providing an API and
instructions.

------
shmerl
I wish they'd add history to snippets, like Github has for gists.

~~~
sytse
Thanks for posting. I wanted that to 3 years ago and made an issue
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/13426](https://gitlab.com/gitlab-org/gitlab-ce/issues/13426)

While I'm the CEO the product managers decide what to work on next since they
are the DRI [https://about.gitlab.com/handbook/people-
operations/directly...](https://about.gitlab.com/handbook/people-
operations/directly-responsible-individuals/)

We are looking into this [https://gitlab.com/gitlab-org/gitlab-
ce/issues/48215](https://gitlab.com/gitlab-org/gitlab-ce/issues/48215)

~~~
prepend
Thanks for writing this explanation for how you use DRI. It’s the first time
I’ve read about it that went into detail how it supports collaboration and
consensus. A few times in the past I’ve tried to explain and ran into problems
with the criticism that DRI means authoritarianism. It didn’t help that Jobs
was a bigger user of the term.

------
ksec
Any plans to join the Rank of Shopify / Github / BaseCamp running on near /
close to Rails Master?

I believe Gitlab is still on Rails 5.

[1]
[https://weblog.rubyonrails.org/2019/4/24/Rails-6-0-rc1-relea...](https://weblog.rubyonrails.org/2019/4/24/Rails-6-0-rc1-released/)

~~~
brodock
There is an ongoing effort to get us migrated to latest stable first. So we
just upgrade from 5.0.x to 5.1.x [https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/27480](https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/27480) there are still lots of warnings and deprecations to
fix. Rails 5.2 will come next and I believe when we get to the point to
migrate to Rails 6 it will be stable already.

There is no plan to ship with unstable/master that I know of.

~~~
smcg-gitlab
[https://blog-rails5-upgrade.about-
src.gitlab.com/2019/04/10/...](https://blog-rails5-upgrade.about-
src.gitlab.com/2019/04/10/upgrade-to-rails5/) is a WIP blog post about how we
upgraded to Rails 5 which might be interesting, too.

------
geezerjay
Has anyone had any luck adding API tests to Gilab's CI/CD pipeline? For some
reason I'm able to build Docker images and run them as containers with dind as
part of a testing pipeline but I haven't had any luck getting the API test
scripts to establish any connection with the containerized service.

~~~
rmetzler
This sounds like a Docker networking problem. I would think you need to have
docker-compose and bring your microservice and all the dependencies up and
then test against your microservice _in the same network_.

I've written some .gitlab-ci.yml files in the last months. What I do is using
a script to validate against the Gitlab lint API. This is done every time I
save the file.

I also run gitlab-runner on my local machine and test my jobs with `gitlab-
runner exec docker`. Don't forget to commit what you need in the job. You
don't need to commit the .gitlab-ci.yml, but everything else, because the
first step to run the job is cloning the repo.

I have also updated the brew formulas for the last releases of gitlab-runner.
Gitlab is great software and I've worked with it and administrated it for the
last 5 years. I don't want to miss it.

~~~
BaronSamedi
I was also going to say it's likely a Docker network problem. Docker-in-docker
runners work great for us and make it possible to do all kinds testing in the
pipeline; for example Selenium, custom REST, OWASP ZAP, etc.

------
moviuro
My GnuPG signatures are still unverified :( [0,1] [2]

[0] [https://gitlab.com/moviuro/moviuro-
pkgbuilds/commit/e4918741...](https://gitlab.com/moviuro/moviuro-
pkgbuilds/commit/e491874122450314a090e5902218148f48b7650c) # Broken

[1] [https://github.com/moviuro/moviuro-
PKGBUILDs/commit/e4918741...](https://github.com/moviuro/moviuro-
PKGBUILDs/commit/e491874122450314a090e5902218148f48b7650c) # OK

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

~~~
dbnoch
You replied a month ago saying that you downgraded the version and the issue
was resolved, is that still not working for you?

EDIT: Fixed spelling of replied

~~~
Sevenn
Hey ! It's me the reporter of this issue xD Dowgrading the version on my
system was the solution, but, it can't be a definitive solution.

~~~
moviuro
Yeah... downgrading anything goes pretty much against the nature of my current
distro (Arch)

~~~
Sevenn
Same same, and downgrading gpg on arch it's not really easy, and pretty unsafe

------
tbrock
Anyone know how gitlab’s CI/CD compares to buildkite’s?

~~~
bl4ckm0r3
How do you like buildkite?

~~~
tbrock
We like it so far. It’s great to control our own runners and be able to size
larger hosts. We came from CircleCI.

------
absorber
Hey, congrats on the new release!

Not sure if this is the right place to shed some light on my issue, but my
repo is in the process of being deleted for over a month now [0]

Basically I made some mistakes in that repo and didn't know how to rectify
them, so I decided to delete it and then make it again. However the deletion
process got stuck it seems.

[0] [https://gitlab.com/gitlab-com/support-
forum/issues/4413](https://gitlab.com/gitlab-com/support-forum/issues/4413)

~~~
emilycook
Hi! I've passed this on to our support team. Sorry for the inconvenience!

------
laktak
Hey gitlab, this is just a personal preference but could you allow us to call
"merge requests" "pull requests" instead?

~~~
emilycook
Hmmm I'm not sure changing our whole naming system is feasible, but I mean,
you can still call it whatever you want to I guess.

~~~
chappi42
If I call it pull request it would be nice if the gitlab ui would have the
same name. I see, you won't change, so maybe offer a config option for this
name?

~~~
emilycook
Unfortunately I don't see this being a priority for us, as it would be a
fairly large-scale operation for not a lot of benefit. However, you can open
an issue for it here if you want! [https://gitlab.com/gitlab-org/gitlab-
ce/issues](https://gitlab.com/gitlab-org/gitlab-ce/issues)

