CI/CD Minutes For GitLab SaaS Free Tier

Hi everyone,
First, thank you for building this incredible tool that Gitlab is (that may only need a shortcut to navigate beetween commits of a merge request ), and providing free access to some of these incredible features.
Now, as I currently use GitLab SCM + CI + CD (around 1k-1k5 minutes a month)
As I work for a non profit organization that works alongside homeless and poor people, and this change will most certainly impact us, I wonder if you plan to apply some exceptions or solidary billing on these usages quotas for non profits organization ?
Thanks

I honestly wish that before making this change you had addressed the workflows of purchasing additional minutes. I almost bought extra minutes one month when I was approaching the limit, but it was so unintuitive that I thought it was broken and gave up. https://twitter.com/tecknicaltom/status/1273459732351561728 - I should be able to give you a cc and you give me minutes. Don’t make it difficult for people to give you money. (PS, I registered on this forum to make this post. Same deal, why do I need to confirm my email address when I logged in with my gitlab account?)

Hi @paspalas thanks for the feedback. We will consider including this in future communications.

From our pricing page: Pipeline minutes are the execution time for your pipelines on GitLab’s shared runners. Execution on your own runners will not increase your pipeline minutes count and is unlimited.

More information on CI/CD is here https://docs.gitlab.com/ee/ci/introduction/

Hi @thibaut.cheymol - thanks for writing in with your feedback. So glad you love GitLab!

Currently - we have programs for Open Source, Education and Startup programs and do not have one for Non Profits. We do generally see the value in non-profits and we hope to create some sort of a non-profit offering in the future. Consider providing your feedback in this issue for non-profits.

I’m involved in several open source project groups that are using GitLab CI quite extensively. Joining the Open Source Program to get extra CI minutes is interesting, but I’m unclear exactly how this will work wrt contributors.

Our projects use the forking workflow, so individual contributors never have direct access to any of the official project group repositories. Instead they fork the repo, and open merge requests to feed code back from their fork into the primary project repos. All merge requests are required to pass all CI jobs before merge requests are permitted to merge. Due to the forking workflow, the CI jobs are all running in the context of the user’s fork, not in the context of the main project group.

IOW, the only CI jobs that run in the context of the project are the post-merge CI jobs. Everything else ends up running in the contributors personal account. If the project joins the open source program, that give more minutes for the post merge CI jobs, but does not appear to help our contributors who are running CI jobs from forks.

Given that the project requires CI to complete before accepting a merge, if a contributor runs out of free CI minutes, they will be unable to contribute to the project, even if the project is part of the open source program. It feels like the open source program ought to be able to cover this forking workflow scenario somehow. Am I missing something in this respect ?

I would also note that registering custom runners to a project is not a simple way to deal with the reduced CI limits. The custom runners can only run jobs that are directly associated with the project against which they are registered. They are not able to run jobs for any users’ forked repos. This makes sense from a security POV, as you don’t want a custom runner to be abused by anyone, but it significantly limits the usefulness of custom runners for projects with a forking workflow.

This problem is not unique to gitlab CI, and I’ve noticed other platforms often deal with this by requiring a project administrator to approve running of jobs when receiving submissions. It would be very useful if GitLab supported something like this so that custom runners from a project can run jobs on a merge request submitted from a user’s fork. This would solve a big usability problem with providing CI envs for non-Linux OS and lessen the impact of the reduced CI minutes on shared runners.

What happend to the bronze tier?

Our team is on the free tier and currently uses gitlab for SCM + CI/CD. In my analysis back in May this year, I figured out that probably the Bronze tier would be the appropriate choice for us.

Has it been dropped? If so, I think we have to stick with the free plan and top up the minutes every now and then. Silver tier is not feasible for us.

Hey @tecknicaltom thank you for contributing, I appreciate your candor! I am the Product Manager for Fulfillment which focuses on the purchasing and provisioning experience. We are diving into several purchase flows including CI minutes looking to uncover opportunities for improvement.

If you’d be willing to connect for a 30-minute call to discuss the challenges you encountered, that would be super helpful. If you’re interested, please ping me at arueda@gitlab.com.

Is this applicable for public open-source projects?

I’m using more than 3000 minutes for my public projects! I will be more affected if it is 400 mins for public repos!

PS: GitHub offers unlimited action minutes for public projects!

Unfortunately, this limitation can cause weakening of GitLab’s competitiveness compared to other competitors… Nevertheless, I do not object to this limitation, as I recognize the burden of GitLab.

However, I’m wondering if GitLab is looking for a way to complement this. I think one way is to provide free tier with features (i.e. multiple assignees, reviewers, etc.) instead that are less burdensome to GitLab and that give users great convenience. I hope to hear GitLab’s thoughts. Thanks.

I have three questions/comments.

Should this limit be per project and not per group? Because I worry that this will lead to proliferation of groups with one project inside of them, for people to get maximum of time. Which will lead to higher occupancy of the top-level GitLab namespace.

Answer by @nuritzi didn’t really address the question by @mattia.basaglia. So does this limit apply only to private projects? Because current language of the open source program read like public projects have a Gold limit automatically. Will this still be true?

