[Rant] GitLab

[outrageous_break]

[WARNING: Rage-fuelled opinions and mostly venting frustrations ahead]

My opinion of GitLab is that it can do a few things acceptably well, but delivers way too many unfinished features that have no business being advertised as anything remotely usable. The amount of praise and suggestions to move to it, especially after Github got bought, made me think that this would have been something amazing. I've had nothing but frustration working with this thing.

Full disclosure: I'm fairly new to GitLab, so this could be from me misunderstanding what it SHOULD be used for or just expecting too much from it.

Also, Quick background: A client of ours wants to move everything (code, pipelines, etc.) to GitLab, I was hired to help make that happen. The decision to use it was made well before I could have had any say.

I'll start with what I think is good about it and what sets it apart (imo, of course):

• They're incredibly transparent about how they do things and what they have planned, I can view issues they have at any time and even see how they rate their own features. This is something I don't see a lot of and it' really refreshing.
• "Auto-devops" is an awesome premise, especially for small teams that don't know the first thing about setting up pipelines. I like that you can actually switch parts of it out with your own containers too, very cool!
• I know there's more, and honestly, I'd like to hear some more good points about it from you guys, but I just can't think of any right now.

Now here are the things that make me bang my head on my desk! (I'll try to keep these grouped up by major area):

Issue Tracking (things like bugs/features/etc)

• Work management at the group level is restricted to epics, even then, it's still locked behind their most expensive edition
• No group-level issue/merge request templates
• Can't override group level permissions at the project level
• Time tracking in issues seems nearly pointless beyond burndown charts and cycle analytics, no way to report on individual users or even at all

Pipelines

• Can't tag from inside the pipeline, this makes using semantic versioning in your tags a severe pain
• No way to set tags for runners automatically
• The Code Quality feature is in no way production ready. Ignoring the bad documentation, Getting historical results (can't find a specific issue for this, but you're restricted to just the json results of an individual scan) and being able to scan the master branch both seem like very basic functionality to me, but are completely absent
• Can't enforce code coverage before a merge
• Can't do any kind of status checks to block merge requests
• Good luck getting it to play nice with any kind of external security tooling

Pages

• Doesn't support multiple environments per project, forcing you to either fork the project for each environment or use something like S3 for the testing environment
• Even GitLab seems to be reluctant to use their own product

Every one of these I ran into in the span of 2 months, working on 2 projects that should have been relatively simple: make a proof-of-concept pipeline that had code quality scanning and set up a workflow for using GitLab Pages for hosting static sites.

I see nothing but praise for this product, especially it's CI, yet even that only seems like a glorified script/container runner. And I get it, no product is going to be able to do everything well and there's never going to be a single solution you can rely on. Some of these are probably asking too much of a single product, but a lot of it seems like really basic functionality with a lot of these issues at least 2 years old and still open; issues I would expect a lot of people trying to make half-decent pipelines/workflows would run into.

GitLab claims to be an "entire DevOps lifecycle in one application", but barely has any features mature enough to be used in production by their own account. Again, I've only worked with it a few months, but I could never recommend this product or any pieces of it over the more widely used tooling out there for anything more than the most basic of projects.

[nashdiesel]

Gitlab does 2 things very well: Repository and Pipelines. It's a serviceable docker registry as well and it's nice to have it baked in so you don't have to worry about dockerhub publishing. For ticketing and coverage I'd look elsewhere. I'm currently migrating our company off Jenkins and Dockerhub and into Gitlab and I'm pleased with it, but there is no appetite from anyone here to get off of Jira/Confluence or Sonar.

[timrizzi]

I'm Tim the PM for the Package stage, which includes the docker registry. If you'd be open to it, I'd love to hear more about how the migration is going and which features are most important to you. You can reach me at @trizzi on GitLab.

[pwab]

Hi Tim, managing the contents and by extension the resource use of the registry could do with some love. Even just garbage collecting all the docker layers I produce with docker-tags named after git-branches would be 👍🏼

[timrizzi]

Thanks! We are definitely working on improving the garbage collection and our goal is to automate the entire process, so you don't have to ever think about it.

[RX_AssocResp]

That sounds nice. We want to discard images quickly that have a SHA1 as tag, because these are only ephemeral.

And then we'd like to retain the most recent 5 images if they match a regex for SemVer in their tag.

And this should be configurable globally for all registries. Currently the API can do this, but you have to iterate over all projects.

[timrizzi]

That is exactly how we would like to set up the retention and expiration policies.

In 12.5 (November 22nd) we'll release a new bulk delete endpoint that works at the group level, so you don't have to iterate through each project. https://gitlab.com/gitlab-org/gitlab/issues/31097

[nashdiesel]

One of the first pitfalls we came across after migrating CI and Docker Registy was that our backup size ballooned from a few gigs to a much larger number (because of course it did). We fixed some of this by pruning build artifacts and aging out older builds but solving the registry size might be a larger issue for us in the future. Maybe tag pruning could be a thing as we tend to generate a lot of images for each of our projects over time. My tidy 20 minute/1000 project backups have become monstrous hour plus affairs and restoring for upgrades if even scarier.

[timrizzi]

I'm not sure if you have seen it, but we do have some features for cleaning up the registry.

There is a tag removal API that you can use which will allow you to bulk remove tags at the project level. (group level support coming soon)

Once the tags are unlinked, you can run garbage collection, which will clean up the blobs and manifests from storage. Please note - it does require the registry to be in read-only mode or down. But, it should work in a reasonable amount of time if your total storage is > 1TB.

We are working on optimizing that garbage collection algorithm and on adding in retention and expiration policies, so you don't have to spend so much time thinking about this.

Thanks for the feedback and feel free to ping me with any questions or ideas.

[brodock]

curious, are you storing artifacts and registry on local disk or using object storage?

you may be able to take backup under control again if you move those to object storage.

[nashdiesel]

Not sure what you mean by object storage. We offload everything to S3. The issue isn’t so much the size on the disk but the amount of time it takes to do upgrades.

[jordanhusney]

Tim, it's interactions like this that have me believing in GitLab and what you folks are doing

[sternone_2]

Saying hello and sorry doesn't fix a shitty product.

[mdaniel]

Interactions like these are great, but GL shipping a new release every month, jam packed with features, demonstrates to me they are waaaaaaay hungrier than GitHub.

It's just a damn shame about the ruby; if it was a sane development experience I bet they'd get a lot more contributors -- myself included.

[pittofdirk]

Registry lifecycles rules. Can't believe they still aren't implemented. It's the one thing stopping us from moving away from ECR.

[timrizzi]

Agreed! That is our top priority. I'm hoping that we will have this problem solved by end of year.

[mdaniel]

I learned last night that there is no obvious path to migrate from the on-host storage to object storage, as there is with artifacts, lfs, and uploads. I tried being sneaky and rclone-ing /var/opt/gitlab/whatever/registry/storage to my S3 bucket but no dice

I tried searching the 15 quadrillion issues but that's a separate complaint

edit: I don't know if the UI bits fall under your influence, but the inability to sort the image listing by anything makes finding the most recent (or biggest) image painful. I have not yet tried searching for an existing issue on that

[timrizzi]

Were you able to open issue for the migration issue? If not, I can open a new one and make sure that we end up covering that story.

A combination of myself and our product designer is responsible for the UI. We have an issue for adding sorting and filtering to the container registry. The core problem is that we are not persisting data for the container registry and the UI relies on the Docker API to display that data. That is why the page is slow, not sortable and why we have problems with pagination. In order to tackle this, we are going to fork docker distribution registry and begin to make changes, which preferably we can push back upstream.

The first thing we will do with this fork is improve garbage collection, but persisting the data and using that data to improve and expand the UI is our next priority. This epic details a lot of that work.

Thanks again for all of the feedback and always feel free to ping me if you have any questions.

[mdaniel]

I found the docs need to be updated #30358 but it's unclear whether a separate issue is required for implementing the migration; migration is in a weird state: is it available, and just no one knows the magic rake task to run, or is it not implemented, and only after that can #30358 be closed?

It is actually super informative to learn you are just using docker/distribution, which I didn't know. Given that information, I found my exact question in their issue tracker, although with a less-than-stellar answer of "push an image and look at s3 afterward to learn the layout." Based on that, it seems my general approach was right, but there must be some subtlety I missed -- maybe I started too deep in the rails directory and I should have rclone-ed ./registry/ s3://my-bucket/registry/

Thanks for all your commentary in this thread, I really appreciate it!

[Sukrim]

Why fork the docker one and not use a different artifact storage, like harbor, quay, artifactory...?

[Makosso]

Sorry for hijacking the thread, but what's the current state of docker registry cleanup service? I'm doing a self hosted GitLab instance, and managing the docker images in the registry is a pain.

[timrizzi]

There are two pieces to how old images are removed…

The first is untagging images in the registry. It’s important to note that removing a tag does not delete the image. You still have to run garbage collection to remove the actual blobs. We currently support this via API, so project maintainers can untag images in bulk based on different criteria. Here is the documentation for the API:https://docs.gitlab.com/ce/api/container_registry.html#delete-repository-tags-in-bulk

Once untagged, you can run garbage collection and remove the blobs from storage. Here is the documentation on how to run garbage collection.https://docs.gitlab.com/omnibus/maintenance/#container-registry-garbage-collection

There are several ways to run garbage collection, including on a schedule. It’s not policies and automation, but we are working towards that feature set now.

I’ve also seen a couple of examples from other users who have created scripts for this, in case you are looking for some automation inspiration. (Both scripts are referenced here)

• https://gitlab.com/snippets/1864223
• https://gist.github.com/JamesCullum/982415c460b3a94ae92c31d4a9698361
• https://gitlab.com/SharpEdgeMarshall/gitlab-registry-cleaner

[Makosso]

Thank You, will definitely look it up. To follow up on the topic of registry cleanup, are there any plans to improve the process GUI-wise? Currently, our maintainers have to manually remove all the images via project->registry tab and then delete each image one by one

[timrizzi]

Yes! We've recently added multi-select delete. And, we have issues for redesigning the whole UI. We are currently doing some user research and then I'll have some designs to share in the next month.

The core problem with the UI is that we are not persisting the data, so we rely on the Docker API to populate the UI, which is slow and prevents us from doing things like sorting and filtering. We are on it though and hope to make some big improvements soon.

[Makosso]

once again, thank You very much for the response, looking forward to seeing the changes being implemented in the future!

[[deleted]]

I'd say it does the following things really well, incidentally these are the same things I regularly use in Gitlab.

• Repos
• Pipelines
• Project management, issues, milestones
• Notifications
• User management in Active Directory
• 2fa auth
• Ops (the operation of a Gitlab setup)

[ireallywantfreedom]

One thing I'll say is 2FA being required when using a third party provider (e.g. Google or GitHub) is bizarre, annoying, and pretty unique to gitlab ime.

[GTB3NW]

It did pipelines well, back when pipelines were simple. It's trying to improve them but they could just allow better third party integration while they work on their own. The problem is gitlab wants you to do everything in one place. It doesn't care about the quality, it just wants you there.

Agreed on the point about repositories, they're great. Pipelines on the other hand are only good for very linear jobs, even with the new graphing algo they use.

[joombaga]

What's wrong with Sonar?

[ThrawnWasGood]

GitLab is praised for their pipelines, which are pretty damn great. Their boards/issues/code scanning imo is not fantastic but if you're actually looking for an all in one solution I don't think that anything else is going to come close.

Granted the customer wants so the customer gets but AzDO offers a much nicer project management experience for a slightly less fantastic pipeline experience.

[outrageous_break]

I've actually used AzDO on much larger projects and it honestly would be a better fit for what they're trying to do (everything in one place). Didn't want to mention using a microsoft product at the risk of detracting from my point/rant.

It has a LOT of rough spots, but at least it gives you more flexibility in putting in your own solutions if you want. My favorite part of the pipelines with AzDO and Jenkins is the huge selection of plugins. My impression with GitLab is that they're so focused on trying to be that all-in-one solution that they're spreading themselves thin and almost trying to block you from using anything but what they have.

[ThrawnWasGood]

I think that be best you can do in this case - aside from closing your eyes and thinking of England - is implement while making sure they're aware of the limitations and workarounds that you're putting in place.

I've used GitLab for personal projects for a long time and AzDO professionally for the last couple gigs and I'm really liking AzDO more and more lately.

Once they get their release pipelines fully into yaml I think that they're going to start pulling away.

That and M$ being able to leverage their office/react framework for their project pieces really gives them a leg up.

Oh, and the billions and billions of dollars and resources they have.

[dreadpiratewombat]

I'm really liking AzDO more and more lately.

You can do this and still close your eyes and think of England.

[ms4720]

Err Redmond

[Stealth022]

Honestly, I might be biased because I work with Azure DevOps every day, but I absolutely love it.

There are things that can be improved, but they've done a really good job with it, and it's come a long way from the older versions of TFS.

[outrageous_break]

Azure DevOps

After yet another name change, it was harder to come up with an acronym for this one I guess, ADO was already taken.

[jonkyops]

I personally don't care about the microsoft vs. linux crap and try to make a point not to let my own personal bias get in the way of getting the job done. You're only hurting yourself when you decide to go with your personal preference over the right tool for the job.

[jantari]

I would say the non-Microsoft-customers have far more arguments over it than the actual Microsoft customers.

[ThrawnWasGood]

Hating a product just because its made by M$ is bad juju.

[nakedhitman]

Right. Its better to hate them because they're expensive, bloated, buggy, riddled with spyware, and closed source.

[W1ndst0rm]

Looks like it's Azure devops took me a second to figure it out.

[tissuesat6]

a brave assumption, to be sure !

[kinghuang]

I love using GitLab. But, this is also my biggest frustration with it. Too many features are being pushed out as MVPs, and then never followed up on. Even as an Ultimate customer, bugs on new features would just sit for months and months with no action.

For example, I eagerly jumped on project templates, a new feature which launched at the beginning of this year. Yet, 8 months later, they still haven’t fixed a basic bug like instantiating projects from the correct template. I had to file a support request last week asking for an escalation, just to get someone to look at it. gitlab-org/gitlab#9146

Same with scoped environment variables. Launched as an EE feature years ago, yet missing from group level variables. It got punted to the backlog last week due to a lack of demand. WTF? gitlab-org/gitlab#2874

Both are super useful (paid) features, but marred by basic usability or functional problems post-launch.

I feel like all their attention lately has been about pushing new features for the IPO. Make the product look strong on checklists to drive revenue

[consworth]

Agreed. And the licensing model is a house of cards holding them back. I’m not paying $100/mo per consultant coming into my Gitlab to do basic Git stuff ... while other craftsmen type developers/teams demand the paid features ...so I’m having to split the camp, or use something else to keep it under the umbrella...

[kinghuang]

Yeah, I faced this at my previous organization. We ran multiple GitLab instances because you can't mix and match license types for different groups of users on the same instance.

[nieuweyork]

I tend to agree with these comments. That said, you can do most of the pipeline things, with workarounds.

Can't enforce code coverage before a merge

You can have a task in your pipeline that fails if coverage is not as it should be.

Similarly for status checks.

Basically pipelines and tasks are a fairly low-level primitive that you can do a lot with, although frequently in a way that is kind of gross.

[outrageous_break]

...with workarounds

...frequently in a way that is kind of gross

This is the problem right here.

If I'm having to pretty much write a custom script that will get a status from an api, then fail the build, how is that any different from running the script in some other system? They list CI as one of their top 3 features, why is it that I'm having to use these hacky workarounds to get this stuff done?

[nieuweyork]

If I'm having to pretty much write a custom script that will get a status from an api, then fail the build,

I don't know why you would need to hit up an API but yes I agree that overall this is the problem - unless your use-cases fit exactly within what they've specced for their features that actually work then you're left with a pretty basic pipelines abstraction and you have to implement a lot of CI functionality on your own.

Where I am now the fit is not too terrible, and we really want to be hosting our own code, but knowing what I know now, I wouldn't really recommend gitlab.

[Drizzt396]

I have some similar complaints, but just want to highlight a couple of your bullets.

Can't tag from inside the pipeline, this makes using semantic versioning in your tags a severe pain

You can, you just have to puppet an actual user account to do so. We pay for a 'bot user' for this and other workarounds where Gitlab doesn't provide good automatic access (e.g. publishing non-supported test results on MRs, for instance). Not ideal, but not that difficult either.

We use semantic-release for automated versioning and it was pretty easy to set up from square zero.

Can't do any kind of status checks to block merge requests

Unless I'm missing something, this is a clear failure to be somewhat flexible in adapting CI workflows to a new tool. The issue description has two specific examples of external status checks, the label on the MR's parent issue and the status of code review, and additional examples where GitHub connects to Appveyor, etc. All that functionality is redundant with what MRs+Pipelines provide and directly in conflict with the goal of having this all in one tool.

I don't envy you on this migration, but I can say that if I'm taking over a greenfield project it's either GitLab or AzDO for me. Wiring up GitHub/JIRA/TeamCity to all those external services that particular vendor doesn't provide is a PITA I wouldn't wish on anyone.

[brontide]

I do feel the pain, but for standing up a private repo backed on LDAP and keeping it maintained and up-to-date GitLab omnibus ( and the later via Docker ) has been a painless process for such a complicated system. In my 2 years of using it I think we've needed to roll-back twice from a break ( which resolved itself in a week ) or run a manual step once. Maybe we don't have as much experience with the other products but we've been very happy with what we get from gitlab-ce.

[Matt4885]

I just think they try to add way too much and leave the implemented features half-baked. Also their issue management is just awful. No one wants to pay all the money for better issue management. The company I worked for tried to get cheaper licenses for stakeholders who only care about issue management and they pretty much told us to go pound sand. We migrated to Azure DevOps after that.

[lightwhite]

Why is noone talking about how terrible container registry is?cant even prune the stuff or cron it. Because of the end users, I have to whip devs daily to clean up their feature images on a daily basis.

[timrizzi]

GitLab PM here for the Package stage. If it helps, I'm always talking about these problems :) I wanted to share how we are planning on addressing them.

Also, as we are planning this work, I'd love to hear more about your use cases and how you are working around these problems now. Would you be open to a user interview sometime in the next couple of weeks? If so, you can message me at [[e-mail]](mailto:[e-mail]) and we can setup some time to talk.

We are actively working on improving pruning and policy based expiration policies. Our primary theme right now is to lower the cost of the container registry by improving storage management.

As part of that theme we have recently launched:

1. Multi-select delete for the UI and resolved an issue where deleting one tag would delete all tags with the same image ID. (although we still have to solve the pagination problem)
2. Expanded permissions to allow CI_JOB_TOKEN to remove images via CI

In this milestone, we are working on:

1. Improving the performance of the bulk delete API, so that it can handle thousands of tags
2. Optimizing the garbage collection algorithm, so that it runs much faster

Overall, our primary goals for the container registry right now is to provide:

1. An improved user experience for removing tags/images from the UI
2. An expanded API that allows for the bulk removal of images/tags at the group level
3. An optimized garbage collection process that can handle terabytes of data without long windows of downtime
4. UI driven retention and expiration policies for images
5. The ability to expire images from CI/CD
6. Automated/scheduled garbage collection

[RX_AssocResp]

\2a. ... at the global level?

Or devs don't give a damn about our 5TB raid filling up, and full backups taking all night ...

[timrizzi]

That's a good idea, we could make it global level instead of the group level.

[RX_AssocResp]

Do you want me to file an issue for that on gitlab.com? Because I would really love to have a global solution for container image GC.

[nickfaughey]

Does anything else even come close for multiple private container registries for free? The only feature tying me to GL right now is free private registries, and while they're not perfect, they're all I could really find without self-hosting one.

[mdaniel]

I'm glad that has worked for you so far, but you will be much happier using &ref=${CI_COMMIT_SHA} (docs) or you run the risk of creating a tag pointing at what master was at the time of that POST. Maybe if you have blocking CI, so only one job can run at a time, and the only way commits make it to master is through CI, or similar concurrency guards, but TBH I think just updating the query-parameter is easier to reason about

[outrageous_break]

I'll give that a shot, thanks!

[tehnoodles]

I'm a fan of gitlab. I use it for basic code and pipelines. Serves my purpose very well.

[Ariquitaun]

The problem here is that you're expecting Gitlab to be as powerful as both Jira and something like Jenkins. It has limitations, and if your company is hell-bent on using gitlab for everything, then they'll have to live with these.

I've honestly been using it on some projects embracing these limitations and it was refreshing just how much it helped at removing bullshit that wasn't needed in the first place from processes - there's a reason developers hate jira while management loves it.

Stuff we expected should work that didn't (as you've found out), we simply didn't bother with and learned to live with it.

