CI/CD Minutes For Free Tier

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. :sob:

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. :grinning: Thanks.

2 Likes

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?

1 Like

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. :cold_sweat:

3 Likes

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? :sob:

1 Like

@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: https://about.gitlab.com/pricing/gitlab-com/feature-comparison/ 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: https://about.gitlab.com/pricing/

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

3 Likes

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.

1 Like

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.

2 Likes

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

1 Like

@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. :thinking:

2 Likes

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. :slight_smile:

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. :frowning_face:

1 Like

I am wondering if no replies happened in the recent 8 days… Was all discussion over???

@nuritzi Is that really a bug? That has been a specification about CI minutes of GitLab CI since it has launched, as far as I understand. @mycroft @yogi might be some of specialists for these fields. (Unfortunately, except for all GitLab products and some small PoC, all my contributions to OSS are on GitHub\.com :bowing_woman: )

Will track https://gitlab.com/gitlab-org/gitlab/-/issues/243722 progress! Thanks!

From a viewpoint of a UX/IA designer of Web UI, #243722 might harder than we think…

Thanks, @nuritzi - though can we get some clarity on when you’ll apply the limit to public projects please? The latest comments on https://gitlab.com/gitlab-org/gitlab/-/issues/243722 seems to indicate the ‘fix’ is just to change a configuration value, so this could easily happen by/at the end of September.

A definitive date for changing the limits for public projects would be good, so that everyone can prepare - or failing that, a clear statement that this won’t apply to public projects at the end of September, and that there’ll be (say) a further announcement with at least 2 months notice before you do apply it to public projects.

@abartlet

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

Reference to The Social Dilemma? (I just watched it this weekend and thought it was pretty good. Lots to think about).

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.

Yes, I agree. I added a comment about that in the bug issue and I (and others) have already been advocating for that internally. I used your comment as an example, so thanks for adding to this conversation! Having more real use cases to point to is helpful. (So thank you also to everyone else adding comments here about your open source projects!)

cc/ @tnir @joseph.heenan @berrange @supadhyaya

3 Likes

Thank you for the update, I’m following that issue too. I tried to get an idea of how much CI time libvirt is using by temporarily making my fork private, and running the CI jobs. I appeared to consume 450 minutes in a single CI run, and that’s with many jobs skipped as their cache was primed. So even if we were approved for the Open Source Program, I fear we would easily hit the larger 50,000 minute limit with our rate of contribution and current scale of testing (ignoring that we want to add even more CI). I’ve not checked their single-run CI time, but I expect the QEMU project will consume even more per-run and their plans call for more CI jobs too.

I completely understand why GitLab needs to put some limits on usage, as it isn’t sustainable for a business to provide free unlimited compute resources forever. So I’m expecting that at some point we’re going to have to at least part fund it ourselves with custom runners, even if we join the Open Source Program to get the extra CI minutes allowance.

If going down the custom runner route though, we would need to figure out an improved way to deal with the forking workflow wrt custom runners. We can’t expect contributors to setup custom runners, and AFAICT, runners from a project are inaccessible to CI jobs run in forks right now. We need a way for a project maintainer to explicitly trigger CI jobs on a new or updated merge request, such that the jobs run on the main project’s runners, not the fork’s runners. If GitLab’s integrated CI features can’t cope with that, then it looks like we’ll have to consider use of webhooks to trigger external CI instead (eg https://gitlab.com/ayufan/merge-requests-triggers), reporting back results as merge request comments or labels or approvals in some manner. It would be a shame to loose integration with GitLab CI infra though, as that’s one of my favourite features of GitLab.

1 Like

Just to add a link to the issue about inheriting runners by forks: https://gitlab.com/gitlab-org/gitlab/-/issues/15861 (and potential duplicate at https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3526).

1 Like

Thanks for adding additional details @berrange. I’ve noted your example.

If others have similar usage stories, where contributors would be affected by the changes, please add them to this thread and tag me!

@nuritzi

As another example, the GnuTLS project, on which Samba depends appears to do 50 pipelines a month, at around 90mins per pipeline. This puts it just on the cusp of the new limit.

I think it is really important that some analysis is done - the public rationale that most groups don’t use anywhere near 400mins per month is (we know learn) based on private projects only.

Also, for Samba, a significant part of the value proposition to using gitlab.com (compared with our previous patches on mailing list approach in particualr) is easy drive-by contributions. In those, we want new contributions to be able to do as much of the preparation work on their change, including making it pass an almost-full CI, before we first look at it, and before their first manual interaction.

Finally, if the gate is ‘genuine open source’ for additional minutes, please make participation in the GitLab Open Source program really easy, ideally one below the ‘Gold’ offering and instead just providing the CI resources. The current process (which Samba started) is to fill in web forms and then be invited to become a full GitLab customer with manual forms, signatures on formal contracts and an annual renewal. I don’t think this will scale to the number of open source projects that will want this!

1 Like

@abartlet

Finally, if the gate is ‘genuine open source’ for additional minutes, please make participation in the GitLab Open Source program really easy, ideally one below the ‘Gold’ offering and instead just providing the CI resources. The current process (which Samba started) is to fill in web forms and then be invited to become a full GitLab customer with manual forms, signatures on formal contracts and an annual renewal. I don’t think this will scale to the number of open source projects that will want this!

ACK on the easier application process. We’ll first be removing the merge request step of the process. We hope to automate the process more so in the near future.

There isn’t a definite timeline that I can provide for those changes at this time, but those interested can follow this epic for now: Epic: Improve OSS Program application experience for applicants and processing team.

For those wondering about the bug fix timeline… please see this new comment from a member of the Gitlab team about the rollout:

For those who are interested in this issue - I know there is some concern about WHEN we will fix this bug - and in an effort to be as transparent as possible I want to give everyone some re-assurance.

  • We understand that despite this being a bug, we owe you as our users advance notice of it changing as it could impact the future cost of your usage of GitLab.com .
  • We will provide at least 8 weeks notice (on our blog and this issue) before we begin accumulating shared runner minutes for public projects.

(Comment is copy and pasted from: https://gitlab.com/gitlab-org/gitlab/-/issues/243722#note_416630076)

If others have open source public projects with high/unknown CI minute usage on the Free tier, please continue to add your use case to this thread. Thank you!

It wasn’t so much about the MR, it was the paperwork of the contract that was a problem.

In particular the fact that the contract renews into a real (for Samba $80,000) invoice in 12 months time unless specific proactive steps are taken by the project, which in turn means we need it signed properly by our ‘fiscal sponsor’ (for Samba that is the Software Freedom Conservancy) and for other projects - the type of project you want to target, for whom GitLab.com might be their primary presence - a single individual has to take on that liability.

This might seem like a different issue, but the change in the CI/DC Minutes is the lever to making these projects need to be full legal/contractual customers, not just website users.

1 Like