And this is to me a major issue with this change. Because MR CI runs run against the fork’s group this becomes a problem for open source. Especially if the limit is per group. This means that all forks I create to my personal namespace will compete for some minutes. Does this mean I will have to create random groups to fork projects into?

In fact, I am most concerned about this. As @mitar mentioned, the CI/CD time limit for public projects restricts individual participation in open source projects, so it seems that GitLab CI will be no longer suitable for open source projects on gitlab.com unless self-hosting.

Yes, @mycroft is right! Please revert this idea for public repos!

If CI/CD minutes are limited the how GitLab is supporting open source to stay sustainable?

@Oxdf
Thank you for submitting an issue for your request, which now marked as a duplicate of this issue you can follow for progress: https://gitlab.com/gitlab-org/gitlab/-/issues/246844

Hi Mitar,

I’ll let someone else respond to the question about namespaces. I do know that GitLab has an abuse department that looks for multi-group creation abuse though.

The Gold project vs Gold group feature offering is something that’s confusing and we’re trying to improve, so I can see why you’d have this question. Here’s more information:

What are Gold features?
First, I’d like to clarify the distinction between GitLab’s features and the CI minutes that we offer. These are separate.

Gold features refer to the list here: Self-Managed Feature Comparison | GitLab You’ll notice that the list does not mention the amount of CI minutes per tier. Instead, we mention the CI minutes per tier on the main pricing page: Pricing | GitLab

Gold features per project vs per group
As you mentioned, Gold features are automatically provided at the project level to publicly visible projects.

However, there are some Gold features that only apply to groups. Those are features like roadmaps and epics. Here’s the list of group level Gold features (the side bar has the list). So, if an open source project needs group-level Gold features, they’ll need to apply to the open source program.

We don’t want to make it harder for people to contribute to open source projects on GitLab. Thanks for the feedback you’re providing!

I believe that due to a known bug, public projects’ CI minutes are not being counted. This gives us some time to think through the open source contribution story in regards to the new CI minute change. That means that only Free accounts with private projects will see an immediate impact to their CI minutes.

I’d really like to see that it keeps getting easier to contribute to open source projects on GitLab, so again, thanks for the feedback!

cc/ @supadhyaya

This makes sense. Thanks for this explanation. Can I suggest this is added to open source program description somewhere? So this difference between gold project and gold group? I was confused with this before, also because you cannot really obtain information about the plan your project belongs to. It would be great if I could somewhere written “plan: gold” for public projects. (Or is it there?) And then for public groups there would be some other plan listed.

Good idea! I’m in the process of making several changes to the GitLab for Open Source landing page. I’ll try to add more about that there for now. I just added a note to myself about that in the work-in-progress MR I have for an update to that page.

I personally think that there should be more information about Gold groups vs projects on the pricing page though. I have this proposal in an issue here: Suggest update of GitLab’s comparison page.

I don’t think we have that in the works, but I think it’s a good suggestion. I created this issue just now taking your comment as inspiration.

As an FYI, we may need to turn that into a confidential issue if the corresponding team picks it up and starts talking about pricing or business strategy. I wanted to show it to you before that happens in case you have further input.

It’s possible we already have some of that, so someone may chime in with more info.

We’re thinking through how to support our open source ecosystem better. This CI minute change will most impact those with Free accounts and private projects.

Please see my more detailed answer to some of the questions around open source projects and the CI min announcement in this comment: CI/CD Minutes For Free Tier

@nuritzi Thanks for your reply.

But could you clarify? It has been announced that this limit applies to public projects as well, but can your reply be understood to mean that the time limit may not apply or may change for public projects?

This is an important point for some open source projects in deciding whether to migrate to another ci/cd service or keep using gitlab ci/cd.

The distinction here about free CI for public project is critically important for Open Source projects like my own, Samba.

I realize that, because we do not pay, we are the product, not the customer.

However, I think we do bring a value to the platform, and while I’m not asking (but of course would appreciate) that we get unlimited free CI forever, we need to know what the rules will be, and when they will apply from.

Significant financial, planning and infrastructure decisions rest on understanding clearly the plan here. Samba is a massive user of GitLab CI, using (at an estimate, because of the mentioned bug) in the order of 720,000 mins of CI pipeline a month. If this was all to fall to our own runners (which we use for some jobs, and as a backup when we are throttled) or we started paying for CI mins, it would cost us considerably!

Again, we have appreciated the generosity to date but need a clear direction from GitLab.com so we can make our own plans!

Furthermore in general, 400mins would not be enough for even a single Samba CI run (they take 1200min), so I can’t imagine many new contributors being willing to first pay GitLab to contribute to Samba.

It is not possible, so far, to run guest MRs against our CI runners, but this means even the newest contributors need to be brought into our group first-up. This will be an issue more broadly.

Therefore, what I ask is for a new timeframe to be set before which no CI on public projects will be charged, and between now and then a clearly communicated plan for what the charges will be and how it will work for projects like Samba.

It is not practical for us to plan based on the indefinite date a bug gets fixed.