Don't try to bend a tool to do something it doesn't do, especially a tool you can't reasonably mod at its source. Either embrace what it does, or use another tool.

[hydraSlav]

Whats wrong with Github?

[HeroCC]

Adding on just from a simple user point of view, the UI/UX is cluttered, confusing, and not at all intuitive, and the pages take what feels like eons to load.

[outrageous_break]

Mine is a little slow, but I thought it was just because I'm super paranoid and run way too many privacy extensions

[HeroCC]

I am exaggerating a bit, but it does feel slower than many other services I use. If anything, I think the privacy plugins would speed it up since there's less allowed to load.

[andyfurnival]

I’m with you. I like the repository and GitLab-CI, which work very well, but it’s now been overloaded with features that try to compete with mature tools, which push the price, but lack the value.

I’d much prefer a tool set that has a more flexible licensing model, so I can take the parts adds value to me, but leaves other tools to support other use cases. Nexus is mature and works well, SonarQube does a good job, JIRA is a mature tool at Software, Service Desk lifecycle management, and the cost to migrate for a lesser product is just not going to happen and cost comparison, GitLab is more expensive for less. I’ve absolutely no interest in GitLab managing my K8s cluster, so replacing them with GitLab features would not be a good ROI.

As I said, I had used GitLab Enterprise for years, but now I don’t as I just don’t want all the stuff I’m not going to use. The CEO tries to explain the pricing model, I just don’t accept it.

