Gitlab 14
about.gitlab.com
about.gitlab.com
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?
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.
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.
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 :)
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.
* 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...
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...
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.
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?
Meanwhile many core features are still unpolished e.g.: running your own runners sucks and you can't test CI/CD locally.
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.
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.
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?
After upgrading to dind 20.x, our build resumed.
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.
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?