Gitlab 14(about.gitlab.com)
about.gitlab.com
Gitlab 14
https://about.gitlab.com/blog/2021/06/22/gitlab-14-modern-devops/
115 comments
What is happening to GitLab? The site is littered with charts and nonsense business marketing lingo like "value stream management". The menu has a mysterious "solutions" category, and I have to fill out a form to watch a demo video. What's next? Will I have to "download a whitepaper" PDF to look at "case studies" before I can understand what they're even offering?
It's definitely getting a lot more marketing heavy lately. Which is unfortunate in my opinion, because there's really not a lot of selling you need to do when people have actually used the product.
You can also start to see more of the monetization strategies coming into play. More and more features are being added to the paid versions than core. This is also still fine with me, because the open core product is still so dang far ahead than the competition when it comes to total feature set, and I still feel like the way they stratify features makes sense. If you're not a big enterprise, most of the paid features aren't all that important to you yet. And I absolutely understand that as a company they want to make money, and grow.
I love GitLab. I use it every day, and I tell other people and companies that they should use it. I will definitely say, however, that I'm counting these as orange-ish flags. Maybe not red, but also not green or yellow. I worry about whether the feature development will continue to be developer-oriented or if like Slack, it will shift to "whatever sells more licenses to large enterprise CEOs."
You can also start to see more of the monetization strategies coming into play. More and more features are being added to the paid versions than core. This is also still fine with me, because the open core product is still so dang far ahead than the competition when it comes to total feature set, and I still feel like the way they stratify features makes sense. If you're not a big enterprise, most of the paid features aren't all that important to you yet. And I absolutely understand that as a company they want to make money, and grow.
I love GitLab. I use it every day, and I tell other people and companies that they should use it. I will definitely say, however, that I'm counting these as orange-ish flags. Maybe not red, but also not green or yellow. I worry about whether the feature development will continue to be developer-oriented or if like Slack, it will shift to "whatever sells more licenses to large enterprise CEOs."
Yeah, the excellent open core is the #1 reason I evangelize for Gitlab to colleagues as well. It's a guarantee that even if Gitlab turns fully user-hostile tomorrow (which I do not expect at all, but just saying, worst case), we can carry on unaffected on the self-hosted open core, which will doubtless be carried on by someone else in that eventuality.
Plus, the scope of its features is incredible. My team uses the community edition and our peer teams use a different stack of three different licensed proprietary vendors just to do the same thing we're able to do on the open core. I had a funny conversation the other day where someone from those teams was looking at buying a license for a new package management system. When I pointed out Gitlab could do what he needed, he said, "Yeah, but we already have these other two vendors for source control and CI". To which I thought, "Sure, so you could drop both of them, too."
But I can appreciate once a team's built momentum on one stack, interrupting that is probably usually more trouble than it's worth.
Plus, the scope of its features is incredible. My team uses the community edition and our peer teams use a different stack of three different licensed proprietary vendors just to do the same thing we're able to do on the open core. I had a funny conversation the other day where someone from those teams was looking at buying a license for a new package management system. When I pointed out Gitlab could do what he needed, he said, "Yeah, but we already have these other two vendors for source control and CI". To which I thought, "Sure, so you could drop both of them, too."
But I can appreciate once a team's built momentum on one stack, interrupting that is probably usually more trouble than it's worth.
> More and more features are being added to the paid versions than core.
If you tally the features per release, still more features are being added to Core: https://gitlab-com.gitlab.io/cs-tools/gitlab-cs-tools/what-i...
(Disclaimer: GitLab employee and co-author of that overview)
If you tally the features per release, still more features are being added to Core: https://gitlab-com.gitlab.io/cs-tools/gitlab-cs-tools/what-i...
(Disclaimer: GitLab employee and co-author of that overview)
They provide additional features from the 'paid' tiers if you are hosting public groups/repositories - and open source projects can apply for additional freebies/discounting.
It's really frustrating because the technical stuff is actually really cool! I like automating what I can! Gitlab provides a ton of tools for that, and it's fantastic! But it becomes increasingly hard to figure out, not imo because the features are poorly designed or implemented, but because it's marketing over substance. I keep getting told the effects of what I can do with Feature X, but never what Feature X actually does.
Maybe it's time for me to learn the pure git and email workflow.
Maybe it's time for me to learn the pure git and email workflow.
> What's next? Will I have to "download a whitepaper" PDF
at the bottom there's a "Free eBook: A beginner's guide to GitOps" that requires filling out a form to download
at the bottom there's a "Free eBook: A beginner's guide to GitOps" that requires filling out a form to download
I fear most core features are done - the basics (CI, issues, merges) work very nicely, even though a bit spartan at some points, but it's not enough for Gitlab's sales to be where it needs to be. So to me it feels like Gitlab is now look for a problem to solve, which actually makes the product more confusing and less compelling unless you buy into their whole story
I wouldn't be surprised if at some point something like Gitea (no personal experience with it) will close the gap sufficiently for a lot of users to switch there, especially as the gitlab upgrade cycle becomes more tiring without seeming to add anything of real value
(I know I'm just a freeloader with gitlab CE, but at this point the only reason to upgrade is the monthly security vulnerability, and I just pray it hits sufficiently far away from the 22nd of the month that all the update bugs have been ironed out again)
I wouldn't be surprised if at some point something like Gitea (no personal experience with it) will close the gap sufficiently for a lot of users to switch there, especially as the gitlab upgrade cycle becomes more tiring without seeming to add anything of real value
(I know I'm just a freeloader with gitlab CE, but at this point the only reason to upgrade is the monthly security vulnerability, and I just pray it hits sufficiently far away from the 22nd of the month that all the update bugs have been ironed out again)
> I fear most core features are done - the basics (CI, issues, merges) work very nicely
well they should make their review stuff better. sorry but if my merge request has too many changed lines, it basically just does not show all files, not even in their vscode plugin, which is so stupid. it's cheaper to use gitlab free and put upsource behind it, if your dealing with large mr's... I'm not so sure anymore.
if their ci wouldn't be so good, i would've already used gitea. but gitea+drone is way worse.
well they should make their review stuff better. sorry but if my merge request has too many changed lines, it basically just does not show all files, not even in their vscode plugin, which is so stupid. it's cheaper to use gitlab free and put upsource behind it, if your dealing with large mr's... I'm not so sure anymore.
if their ci wouldn't be so good, i would've already used gitea. but gitea+drone is way worse.
> I wouldn't be surprised if at some point something like Gitea (no personal experience with it) will close the gap sufficiently for a lot of users to switch there
Gitea is a weird one for me and I've been studying the Git code hosting space for probably a decade now.
In the last year, they have what appears to be 7 core contributors:
https://public-001.gitsense.com/insights/github/repos?p=impa...
where 4 must be working on this full-time or doing a lot of extra work outside of their day to day job.
Gitea appears to be funded by opensource contributions
https://opencollective.com/gitea
but the amount there doesn't seem like it would be enough to really push development forward fast enough to become a serious alternative for enterprise. Gitea though, is significantly more active than Gogs, which it forked from:
https://public-001.gitsense.com/insights/github/repos?p=impa...
which is very much a one person operation for the most part.
Disclaimer: I'm the creator of the tool that is being linked
Gitea is a weird one for me and I've been studying the Git code hosting space for probably a decade now.
In the last year, they have what appears to be 7 core contributors:
https://public-001.gitsense.com/insights/github/repos?p=impa...
where 4 must be working on this full-time or doing a lot of extra work outside of their day to day job.
Gitea appears to be funded by opensource contributions
https://opencollective.com/gitea
but the amount there doesn't seem like it would be enough to really push development forward fast enough to become a serious alternative for enterprise. Gitea though, is significantly more active than Gogs, which it forked from:
https://public-001.gitsense.com/insights/github/repos?p=impa...
which is very much a one person operation for the most part.
Disclaimer: I'm the creator of the tool that is being linked
A Disclosure provides a reader all necessary and relevant information regarding a purchase or promotion so they can make a well-informed decision. It’s “the fine print.”
A Disclaimer is a statement to limit your liability; that denies something, especially responsibility. It’s your “hold me harmless” blanket statement.
---
Disclaimer: I am not a lawyer.
Disclosure: The above quotes are from http://ajfeuerman.com/disclaimer-vs-disclosure/
A Disclaimer is a statement to limit your liability; that denies something, especially responsibility. It’s your “hold me harmless” blanket statement.
---
Disclaimer: I am not a lawyer.
Disclosure: The above quotes are from http://ajfeuerman.com/disclaimer-vs-disclosure/
Thanks for the clarification!
I switched to Gitea a year or two ago. GitLab was getting too heavy for me. I felt like I was building development process instead of software. Gitea gets out of the way and I don’t miss any features.
Gitea just added push mirroring, so my favorite new thing is to develop via Gitea and push to GitHub for actions or things like Cloudflare pages deployment.
I pledge / donate to bounties for Gitea with the Starter $ I was willing to give GitLab.
Gitea just added push mirroring, so my favorite new thing is to develop via Gitea and push to GitHub for actions or things like Cloudflare pages deployment.
I pledge / donate to bounties for Gitea with the Starter $ I was willing to give GitLab.
We try to appeal to different audiences with different content. The developer focused post for this release was published on the same date on https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-rel...
I have no interest in any of the ticketing/workflow/pm features (JIRA shop), nor am I interested in the container or package registries (Artifactory). I just use GitLab for the code repository, review, and CI stuff, and while those basic features do still get love, it's frustrating to have the Starter plan dropped so that the only paid option is 4x the price and the banner features are all stuff I don't care about.
This doesn't look like a normal release announcement. It's has a bunch of marketing fluff, but I don't really know what is new in gitlab 14.
Hey there, I addressed that in this comment here: https://news.ycombinator.com/item?id=27714800
It was never a good idea to centralize a decentralized source revision control system.
https://news.ycombinator.com/item?id=19367916
https://news.ycombinator.com/item?id=19367916
Git supports a wide variety of deployment architectures. Centralized hub-and-spoke just happens to be one of them.
Welcome to VC Money. The pressure to grow faster may be heating up.
EugeneOZ(1)
>The menu has a mysterious "solutions" category
What's so mysterious about it?
What's so mysterious about it?
Take this with a grain of salt, perhaps I'm just not in a good headspace for reading this.
The first two paragraphs of the first section (The next iteration of Dev Ops) reads like it was written by someone at Gartner trying to get my 11 person business to buy a report for $50K that still won't actually tell me if the product will do the things I need it to. I imagine it's exciting for investors, but it made me sad and made me suddenly (and likely unfairly) scared that the features were going to take a back seat to the "placing strongly in several markets".
That being said I read through the feature list and while none are specific things I needed it certainly sounds pretty great. We made the switch from github to gitlab about 4 years ago and I haven't really ran into any major issues or frustrations. So for what its worth after my comment above a BIG thank you to the Gitlab team.
The first two paragraphs of the first section (The next iteration of Dev Ops) reads like it was written by someone at Gartner trying to get my 11 person business to buy a report for $50K that still won't actually tell me if the product will do the things I need it to. I imagine it's exciting for investors, but it made me sad and made me suddenly (and likely unfairly) scared that the features were going to take a back seat to the "placing strongly in several markets".
That being said I read through the feature list and while none are specific things I needed it certainly sounds pretty great. We made the switch from github to gitlab about 4 years ago and I haven't really ran into any major issues or frustrations. So for what its worth after my comment above a BIG thank you to the Gitlab team.
Thanks for the feedback.
This is the first time we wrote a blog post about a release in addition to the release post we publish each month on the 22nd. (The release post for 14.0 can be found here: https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-rel...)
We'll keep iterating to make these blog posts more appealing to the wider community in the future.
This is the first time we wrote a blog post about a release in addition to the release post we publish each month on the 22nd. (The release post for 14.0 can be found here: https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-rel...)
We'll keep iterating to make these blog posts more appealing to the wider community in the future.
From a skim read of both blog posts it's still impossible to understand what's actually new in this version. Just introduce the features in the post, no?
I kept stopping at the MVP section (I'm on iOS) but if you keep scrolling you'll eventually get to "Key features released in GitLab 14.0"
If you check out the "Key features" section of the release post, you will find descriptions of all the new features in 14.0: https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-rel...
don't 'iterate' for 'appeal'. just have a passionate dev write shit and we'll eat it up!
Who was your target audience with the blog post?
peakaboo(2)
> like it was written by someone at Gartner trying to get my 11 person business to buy a report for $50K that still won't actually tell me if the product will do the things I need it to
Does that actually happen? Especially the part where businesses are in the market for $50k reports that over-promise and under-deliver?
Does that actually happen? Especially the part where businesses are in the market for $50k reports that over-promise and under-deliver?
Real thing that has happened to me, at the time my company (IT consulting / support) was ~10 people (we're ~25 now). A Gartner cold call that wanted to sell me a report that I could use to recommend which cloud storage vendor (box, dropbox, etc.) my clients should use. I explained that we were doing just fine by evaluating which one to used based on which features were more important to that specific client, but he seemed to think having the Gartner rec was critical. I said sure, then asked about the price, once I knew that I was clear that we weren't interested and thankfully he got the message and stopped calling. Maybe this is why my SMB IT company will never make the transition to enterprise clients.
It gave me a pretty jaded view into how those types of reports work. It was hard to not think they are purchased to CYA (internal or external) when you end up recommending the wrong software. I hope that isn't always the case, maybe there is some great content in them, but at 50K I'll never know :)
It gave me a pretty jaded view into how those types of reports work. It was hard to not think they are purchased to CYA (internal or external) when you end up recommending the wrong software. I hope that isn't always the case, maybe there is some great content in them, but at 50K I'll never know :)
This feels like it was written by marketing, for marketing.
I just want to know what's new, but I have to wade through a bunch of prose about how "GitLab has placed strongly in several market reports" and "The DevOps Research and Assessment (DORA) firm’s industry-defining research..." etc.
I just want to know what's new, but I have to wade through a bunch of prose about how "GitLab has placed strongly in several market reports" and "The DevOps Research and Assessment (DORA) firm’s industry-defining research..." etc.
For more detail on what's new in the 14.0 release, you can find the release post here: https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-rel...
Oh, that's helpful thanks. I found that post earlier but didn't realize it lists new features (the "Key features" section is 3 pages down for me, I didn't even realize it was there).
FYI this page has a 200% horizontal overflow on mobile Safari, which makes it hard to scroll straight down the page. It also breaks reader view so I can’t use that.
What iOS version / phone are you on? I'm not able to reproduce that.
14.2.1 on 12 mini
I can reproduce it with and without content blockers.
I can reproduce it with and without content blockers.
Hey also there's an awesome "What's new" section in the help menu on my instance which links to the release post.
For folks not willing to fill out forms to download PDF's some bullet points.
* Terraform module registry.
* VS Code Plugin update - Adds merge reviews in VS Code
* New top menu (combines projects, groups and more menus)
* New sidebar navigation
* Wiki edits / WYSIWYG markdown editor (partial support).
* CI/CD pipeline editor initial templates
* Epic boards to see Epic status more easily
* Container scanning - Trivy and Grype
* Set your preferred pronouns in your profile for orgs where that is important
* Slack notices include links to diffs.
* Change issue types
* Rails 6.1
and more
* Terraform module registry.
* VS Code Plugin update - Adds merge reviews in VS Code
* New top menu (combines projects, groups and more menus)
* New sidebar navigation
* Wiki edits / WYSIWYG markdown editor (partial support).
* CI/CD pipeline editor initial templates
* Epic boards to see Epic status more easily
* Container scanning - Trivy and Grype
* Set your preferred pronouns in your profile for orgs where that is important
* Slack notices include links to diffs.
* Change issue types
* Rails 6.1
and more
The whole Gitlab saga has left me in a bit shaken. To begin with I became a Gitlab supporter and paying customer, because i want to give the lille guy a chance, and it made my switch from GitHub a given. I don't promote myself on a professional level via GitHub anyway. And i like the idea of value for value. And the healthy competition, even if i don't use git that much.
However this resent switch have shown me that the plan with gitlab was to push to the corporate market (which i understand), but leave us small privates (less than 200 commits a year) behind. Lucky i have found a new "Upcoming small guy" to support - fingers crossed...
However this resent switch have shown me that the plan with gitlab was to push to the corporate market (which i understand), but leave us small privates (less than 200 commits a year) behind. Lucky i have found a new "Upcoming small guy" to support - fingers crossed...
Exact same thing happened with me. Had the 4$/mo (I think) plan to support them, despite doing nothing on their platform beyond free tier, and when it became clear that would become > 20$/mo in future I cancelled it and left a message explaining why. Apparently they felt the three year ramp up was more than generous.
I like that you didn’t include who you’re supporting. Makes your comment more legit.
Gitea?
sourcehut.org ?
It's hard to sell in an article because all their releases say Performance Improvements, but this version actually appears to be noticeably snappier in a way that makes a difference in my day to day usage, which is great.
I believe that’s because every team was tasked with auditing their own features to find and fix slow/expensive database queries.
https://gitlab.com/groups/gitlab-org/-/epics/5675
https://gitlab.com/groups/gitlab-org/-/epics/5675
Sigh, my job took a deal from Microsoft and we've been slowly migrating from our locally hosted gitlab to GitHub. It makes me sad, even though I'm glad I resisted the urge to use any of the gitlab CI stuff. I won't be using any of the GitHub actions or whatever they are either.
> took a deal from Microsoft
I feel this. There is a gigantic difference in usability (and in my experience, productivity and maintainability) between the two self-hostable platforms (Gitlab being much better than Github enterprise), and I'm not sure that there's really a good set of metrics to expose when an executive says "here's the easy cost bottom line" between the two. Somehow, the fact that the free GitLab product is already significantly better than the paid GH product seems to be missed as well.
There's just too much FUD about not having a service contract, and that since GH and MS are household names, people assume their products are better and will move forward more quickly. That is not my experience at all, across several companies that have tried both.
All I can say is I'll probably invest in GitLab when it IPOs. It's almost certainly going to be undervalued.
I feel this. There is a gigantic difference in usability (and in my experience, productivity and maintainability) between the two self-hostable platforms (Gitlab being much better than Github enterprise), and I'm not sure that there's really a good set of metrics to expose when an executive says "here's the easy cost bottom line" between the two. Somehow, the fact that the free GitLab product is already significantly better than the paid GH product seems to be missed as well.
There's just too much FUD about not having a service contract, and that since GH and MS are household names, people assume their products are better and will move forward more quickly. That is not my experience at all, across several companies that have tried both.
All I can say is I'll probably invest in GitLab when it IPOs. It's almost certainly going to be undervalued.
My problem with Gitlab is that sneak useful features in their expensive plan. If you want similar features as Github you would need to get their expensive plan and still you will be missing Github Checks API or its ecosystem to have slick integrations with your PRs
What do you use instead? In a similar position GitLab as current and bosses wanting to go Azure DevOps which I'm sure is going by the way side quickly with how much they are changing Azure to work with GitHub. We're still on TeamCity
I've migrated my company's CI and CD to self-hosted Concourse. It's slower due to polling (which might change soon), rather annoying to set up, but it's incredibly flexible.
all of our CI/CD stuff is in Jenkins. It's not perfect, but it has a ton of plugins, and works well enough. The main thing I like is that its dedicated, and independent. Though I've been using it for years, and I'm still not sure if I like groovy or hate it.
I spent a year building a distributed CI service, so I've thought about this a lot.
To be honest I would really recommend giving either Gitlab CI or Github actions a shot. One of the main factors in my thing failing was the inability to compete with the vertical integration these tools both have, which is a massive lever for simplicity, power and reliability.
The disadvantage you rightly highlight is some degree of lock in, should you ever need to move your code, but if you put the core logic of your workflows into scripts (which you likely should do regardless) then this really isn't a big issue.
Genuinely, give Github actions a try - see if your opinion doesn't change once you see its advantages.
To be honest I would really recommend giving either Gitlab CI or Github actions a shot. One of the main factors in my thing failing was the inability to compete with the vertical integration these tools both have, which is a massive lever for simplicity, power and reliability.
The disadvantage you rightly highlight is some degree of lock in, should you ever need to move your code, but if you put the core logic of your workflows into scripts (which you likely should do regardless) then this really isn't a big issue.
Genuinely, give Github actions a try - see if your opinion doesn't change once you see its advantages.
My org has a mix of Jenkins and GitLab CI, and I think it actually works reasonably well, especially if you can have both systems targeting a common pool of k8s-managed compute.
Basically there are large build/integration/test jobs that are centrally managed on Jenkins via Pipeline/Jenkinsfile, but then we offer a library of relatively simple common-case gitlab-ci configs that can be trivially pulled in, so most common cases are basically a one-liner (build dpkg, build setuptools, build sphinx, run nose, etc), but from the dev's point of view it's a self-serve thing rather than some mystery-meat process that can only be altered by filing DevOps tickets and hoping for the best.
TBH I think my biggest complaint with GitLab CI is the insistence that every job is a brand new container. This means if you, say, have a big NPM project that installs thousands of dependencies on every run, you have to either a) hit your repo multiple times and not worry about it, b) figure out a local-enough caching proxy for your repo that it doesn't matter, c) combine your build/test/lint stages into a single one, d) build from a nightly container that has a bunch of it pre-installed, e) abuse the artifacts system to pass the workspace between jobs, f) spend multiple hours trying to make the supplied caching mechanism work, only to find that no matter what you do, NPM ignores the cache and re-fetches every time, and even if it worked, you'd have to pick between various non-ideal cache-keying strategies: https://docs.gitlab.com/ee/ci/caching/
Basically there are large build/integration/test jobs that are centrally managed on Jenkins via Pipeline/Jenkinsfile, but then we offer a library of relatively simple common-case gitlab-ci configs that can be trivially pulled in, so most common cases are basically a one-liner (build dpkg, build setuptools, build sphinx, run nose, etc), but from the dev's point of view it's a self-serve thing rather than some mystery-meat process that can only be altered by filing DevOps tickets and hoping for the best.
TBH I think my biggest complaint with GitLab CI is the insistence that every job is a brand new container. This means if you, say, have a big NPM project that installs thousands of dependencies on every run, you have to either a) hit your repo multiple times and not worry about it, b) figure out a local-enough caching proxy for your repo that it doesn't matter, c) combine your build/test/lint stages into a single one, d) build from a nightly container that has a bunch of it pre-installed, e) abuse the artifacts system to pass the workspace between jobs, f) spend multiple hours trying to make the supplied caching mechanism work, only to find that no matter what you do, NPM ignores the cache and re-fetches every time, and even if it worked, you'd have to pick between various non-ideal cache-keying strategies: https://docs.gitlab.com/ee/ci/caching/
The caching is Gitlab CI biggest weakness IMHO, super slow, and as you said cache strategies are to few to be useful.
Tip: Using the fast zip feature flag when configuring runners/pipelines can help quite a bit
https://docs.gitlab.com/runner/configuration/feature-flags.h...
https://docs.gitlab.com/runner/configuration/feature-flags.h...
I've tried this out but the difference was almost immeasurable. Probably depends on the type of project.
I have too much of an aversion to vendor lock-in and/or Microsoft. I don't think I could give it an honest appraisal. The only way I can see myself using it is if it becomes a mandate at work, and even then I'll make sure the project gets assigned to someone else.
GitLab team member here. I made a 5 minute summary of our GitLab 14 meetup for folks interested in "what's new": https://labwork.dev/go/GitLab14
You mean, GitLab sales here, please watch our promo video?
The majority of the features covered in the video (close to 100%) are features in our Core (free) edition.
In addition, my #1 feature I shared was us moving our SAST feature from our paid version to the open source version. We're very proud of the value in our open source version, and are constantly reinvesting in it.
In addition, my #1 feature I shared was us moving our SAST feature from our paid version to the open source version. We're very proud of the value in our open source version, and are constantly reinvesting in it.
Actually, community members showing their favorite GitLab 14 feature in a meetup, this Monday.
You can watch the full recording here: https://youtu.be/mSspEk8efHE
If you prefer an even shorter version, I attached a GIF to this tweet: https://twitter.com/dnsmichi/status/1410935805271592961?s=20
You can watch the full recording here: https://youtu.be/mSspEk8efHE
If you prefer an even shorter version, I attached a GIF to this tweet: https://twitter.com/dnsmichi/status/1410935805271592961?s=20
The release looks solid. Can you guys produce a bulletin point list of:
* bugfixes
* new features
* removed features?
It is easier to approach.
* bugfixes
* new features
* removed features?
It is easier to approach.
There's also the releases on the project that are formatted more like that: https://gitlab.com/gitlab-org/gitlab/-/releases
Does that help at all?
Does that help at all?
Ah yes thanks a lot :)
Appreciated!
GitLab is starting to become difficult to use due to the amount of features being introduced. It was simple but now it just looks and feels complex. Personal perspective, of course.
I'm a paying customer and I agree.
Meanwhile many core features are still unpolished e.g.: running your own runners sucks and you can't test CI/CD locally.
Meanwhile many core features are still unpolished e.g.: running your own runners sucks and you can't test CI/CD locally.
Hi Carlos, Darren here, PM for runner. Can you provide a bit more insight in terms of some of the challenges that you are having with hosting your own runners? In regards to testing CI locally, did you mean having the ability to validate that a pipeline is fully functional prior to pushing your commit to GitLab?
Not the OP but we can't enable our self-hosted runner on our open source project because if we do then the pipeline won't run on external merge requests. It simply fails with permission errors when we get merge requests. So we have to use the shared runners which are less powerful.
ok ping me on the epic link below. @DarrenEastman is the GitLab handle and let me know what compute class you are needing. We are planning to pivot soon on getting various compute types available on GitLab.com Shared runners.
https://gitlab.com/groups/gitlab-org/-/epics/2426
https://gitlab.com/groups/gitlab-org/-/epics/2426
Hm? Actually you can indeed test CI locally, if only one step at a time. This is a very very rare feature. It’s gitlab-runner exec.
Also, I find that running your own runner is super easy and straightforward.
Also, I find that running your own runner is super easy and straightforward.
What do you mean re not testing locally? I've had good success with hosting a runner on my local machine and using it to run the jobs
Not using it for enterprise (I am not the one who decides) but I started with Gitlab CE for my personal use (running in a docker container), it was exactly as you put it. It felt complex. Moved to Gitea and I am surprised by how fast git doing just git can be (on my limited hardware)
I hadn't used it much until maybe 3-4 years ago, but have found the UI confusing and messy that whole time.
Then again, I also find Facebook and Twitter so confusing they're nearly un-usable, so maybe it's just me.
GH and their clones are fine, though GH's starting to nose into "too much shit going on for me to make sense of it, and unhelpful information density/hierarchy" territory after the last major re-design and latest round of updates, too.
Oddly, very complex actual desktop applications with tons of features rarely leave me feeling helpless and lost the way business productivity web apps so often do, unless they're something like Blender.
Then again, I also find Facebook and Twitter so confusing they're nearly un-usable, so maybe it's just me.
GH and their clones are fine, though GH's starting to nose into "too much shit going on for me to make sense of it, and unhelpful information density/hierarchy" territory after the last major re-design and latest round of updates, too.
Oddly, very complex actual desktop applications with tons of features rarely leave me feeling helpless and lost the way business productivity web apps so often do, unless they're something like Blender.
FWIW, you can turn off most things by going to the project settings under general, visibility.
This reduces the menu items to a minimum.
This reduces the menu items to a minimum.
Also, Holy Crap if you played a drinking game for the word DevOps, you would die from alcohol poisoning.
Long long ago I was full with excitement and expectation about every Gitlab monthly release just to go over the changelog and read about "the new cool stuff that I'll get to play with when I upgrade". Those days are gone now, sadly. Gitlab's changelog (the "New release" blog posts, that is) are unreadable. There are just too many features pushed in every release, on top of too many deprecations. Last time I tried to go point-by-point in their monthly release' changelog it took me ~2.5 hours just to carefully understand what was added / removed / deprecated.
Upgrading has turned from a joy to a completely fearful experience. And don't get me wrong, the omnibus installer is rock-solid and hasn't failed me once. The fear comes from me wondering if I have missed any of the dozens of things that got deprecated / changed and causing a major downtime in my Gitlab installation.
I wish Gitlab could slow down a little bit, but I totally understand this is not possible.
Upgrading has turned from a joy to a completely fearful experience. And don't get me wrong, the omnibus installer is rock-solid and hasn't failed me once. The fear comes from me wondering if I have missed any of the dozens of things that got deprecated / changed and causing a major downtime in my Gitlab installation.
I wish Gitlab could slow down a little bit, but I totally understand this is not possible.
I would probably use gitlab a lot more if they didnt keep logging me out every 20-30 minutes even after setting remember me flag. I stay logged in on github for weeks/months and it is slightly annoying to have to login to gitlab constantly. (I use firefox)
That's probably never going to change.
Oh I like the VS Code-integrated Merge Request reviews. It shows comments and allows you to interact with the merge request & comments just like the web interface but without having to leave VSC.
What is modern DevOps? Does it follow in the wake of an Enlightenment in DevOps? Is it associated with individualism, containerisation and elitist control groups?
Will there be a postmodern DevOps? Will it criticise belief in the inevitability of progress? Will it spring from alienation and anomie brought by breakdown of the traditional operating hierarchy? What will GitLab 15 bring?
Will there be a postmodern DevOps? Will it criticise belief in the inevitability of progress? Will it spring from alienation and anomie brought by breakdown of the traditional operating hierarchy? What will GitLab 15 bring?
Traditional DevOps is when sysadmins checks their scrips into git. Modern DevOps is when they check scripts into git using a really fancy web interface.
Our build pipeline's been failing automatically with "can't run make, operation not permitted" when compiling a native elixir hex (bcrypt), and the only pattern we're seeing is that it's Gitlab Runner v14. I can't find any errors and this has been wasting my time (and our senior DevOps guy's time) for two days now.
Is this on GitLab.com Shared Runners or your own? Also - go ahead and raise an issue with the details in the runner project so we can take a closer look.
https://gitlab.com/gitlab-org/gitlab-runner/-/issues
https://gitlab.com/gitlab-org/gitlab-runner/-/issues
Off topic, can someone help me with the following on gitlab? Maybe I'm not searching with the right search parameters to get the right answers.
1. Who exactly is the assignee? When I'm working on a feature and raise a merge request, why am I given the option of selecting the assignee?
2. How can I cancel build pipelines when team members raise merge requests? I don't have a pipeline setup yet, but I don't want it to run in the first place (and fail)
3. Why is it that people who raise merge requests can approve their own request ? Is there a way to disable this? I would like to have people raise the merge request, but the ability to approve should lie with a few maintainers and developers.
1. Who exactly is the assignee? When I'm working on a feature and raise a merge request, why am I given the option of selecting the assignee?
2. How can I cancel build pipelines when team members raise merge requests? I don't have a pipeline setup yet, but I don't want it to run in the first place (and fail)
3. Why is it that people who raise merge requests can approve their own request ? Is there a way to disable this? I would like to have people raise the merge request, but the ability to approve should lie with a few maintainers and developers.
> Why is it that people who raise merge requests can approve their own request ? Is there a way to disable this?
Sounds like you've configured your repo to allow developers to merge, which is not the default, otherwise you are adding everyone as maintainers. The typical setup is that developers can make merge requests to protected branches, but only maintainers can merge.
> Who exactly is the assignee?
That's up to you to define really. In the system whoever is assigned is the person who gets the ticket in their overview. For our workflows most just keep it unset and someone picks it up on their own. Unless they know for certain which maintainer will be handling the merge request.
> I don't have a pipeline setup yet, but I don't want it to run in the first place (and fail)
I'm not sure what you're asking here, if you don't have a pipeline defined what is it that you don't want to run? Could you have auto-DevOps enabled perchance without wanting it? It can be disabled under "Settings>CI/CD"
Sounds like you've configured your repo to allow developers to merge, which is not the default, otherwise you are adding everyone as maintainers. The typical setup is that developers can make merge requests to protected branches, but only maintainers can merge.
> Who exactly is the assignee?
That's up to you to define really. In the system whoever is assigned is the person who gets the ticket in their overview. For our workflows most just keep it unset and someone picks it up on their own. Unless they know for certain which maintainer will be handling the merge request.
> I don't have a pipeline setup yet, but I don't want it to run in the first place (and fail)
I'm not sure what you're asking here, if you don't have a pipeline defined what is it that you don't want to run? Could you have auto-DevOps enabled perchance without wanting it? It can be disabled under "Settings>CI/CD"
Hey thank you very much. I was not available about a lot of features that you have mentioned. I have set this up properly now.
The thing is I'm working with a new team who are not aware of git / gitlab. So it's a huge learning curve for everyone. And gitlab has a lot of features and terms which are confusing for everyone.
The thing is I'm working with a new team who are not aware of git / gitlab. So it's a huge learning curve for everyone. And gitlab has a lot of features and terms which are confusing for everyone.
Upgrading crashed Puma (the Ruby Server) for me, because it called an unused Funktion meant for Enterprise Edition Users and I am using community edition. Bad to remove the Funktion to get it working again.
"The WIP feature for merge requests has been renamed to "Draft", a more inclusive and self-explanatory term."
English is not my native language and I am outside current American culture trends. Can anybody explain briefly what was wrong and non-inclusive with ”WIP” term?
English is not my native language and I am outside current American culture trends. Can anybody explain briefly what was wrong and non-inclusive with ”WIP” term?
[deleted]
It's a shame that the 'needs' in same stage feature didn't make it in release 14. I think it was supposed to come with release 13.2 or something.
Is there a sane web Notification Center yet? Nope. Sigh.