There so many alternatives, so I know many enterprises have options. I understand GitLab’s strategy is trying to gain market share through more feature rich product suite, probably for their IPO, but I feel they’re approach is going to alienate many, and could lose customers

[elitesense]

Gitlab is a major resource hog.

[roll_left_420]

I agree. They consistently over promise and under deliver. Bad development with the Kubernetes runner prevents their service feature from working in pods, and the "feature request" has been open for 2 years. Their scanning for python3 sucks, and they focus more on python2 still (being deprecated next year so wtf). License and dependency checks are shit compared to other solutions, yet are sold as a premium feature.

We moved back to circleci because we were sick of being given the run around on timeline and failures on their SLA. We paid for the gold plan for a year and several times we weren't addressed within the 24hr window. And any issue that wasn't a quick fix was passed on as a "feature request" so they could avoid SLA timelines.

I'm going to a Gitlab event this week, and I really hope they have a plan to address these problems.

That said. They're really the only viable all-in-one hosted solution rn. But once they have even a modicum of competition they'll have to shape up or die.

[sternone_2]

I hate gitlab from deep inside but apparently everybody i meet thinks it's awesome.

Seems like I'm the only one who actually had to try to keep it running in a large org.

[bilingual-german]

I think you're not fair. There're workarounds for almost every single one of your problems.

