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.
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.
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).
Ha, thanks! I closed the page at "Join us for GitLab Commit Virtual" and "This month's Most Valuable Person" thinking i reached end of the page with some footer advertisement.
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.
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.
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
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'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.
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
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.
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.
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/
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.
EDIT: to elaborate, I agree with other commenters that seem concerned with Gitlab's direction. It's hard to put my finger on what exactly bothers me, but to take a stab at it: Gitlab always seemed to pitch itself as the nerdy, more open little brother to Github. I'm currently on the free plan, but definitely consider/considered going for a paid plan.
But this blog post plus the 'developer evangelist' give me pause and make me feel like Gitlab is aiming to just be a less well-funded Github. If you're going for the developers, it's best to avoid corpo-speak and the blog post and 'developer evangelism' is full of it.
So you think that because someone works on marketing or marketing related areas they’re technically illiterate?
As a former Gitlab employee I can tell you that Gitlab has a lot of technically accomplished people doing marketing.
People at Gitlab understand Gitlab because they eat their own dogfood. Everything at Gitlab is build using Gitlab including several marketing workflows.
Maybe they are literate or illiterate but the post is so abstract it has become nonsense.
The moment I saw this on HN, I visited the URL, to find _whats new_. Took me so many clicks to find the actual changes.
They have a release notes and a blog post and a feature list. The first two ones could be written by AI as far as I'm concerned because you can read it and understand nothing.
Third one [0], the actual list of changes, has always been crafted so well.
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?
> 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?
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 :)
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."
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.
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.
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.
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 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.
> 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:
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:
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.
> 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.
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.
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)
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.
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.
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...
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.
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.
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.
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.
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?
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.
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.
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)
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.
> 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"
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.
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.
"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?
115 comments
[ 2.5 ms ] story [ 176 ms ] threadIn 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.
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
* bugfixes
* new features
* removed features?
It is easier to approach.
Does that help at all?
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 can reproduce it with and without content blockers.
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.
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.
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/
https://docs.gitlab.com/runner/configuration/feature-flags.h...
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.
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.
EDIT: to elaborate, I agree with other commenters that seem concerned with Gitlab's direction. It's hard to put my finger on what exactly bothers me, but to take a stab at it: Gitlab always seemed to pitch itself as the nerdy, more open little brother to Github. I'm currently on the free plan, but definitely consider/considered going for a paid plan.
But this blog post plus the 'developer evangelist' give me pause and make me feel like Gitlab is aiming to just be a less well-funded Github. If you're going for the developers, it's best to avoid corpo-speak and the blog post and 'developer evangelism' is full of it.
As a former Gitlab employee I can tell you that Gitlab has a lot of technically accomplished people doing marketing.
People at Gitlab understand Gitlab because they eat their own dogfood. Everything at Gitlab is build using Gitlab including several marketing workflows.
The moment I saw this on HN, I visited the URL, to find _whats new_. Took me so many clicks to find the actual changes.
They have a release notes and a blog post and a feature list. The first two ones could be written by AI as far as I'm concerned because you can read it and understand nothing.
Third one [0], the actual list of changes, has always been crafted so well.
[0] https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-rel...
Does that actually happen? Especially the part where businesses are in the market for $50k reports that over-promise and under-deliver?
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 :)
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."
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)
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.
at the bottom there's a "Free eBook: A beginner's guide to GitOps" that requires filling out a form to download
It's a very, very hard thing to balance, as shown by the comments here.
Personally, I think they are doing an OK job on this.
Maybe it's time for me to learn the pure git and email workflow.
What's so mysterious about it?
https://news.ycombinator.com/item?id=19367916
It’s not 6:1.
(Disclaimer: am engineering manager at GitLab)
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)
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 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 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/
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.
Meanwhile many core features are still unpolished e.g.: running your own runners sucks and you can't test CI/CD locally.
https://gitlab.com/groups/gitlab-org/-/epics/2426
Also, I find that running your own runner is super easy and straightforward.
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.
This reduces the menu items to a minimum.
* 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
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...
https://gitlab.com/gitlab-org/gitlab-runner/-/issues
After upgrading to dind 20.x, our build resumed.
https://gitlab.com/groups/gitlab-org/-/epics/5675
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?
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.
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"
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 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.
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?