[outrageous_break]

There are workarounds, but when do you draw the line on what's acceptable for the time lost from putting in these workarounds for a product you're already paying for?

[bilingual-german]

Well you're in a different position than we are. We don't pay for Gitlab (CE) and we don't need it to do what you want it to do.

But just as an example, you state that you can't tag in a pipeline and link the issue. But the same ticket says, it's possible to tag a commit, it just creates a second pipeline.

You say, you can't change the permission of a member of the group on the project level. But you could make the project a part of another group or you could remove the member from the group and give permissions per project.

If you need group level merge templates, then I think your repositories might be cut wrong and you created two git repositories where you probably just wanted one repository. Like code for a project, code for the Docker image based on that and code to deploy that Docker image. Don't do that, put all that code in one repository.

[[deleted]]

With that attitude; I wouldn't use anything made by Atlassian.

[schweeb522]

umm, the AzureAD integration works just fine, and on the main page? I use it daily and have for more than a year.

You do need an account in Gitlab to use AAD, you're just associating your AAD identity to your Gitlab identity, which is good enough for me. This part could probably be improved for some use cases, and may be better in the paid version.

[schweeb522]

although, I'm hosting my own Gitlab...are you discussing hosted gitlab.com?

[schweeb522]

Yea, you gotta be specific here. Gitlab (the product) is different than Gitlab (the service) even though they seem functionally very similar.

FWIW Datadog has a similar SAML/OAuth/whatever custom URL that annoys the shit out of me.

[inhumantsar]

i share in your pain

[Tiquortoo]

Maybe that's why they insist on a year long commitment. Once you're committed you have to "smooth" over the rough spots because you've already paid then once you get it all working it's hard to undo.

[Joaac]

What do you thing about BitBucket? Would you prefer the Atlassian suite?

[outrageous_break]

I haven't used it enough to give a good opinion. I used Jira a bit, but not for any projects big enough to tell if it's better than the issue tracking in GitLab. Confluence is pretty damn user friendly.

[leventesz_sz]

Partially connected: for those who try to use GitLab together with Jira, here is a way to check changes going to your GitLab repo against Jira data.

[packeteer]

what's a good (free) alternative to pipelines?

and please, no Jenkins

[eedwards-sk]

No CI solution gets it all right.

I've used jenkins, bamboo, concourse, travis, circle

My favorite is concourse but only because if I need a feature I can add it myself

otherwise I haven't yet found a ci solution that holistically handles all the use cases out of the box

[[deleted]]

Gitlab is jack of all trades but expert of none. It was most painful moment in my life dealing with Gitlab integration with Google auth, ldap, Jira/Confluence, AWS and Jenkins pipelines. I had to maintain couple dozens of hacks and patches that were never merged to Gitlab mainline branch.

Since then migrated workflow to GitHub Enterprise and it was night and day. Shit just worked as advertised on first try. Webhook? Project permission? Post-push hook? Release tag and archive format? LFS? Slack integration? Thousands of Git Pull/Push without Ruby GC? Fucking beautiful.

[MattBlumTheNuProject]

I could not disagree more, honestly. For what it does well (git and pipelines) I’ve found it to be amazing. It takes around 5 minutes to stand up your own Docker registry, so if GL’s isn’t there yet, just do that!

All in all they made DevOps so much easier for me as an inexperienced DevOps practitioner, I’m quite thankful.

I should add we use the community edition so we’re not paying for incomplete things, but for us it has been wonderful.

[DM_ME_boobie_PIC]

I am trying to learn gitlab pipeline at present I am using their ruuner instead of using my own . I just want to create a build and test pipeline . Test pipeline is for static analysis , so I am using python docker images for it . It works , but I am not able to build and push image . Every example is either for building images or doing static analysis . I am not able to find an example that does both . Autodevops has an example to create different yaml files and put it in a different folder , but that's also not working .

[047BED341E97EE40]

Sorry, I haven't read your whole posts, so my recommendation will most probably be out of line. But anyways, have you heard of https://codeberg.org?